Discard one of your draft review findings
Deletes one of your working notes outright.
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.
A hard delete is permitted precisely because a note is not evidence. Nothing in any review record is touched by this route, and a record already written stays exactly as it was — records are immutable and this surface does not reach them.
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.
The reviewer client's own handle for this note, in the same spelling a review record's item id uses. Client-issued: the server does not mint it, and it is unique only within one owner's notes on one subject. It is the SAME id the item will carry if the note is later recorded, so the link between a note and the item it became is legible without a pointer from the immutable side.
^[A-Za-z0-9._:-]{1,200}$Response
The note is gone. A hard delete is permitted precisely because a working note is not evidence; nothing in the review record is touched, and any record already written stays exactly as it was.