Skip to main content
Version: MVP

Distilled instructions

5 min readReferenceUpdated 2026-05-21

What you'll find here

The lifecycle, category taxonomy, provenance links, and snapshot rules behind Craik's distilled instruction proposals. Use this page to understand what the runtime stores before an instruction can become an active constraint.

Distillation creates proposals, not authority.

Parsed instruction text becomes reviewable evidence. Only an explicit approval can move a proposal into the governing set used by case files and compiled prompts.

Lifecycle

Status
Authority
Meaning
proposed
inactive
Extracted, provenanced, categorized, and waiting for operator review.
governing
active
Approved by an operator and backed by a promoted instruction constraint.
rejected
inactive
Denied by an operator with a review receipt.
deferred
inactive
Held back because the source is stale, missing, newly observed, omitted, or contradicted.
superseded
inactive
Replaced by a newer proposal or review path while preserving audit history.

Stale or contradicted proposals remain visible for review, but they do not participate in list_governing, case-file assembly, or prompt compilation unless an operator approves them with an explicit override rationale.

Categories

Craik categorizes extracted statements deterministically. Each proposal records the matched rule name and confidence so later reviewers can explain why a statement entered a category.

CategoryUse
policyApproval, governance, or authority requirements.
security_ruleSecret handling, sandboxing, safety, or security-sensitive requirements.
boundaryScope, ownership, repository, or authority boundaries.
commandRequired or forbidden commands and validation steps.
instructionGeneral runtime guidance for agents.
handoff_ruleRequirements for durable handoff content or timing.
memory_ruleRules for memory reads, writes, proposals, and promotion.
preferenceStable user, team, or project preferences.
stale_riskWarnings that context may become outdated or unsafe.

Unclassified candidates are not promoted into proposals silently. They are returned in ingestion summaries as warnings for operator review.

Provenance

Every proposal links back to the source text that produced it:

Source ID

The registered instruction source.

Snapshot ID

The observed source hash state.

Provenance IDs

The extracted source ranges.

Evidence IDs

Receipts and supporting review records.

Excerpt hash

A stable digest of the extracted statement after newline normalization.

Summary

The first non-empty statement line, capped for display.

Line ranges are precise when the parser can identify stable lines. Partial ranges are rejected because they make review ambiguous. When a stable range is not available, the provenance record falls back to the source-level reference instead of inventing a line number.

Snapshot linkage

craik.instruction_source_snapshot records whether a registered source is new, unchanged, changed, or missing. Proposal state follows that snapshot history:

  1. An unchanged source can keep its existing proposals reviewable.
  2. A changed source defers prior proposals until the new text is reviewed.
  3. A missing source defers proposals derived from that source.
  4. A newly observed source produces new proposed items rather than active constraints.

Case files and prompts consume only governing constraints. Compiled prompts render them in the Active instruction constraints section as (category) `statement` [source_id @ path:line-range], sorted by category, source ID, and statement.

What's next