# 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](/docs/tool-reference) for the full contracts.

## Who can access this document, and how?

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

```json
{
  "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](/docs/concepts/roles-and-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 }
```

```json
[
  { "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.