Module check 

Check records — the engine-recorded act of verification (agent-trust plan 14).

A check is an agent recording “entity E checked, verdict ok | failed, via method M”. It is engine state, never entity content: absent from markdown and content_hash, and it produces no mem commit — checking-touches-nothing is what makes check-staleness computable. Records are append-only JSONL under the workspace store (.memstead/state/checks/checks.jsonl); a newer check of the same kind supersedes older ones for state derivation but never erases them (kinds derive independently, see CheckKind).

Unlike the friction ledger next door, recording here is NOT best-effort: a check the ledger failed to persist must refuse — the caller believes the act was recorded, and a silently dropped check is exactly the self-report dishonesty this tier exists to end. For the same reason there is no rotation cap: check history is the substrate process state derives from, not disposable telemetry.

Each record carries plan-13 provenance (actor, client, declared role) plus the entity’s content_hash at check time. State derivation compares that hash against the current one:

• no record → never_checked
• hash matches, ok → checked_ok
• hash matches, failed → check_failed
• hash differs → check_stale (whatever the verdict was, it no longer speaks to the current content — stated, never silently carried forward)

A conformance record additionally carries the mem’s schema pin and goes stale when the pin moves (derive_state_pinned): the prose it judged against is no longer the prose in force.

Structs

CheckLedger

Append/read handle for a workspace’s check ledger.

CheckRecord

One recorded check — the full ledger line.

Enums

CheckKind

A check kind from the closed vocabulary.

CheckState

Derived per-entity check state.

Verdict

A check verdict from the closed vocabulary.

Constants

CHECK_KINDS

The closed kind vocabulary. verification is the default and today’s behaviour: “I checked this entity’s content”. conformance is the semantic judgment “this entity satisfies its type’s schema prose (write_rules / writing_guidance)” — recorded with the mem’s schema pin, stamped by the engine at record time, so the verdict’s freshness against both the content AND the prose version stays computable. A third kind is a separate decision; closed kinds keep health aggregation well-defined, matching the closed verdict vocabulary.

VERDICTS

The closed verdict vocabulary. Nuance goes in the method note or in process-mem entities — never in new verdict values.

Functions

check_ledger_path

The ledger file path for a workspace.

derive_state

Derive the state from the newest record (if any) and the entity’s current content_hash. Hash-only: this is the verification derivation, and stays the whole story for that kind — a schema re-pin never stales a verification verdict.

derive_state_pinned

Derive the state with schema-pin awareness: beyond the hash comparison, a record that carries a schema_ref (a conformance record) is stale when the mem’s current pin differs from the recorded one — the prose the verdict judged against is no longer the prose in force. A mem that has since lost its pin entirely stales the verdict the same way. Records without a schema_ref (every verification record) are unaffected by the pin argument.