List your own draft review findings on a sealed review submission
Your durable working notes on this sealed subject, most recently saved first, each with stale and stale_reason derived at read time against the live sealed row.
RECORDS what one human reviewer has typed about this exact sealed subject and has NOT yet recorded.
DOES NOT ESTABLISH anything: not that the reviewer read the package, not that the note is right, not that the policy is correct, and not that the source is true or complete. A draft finding is a working note, not evidence — it is excluded from every digest, every receipt, every export and every research record, and no receipt binds one. A judgment becomes evidence only when its author submits a review record through the unchanged review-record route.
Your own notes only. A co-reviewer on the same submission never sees them, because showing one reviewer another’s working notes would pre-load the second reader. Naming another reviewer’s note returns 404 rather than 403: 403 would confirm that it exists.
Requires an authenticated human-session principal. An API-key principal that holds the policies:read or policies:write scope this route declares is refused 403 HUMAN_PRINCIPAL_REQUIRED at the handler; one lacking that scope is refused 403 FORBIDDEN one step earlier, by the scope gate. A machine has no working notes on a human review. This route is deliberately NOT in the humanGovernanceAct class that gates reject and ratification: a note is not a governance act, nothing transitions and nothing is recorded.
Staleness is derived, never stored. A note is stale when the sealed row it names no longer carries its revision or its package digest, when the submission has been returned to the author, or when a newer submission has been sealed for the same policy version. A stale note is KEPT and shown; carrying it to the current subject is a deliberate act (POST …/reassociate), never something this route does silently.
An empty list means YOU have written nothing here. It says nothing about any other reviewer, and nothing about the submission.
Authorizations
MeshQu API key passed as a bearer token: Authorization: Bearer mqu_…. Mint one in the console (Settings → API keys).
Tenant UUID for multi-tenant isolation. Required on all authenticated routes — validated before authentication (middleware/tenant.ts), so a missing or non-UUID header returns 400 (MISSING_TENANT_ID / INVALID_TENANT_ID) before the API key is checked.
Path Parameters
Policy id. The submission must belong to it, or the request is a 404.
The sealed submission the note is about. This is the review IDENTITY — not the policy version, which is a mutable container that yields many sealed subjects over time.