Carry one stale draft review finding to an explicit sealed subject
Copies one of your stale working notes onto the sealed subject named by the BODY’s target_submission_id under a new id, and deletes the stale original, in one transaction.
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.
The target is named, never inferred. The PATH names the stale note’s OWN (superseded) subject; sealed rows are immutable, so that subject can never itself become current, and the target must therefore be a DIFFERENT sealed submission the reviewer chooses — this route never defaults to the newest one on their behalf. An unresolvable target_submission_id (wrong tenant, wrong policy, or a different policy version than the note’s own subject) is 404. A target naming the SAME subject as the path, or a target that is itself no longer current for its version (withdrawn/returned, or already superseded by something newer), is refused 422. A target whose actual sealed legs disagree with the body’s expected_candidate_revision / expected_review_package_digest — the list the reviewer chose it from having gone stale in the meantime — is refused 409 naming the leg, the same protection the PUT route gives an ordinary save.
Deliberate, never silent. Nothing re-points a note on its own. A note that is NOT stale is refused 409 DRAFT_FINDING_NOT_STALE, because there is nothing to carry it to.
The location is re-resolved against the TARGET. A candidate_rule code that does not exist in the target’s sealed candidate_policy, or a source_unit whose item or unit is not in the target’s sealed source_manifest, becomes package, and the old location travels in reassociated_from so the note says where it came from — together with the OLD submission id, so a reassociated note names both what it pointed at and which sealed subject it pointed at that from.
Carrying a note is not carrying a reading. reassociated_from RECORDS that the reviewer moved their own text; it does not establish that anything they concluded about the earlier subject holds for this one. A corrected candidate is a new subject and a new review.
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}$Body
Names the sealed subject to carry one stale working note to. The reviewer chooses it from the sealed subjects of the same policy version — this route never defaults to the newest one on the caller's behalf.
Names the sealed subject to carry one stale working note to. The reviewer chooses it from the sealed subjects of the same policy version — this route never defaults to the newest one on the caller's behalf.
The sealed submission to carry this note to. Must be a DIFFERENT sealed submission of the SAME policy version as the note's own (stale) subject — never the path's own submission, which the request is refused 422 for naming. An id that does not resolve to a sealed submission of that policy and version is refused 404.
The candidate revision the reviewer believes the TARGET carries, read from the list the console offered them. A disagreement with the target's actual sealed row is 409 CANDIDATE_REVISION_MISMATCH — the same stale-read protection the PUT route gives an ordinary save, so a target list fetched a moment too early cannot silently carry a note onto the wrong subject.
x >= 1The package digest the reviewer believes the TARGET carries. A disagreement is 409 REVIEW_PACKAGE_DIGEST_MISMATCH.
^[0-9a-f]{64}$Response
One durable working note. RECORDS what one reviewer typed about one exact sealed subject and has not recorded. DOES NOT ESTABLISH anything — not that they read anything, not that the note is right, and nothing whatever about the policy or the source. Not evidence, not a receipt field, excluded from every digest and export.
One durable working note. RECORDS what one reviewer typed about one exact sealed subject and has not recorded. DOES NOT ESTABLISH anything — not that they read anything, not that the note is right, and nothing whatever about the policy or the source. Not evidence, not a receipt field, excluded from every digest and export.
^[A-Za-z0-9._:-]{1,200}$Leg one of the subject.
Leg two, as SEALED.
x >= 1Leg three, as SEALED, under meshqu-review-package/v1.
^[0-9a-f]{64}$The stable identity of the human who wrote the note (user:<uuid>), stamped from their session. Nobody else reads this note — not a co-reviewer, not a tenant admin.
Which of the two record lists this note is destined for. proposed belongs to a correction — but it is NOT required here, deliberately: a note is saved while it is still being typed, and refusing a half-written correction would lose the sentence the reviewer was in the middle of. The review-record route requires it at the moment the note is submitted, which is the moment it matters. Choosing a kind here commits the reviewer to nothing — nothing is recorded until they submit a review record.
finding Which slot of the sealed subject the note is filed against: one of the ten ruled component names (ruling B2), or package for an observation about the submission as a whole. Same closed set as a review record item, because a note becomes one.
source_manifest The reviewer's own materiality classification, from the preregistered protocol's scoring vocabulary. RECORDS the classification; establishes nothing about whether it is right — that comparison is the blinded run (PWB-026), not a working note.
MATERIAL Free text, stored exactly as typed. It is the reviewer's own working note, never an instruction the server acts on, and nothing reads it except its author.
1 - 4000Where in the sealed subject the note points (contract §3). The kind fixes which other fields carry meaning; a field belonging to another kind is ignored by the checks that kind does not run.
The subject legs and location this note was carried FROM, when it was carried. RECORDS the carry; establishes nothing about the earlier reading applying to the new subject — it does not.
The last save. There is no version history of a note; a note is a note.
True when the sealed subject this note names is no longer the one in front of the reviewer. A stale note is KEPT and shown, and it cannot be carried into a review record — the record route runs its own three-leg check and refuses, which this surface does not weaken.
Which disagreement makes this note stale, when it is. Derived at read time against the live sealed row and never stored, so it cannot drift away from the truth. The first three name a leg of the subject identity; the last two name what happened to the subject itself.
subject_missing