Guide: audit access, sign-off & training

The read side of governance: who can see a document, who has agreed to it, who has completed the training on it, and what a given person owns. Four tools cover it. Bodies below are abridged and illustrative — see the tool reference for the full contracts.

Who can access this document, and how?

→ get_document_members_and_roles { "documentId": "7d4f2a90-…", "topicType": "system" }

{
  "roles": [{ "title": "Client Delivery" }],
  "members": [
    { "name": "Jane Smith",  "email": "jane@acme.com",  "accessType": "role-based", "roles": ["Client Delivery"] },
    { "name": "Sam Nguyen",  "email": "sam@acme.com",   "accessType": "direct" },
    { "name": "Priya Patel", "email": "priya@acme.com", "accessType": "both", "roles": ["Client Delivery"] }
  ]
}

Present it as an audit: roles first, then members grouped by how they got in (direct vs role-based vs both). Access is the union of the two mechanisms — see Roles & seats.

Who has signed off?

→ get_document_agreement_status { "documentId": "7d4f2a90-…", "topicType": "policy" }

Returns each assigned member with agreed / not-agreed status — the compliance view for policy acknowledgements (“who has actually agreed to the new leave policy?”).

Who has completed the training?

→ get_document_training_progress { "documentId": "b2c91e08-…" }

Returns per-user completion percentage and status for a training document. Combine with get_document_members_and_roles to report “assigned vs actually completed”.

What does this person own?

→ list_documents_by_owner { "owner": "Jane Smith", "fetchAll": true }

[
  { "id": "…", "title": "Onboard a new client", "section": "system",  "state": 3, "materializedPath": "3. Client Delivery" },
  { "id": "…", "title": "Leave policy",         "section": "policy",  "state": 1, "materializedPath": "HR" }
]

One call spans systems + policies + trainings (omit section for all three). The name must match exactly or the call returns a 400 — when unsure, use the person’s user UUID (visible on tree nodes as ownerId). ownership defaults to either (primary OR secondary owner).

Recipes these unlock

• Offboarding sweep: list_documents_by_owner for the leaver → report everything that needs a new owner.
• Review-debt report: walk the tree, collect documents with state: 2 (RED, overdue) grouped by owner.
• Compliance gap: agreement status across every policy → who hasn’t signed off, per policy.
• Training rollout check: progress on each training in a learning track → completion by team.

The boundary

All of this is read-only governance. The MCP cannot add members, allocate seats, or reassign roles — that’s the app UI. Don’t attempt it; direct the user there instead.