List the human review records of a sealed review submission
Every judgment recorded against one sealed subject, newest first.
RECORDS that one named human wrote these findings, these corrections and this one package-level disposition against this exact sealed subject, at this time.
PROVES that the record names that subject. Nothing more. This is research evidence, not approval: it does not establish that the policy is correct, ratified, approved, activated or verified; that the source is true or complete; or that the reviewer was competent, independent or unblinded. Ruling B5 keeps this wave review-only.
More than one record is normal and is not a conflict. Records are append-only and there is no edit path, so a reviewer who changes their mind records a new judgment and the earlier one stays legible. Two reviewers disagreeing about one subject is a fact about the review, and this route reports it rather than resolving it — the beta has no adjudication step and inventing one here would manufacture a result.
An empty list means no judgment has been recorded. It does not mean the subject was accepted.
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 judgment is recorded against. This is the review IDENTITY — not the policy version, which is a mutable container that yields many sealed subjects over time.