The vocabulary the rest of the docs assume. Each term maps to one place in the kernel and one guarantee that the tests pin.

The ladder

Every piece of work descends a fixed ladder of rungs. The kernel records exactly one winning rung per decision, and the label must describe what actually ran.

Rung	Input	Success	Tokens	Deterministic
`structured`	Subject fields, work type, status	Required fields present, or a non-reasoning rule hit	0	Fully
`pattern`	Authored or compiled WHEN clause	Exact WHEN match on an active authored pattern	0	Fully
`regex`	String fields	Pattern match	0	Fully
`parser`	Nested objects	Parse succeeds	0	Fully
`learned`	Subject against active, operator-promoted patterns	WHEN matches on the learnable feature set; proposed never fires	0	Fully
`llm`	Residual packet, on a reasoning step only	Gateway returns schema-valid JSON	Actual usage	No; replay uses the recorded decision
`judgment`	Human-required step or policy	Human choice recorded	0	Human
`failure`	Plumbing residual	Never silently recovered; visible failure or the judgment queue	0	Fully

A semantic value remains in the enum so historical rows parse, but the live kernel throws if asked to record it. pattern (authored) and learned (earned) are distinct on purpose: the first is what someone wrote, the second is what the replay gate certified.

Step kinds

Every process step declares exactly one kind. Doctor refuses a step without one.

Kind	May call a model	Rungs it walks	Residual goes to
`plumbing`	Never	structured, pattern, regex, parser, learned	The judgment queue or a visible failure. A plumbing step cannot stage an action.
`reasoning`	Yes, under a token and output contract, after the deterministic rungs	The plumbing rungs, then llm	Judgment. Reasoning stages; it never executes.
`judgment`	No	None	A person records a choice; the process continues.

A plumbing step that references a skill with allow_llm: true is a doctor error. If interpretation is required, the process must declare a reasoning step. A model call with no key and no mock produces judgment, not llm.

Staged actions and confirm

Reasoning, a learned pattern, or an external proposal through the SDK can stage an action: a row in staged_actions with status pending. Staging is a suggestion. Confirm is execution of a side effect, and it is a separate act. The row moves pending → confirmed → executed, or is dismissed, or is marked invalidated_dependency when its authority went stale between confirm and execution.

These constraints hold at every stage:

An action may be staged only if it appears in the resolving skill's action_ids. A payload may select only among those bound ids.
auto_confirm on an action definition lets the kernel confirm its own staging inside a process, in the same transaction as the insert. It does not apply to money_legal or to proposals from the govern surface.
An action id outside a learned pattern's envelope does not stage, confirm, or execute.

The outbox

The transactional outbox is the only job mechanism. Confirm enqueues staged.confirmed in the same SQLite transaction as the status change; scheduled jobs (email poll, resurface, compliance, calibration, reply drafts, genesis) are outbox rows too. A drain runs pending rows with a lease and an idempotency key. A handler that throws is retried; after 8 attempts the row is dead_letter and stays visible. Direct calls are only latency optimisations, so a process that slept catches up on the next drain.

Pattern lifecycle

A pattern is a WHEN clause over learnable features and a THEN (a verdict or an action). The executable row has a miner lifecycle (proposed | active | retired). A promoted pattern is wrapped by a Verified Autonomy Artefact (VAA) that carries two orthogonal states. The VAA lifecycle adds verified between proposed and active, and the two lifecycles always agree on whether a pattern may fire.

VAA states

lifecycle:  proposed → verified → active → retired
standing:   unrevoked, or revoked

State	Meaning	Can fire
`proposed`	Candidate from mining or induction.	No
`verified`	Replay passed. Authority not granted.	No
`active`	Authority granted through `promotePattern`, the only function that writes it.	Only while unrevoked
revoked	Revoked on drift or counterexample. Stops firing until a person revalidates and promotes it again.	No, even while lifecycle is still active
`retired`	Permanently out. The miner will not re-propose that signature.	No

Verified is not authorized, and standing on its own grants nothing. The full path from a human judgment to an active pattern is on How authority is earned.

The envelope

Every promoted pattern carries an authority envelope:

Envelope

{ class: inform | action | money_legal, permitted_action_ids, confirm_required }

It is checked when an action is staged, when it is confirmed, and again inside the outbox handler. The envelope can only narrow what the registry allows. money_legal always needs a person. The rule that decides execution is machine-checked and pinned by tests.

Proof-state binding

When a pattern is promoted, its authority is bound to the registry it depends on. If that changes afterwards, the pattern is skipped before any side effect: at fire time the ladder continues without it; at confirm the binding travels with the staged row; and inside the outbox handler it is checked once more. A row whose binding fails there is marked invalidated_dependency and the work returns to judgment.

Deterministic evaluation

Rules, the kernel, and patterns take time from EvalContext ({ now }). They do not read Date.now(), Math.random(), or an argument-less new Date(). A lint enforces this across packages/rules, kernel, patterns, and govern. Because of it, engine replay-decision can re-run any stored decision with the same context and either match bit for bit or name the dependency that changed.

money_legal

A field with sensitivity: money_legal in the field registry, or an action with money_legal: true, requires a human confirm regardless of confidence, step kind, envelope, or pattern standing. Such fields are refused as learning features, cannot appear in a WHEN, and cannot be auto-confirmed.

Concepts