Issue an authoring capability
Mints a new DRAFT policy version under policy_id — rules copied from source_policy_version_id, created_by set to the issuing human — and, in the same transaction, creates an authoring capability record bound to THAT minted version, a closed set of authoring actions, a set of granted source items and a validity window. The bound policy_version_id and policy_version_number are chosen by the server and returned; a caller cannot name them. Access is decided by two gates, in this order, both answering 403: the scope check runs first, so a principal without the api-keys:admin scope — including an authoring:capability carrier key — is refused FORBIDDEN and never reaches the second gate; a principal that HAS api-keys:admin but is an API key rather than a verified human session is then refused HUMAN_PRINCIPAL_REQUIRED. Only a verified human principal holding api-keys:admin reaches the handler. The subject key named in the body must hold the authoring:capability scope and must not hold policies:read or policies:write. Returns 404 AUTHORING_CAPABILITY_SOURCE_VERSION_NOT_FOUND when the source version is not a version of that policy in this tenant, and 409 AUTHORING_CAPABILITY_DRAFT_CONFLICT when the policy already has an open draft or submitted version, so no shell can be minted. Five further 400s, none of which writes anything. Two refuse a record that could never be used, because the subject key cannot authenticate at all: AUTHORING_CAPABILITY_SUBJECT_REVOKED (it is revoked or inactive) and AUTHORING_CAPABILITY_SUBJECT_EXPIRED (its expires_at is at or before now). One refuses a window that could never open: AUTHORING_CAPABILITY_WINDOW_ELAPSED (valid_until is at or before now). One refuses a window that outlives its carrier: AUTHORING_CAPABILITY_WINDOW_OUTLIVES_SUBJECT (valid_until is after the subject key’s expires_at, so the part of the window past that instant is unusable while the part before it is not — a window ending exactly at the expiry is accepted, and a key with no expires_at does not constrain the window). One fails closed on an expiry the platform cannot read: AUTHORING_CAPABILITY_SUBJECT_EXPIRY_UNREADABLE (the subject key’s expires_at is not a readable timestamp, so whether it can still authenticate cannot be established, and issuance refuses rather than assumes). These are evaluated in one order and the first that applies is the answer: the subject key must exist, then hold the right scopes, then be live, and only then is the window checked — against the clock, then against the key’s expiry.
500 AUTHORING_CAPABILITY_READBACK_FAILED means the capability WAS committed and only the read of it afterwards came back empty or failed (details.committed is true); read it back rather than issuing again. A 404 on this route means nothing was written.
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.
Body
Issue an authoring capability. source_policy_version_id names the EXISTING version whose rules are copied into a new draft version minted by this request; the capability binds to the MINTED version, whose id and number the server chooses and returns in policy_version_id / policy_version_number. valid_until must be strictly after valid_from (AUTHORING_CAPABILITY_INVALID_WINDOW), strictly after the time of the request (AUTHORING_CAPABILITY_WINDOW_ELAPSED), and at or before the subject key's expires_at when it has one (AUTHORING_CAPABILITY_WINDOW_OUTLIVES_SUBJECT). valid_from may be in the past: it records when the delegation began. The subject key named by key_id must additionally pass the subject-key checks the endpoint description lists — it must not be revoked or inactive, it must not have expired, and if it carries an expires_at the server must be able to read it (a key with no expires_at is accepted). Body coherence is checked first (AUTHORING_CAPABILITY_INVALID_WINDOW), then the subject key, then the two clock rules above.
Issue an authoring capability. source_policy_version_id names the EXISTING version whose rules are copied into a new draft version minted by this request; the capability binds to the MINTED version, whose id and number the server chooses and returns in policy_version_id / policy_version_number. valid_until must be strictly after valid_from (AUTHORING_CAPABILITY_INVALID_WINDOW), strictly after the time of the request (AUTHORING_CAPABILITY_WINDOW_ELAPSED), and at or before the subject key's expires_at when it has one (AUTHORING_CAPABILITY_WINDOW_OUTLIVES_SUBJECT). valid_from may be in the past: it records when the delegation began. The subject key named by key_id must additionally pass the subject-key checks the endpoint description lists — it must not be revoked or inactive, it must not have expired, and if it carries an expires_at the server must be able to read it (a key with no expires_at is accepted). Body coherence is checked first (AUTHORING_CAPABILITY_INVALID_WINDOW), then the subject key, then the two clock rules above.
1 - 5121policy.read, draft.edit, draft.validate, review.submit, review.withdraw_request, review.retrieve, case.preview 1 - 256What the agent DECLARES about itself, recorded on the capability at issuance. It is inside the capability digest preimage and therefore covered by the grantor signature, so it cannot be edited after issuance without breaking the record. That is the whole of the property: it does not establish that the named model exists, that it is the model that authenticated, or that it produced anything. Never read by any admission decision.
Response
An authoring capability record: a grant, or the revocation that supersedes one.
An authoring capability record: a grant, or the revocation that supersedes one.
grant policy.read, draft.edit, draft.validate, review.submit, review.withdraw_request, review.retrieve, case.preview ^[0-9a-f]{64}$What the agent DECLARES about itself, recorded on the capability at issuance. It is inside the capability digest preimage and therefore covered by the grantor signature, so it cannot be edited after issuance without breaking the record. That is the whole of the property: it does not establish that the named model exists, that it is the model that authenticated, or that it produced anything. Never read by any admission decision.
Present only on a grant the server minted when a draft supersession carried an authoring capability to the successor draft: the grant this one continues. Inside the capability digest preimage.