Instruction approval
What you'll find here
The operator review contract for approving or rejecting distilled instruction proposals, including review receipts, promoted constraints, and the override path for stale or contradicted items.
Approval is the authority boundary.
Registration and ingestion discover candidate instructions. Approval is the first step that can make a distilled instruction govern a case file, handoff, onboarding context, or compiled prompt.
Review commands
craik instructions list --status proposed
craik instructions show <item-id>
craik instructions approve <item-id> --rationale "Required for release work"
craik instructions reject <item-id> --rationale "Conflicts with project policy"
listshowapproverejectReview commands run through the active operator session. The runtime records who made the decision, when it happened, the rationale, and the proposal state at review time.
Direct runtime API calls also require an active operator session by
default. Test harnesses or tightly controlled internal tooling may opt
into unbound approval by passing allow_unbound=True; production
extensions should leave the default in place so the recorded operator
identity is bound to the current session.
Approval operator checks raise typed InstructionApprovalError
subclasses with stable code values:
operator.identity.missing, operator.session.missing, and
operator.session.mismatch. Missing-session errors also expose a
remediation hint. Session-related failures emit a structured audit
hook with the proposal ID and a short hash of the supplied identity,
never the active session subject.
Receipts
craik.instruction_promotion_review links the decision to the
proposal, policy envelope, receipt chain, handoffs, and active
constraint when one is created.
Approve
Moves a fresh proposal to governing and creates a craik.promoted_instruction_constraint.
Reject
Records a denial and keeps the proposal out of active runtime context.
Repeat approve
Returns the existing review and constraint instead of duplicating authority.
Deferred approve
Requires an explicit override when the item is stale or contradicted.
Active constraints retain proposal ID, source ID, source snapshot ID, provenance IDs, evidence IDs, review links, and a receipt HMAC. Downstream consumers must read governing constraints from the approval API instead of raw proposal rows. Reviews with missing or invalid receipt HMACs are treated as needing re-approval and are excluded from active runtime context.
Overrides
Stale or contradicted proposals are blocked from normal approval. An
operator can approve one only by setting --override and providing
--override-rationale.
craik instructions approve <item-id> \
--override \
--override-rationale "Accepted while policy document migration is in progress"
Override rationale is mandatory.
The review records whether a stale guard or contradiction guard was bypassed. Missing rationale fails before the proposal becomes governing, and the resulting review is integrity-protected before it is stored.
Informational override rationale can also be recorded for non-stale, non-contradicted approvals. In that case the review stores the rationale while keeping the stale and contradiction override flags false.
Runtime consumers
Approved constraints flow into:
Case files
The distillations evidence section.
Compiled prompts
The Active instruction constraints section.
Onboarding
Active project constraints and stale warnings.
Handoffs
Constraint IDs carried forward for audit.
If a source later changes or disappears, stale invalidation defers the affected proposals and excludes them from active runtime context until they are reviewed again.