Retrieve a sealed review submission and its canonical components
The sealed subject plus the ten components in the ruled registry order, each carrying the EXACT canonical bytes that were sealed into that slot.
RECORDS which bytes occupied each named slot of this submission.
PROVES BYTE EQUALITY ONLY. component_digest is sha256(UTF8(canonical_bytes)), and the envelope of those ten reproduces subject.review_package_digest under meshqu-review-package/v1. That is the whole of the claim: it says these are the bytes that were sealed. It does not say the content is true, complete, correctly interpreted, reviewed by a human or authorised.
Source availability is reported SEPARATELY, and only when asked. Pass check_source_availability=true and each MeshQu-custody item in the sealed source_manifest is retrieved from custody and re-hashed against the digest the manifest sealed; the result appears in source_availability, one entry per item, bound to the exact resolution entry that was checked. Without the parameter every entry is NOT_CHECKED, which states that no check ran — it is not a finding about the bytes.
AVAILABLE_VERIFIED is the only state that follows a hash comparison, and it means the bytes were retrievable AT THAT MOMENT. It is not a guarantee of future availability and it says nothing about whether the source is the right source. NOT_FOUND, ACCESS_DENIED, DIGEST_MISMATCH, ERASED, OPERATIONAL_FAILURE and NOT_CHECKED are six distinct answers that never collapse into one another, and none of them is an approval. An unavailable source does not rewrite the sealed subject: the historical digest is unchanged and the current status sits beside it.
These observations are not part of any component and are in no digest. This route never returns bytes; the reviewer-only .../source-items/:sourceItemId/bytes route does (PWB-036).
The bytes are returned verbatim and are not re-serialised, re-ordered or pretty-printed; any of those would produce a string whose digest no longer matches.
Supply expected_id, expected_revision and expected_digest together to assert the identity a judgment was recorded against. All three or none — a partial expectation is refused with 400 rather than half-checked. A disagreeing leg returns 409 with a code naming THAT leg, so “a different submission” is never reported as “the bytes changed”. A match means the judgment names the same subject; it does not mean the judgment is correct.
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
The sealed submission id. This is the review IDENTITY — not the policy version, which is a mutable container that yields many sealed subjects over time.
Query Parameters
x >= 1^[0-9a-f]{64}$When true, each MeshQu-custody source item is retrieved from custody and re-hashed against the digest the manifest sealed, and the result is reported in source_availability. When absent or false, every item is reported as NOT_CHECKED — which is a statement that no check ran, not a statement about the bytes. Items whose custodian is not MeshQu are always NOT_CHECKED: this API resolves no external locator and makes no claim about a custodian's store.
Response
Default Response
The ten components in the ruled registry order. Recomputing sha256 over each canonical_bytes reproduces every component_digest, and the envelope built from those ten reproduces subject.review_package_digest.
One observation per source item of the sealed source_manifest. NOT part of any component and NOT in any digest — this is the separate CURRENT availability status that sits beside the unchanged historical record.
Every entry is NOT_CHECKED unless check_source_availability=true was supplied, and NOT_CHECKED means exactly that: nothing ran. An unavailable source does not rewrite the sealed subject or the judgment recorded against it; it is reported here and nowhere else.
DERIVED, never stored. RETURNED iff a return row exists for this submission; SEALED otherwise. The machine is SEALED -> RETURNED, once. It says nothing about whether the package is good, current or reviewed.
SEALED The CORRECT_AND_RESUBMIT record the return named, or null when the submission has not been returned. This is the id the agent must supply as answers_record_id on its next seal.
The STABLE principal that returned it (user:<uuid>), or null. Display attribution travels separately and is not this field.
Which door the returner came through. tenant_admin is the ruled FALLBACK — ANY tenant admin. It does NOT mean a named second reviewer, an independent one, or one who read anything.
recording_reviewer Returns recorded on an EARLIER draft this version supersedes that no later seal in the lineage answers (ruling R-B: shown, not blocking). A later seal of this version is not required to answer them, and they do not block ratification. Absent when there are none.
Present when the draft-supersession lineage could not be followed (a cycle, more than 64 links, or a dangling link). newer_draft_observed and unanswered_lineage_returns are then incomplete or absent, and their absence says nothing. The seal and ratify routes refuse such a lineage.
true