[PIR][WP4] Add TARL five-operation ledger (add/ignore/revise/reject/defer) onto ADR-194/047 proof-gated memory writes

Epic: #837 · Plan: docs/research/perpetual-intelligence-runtime/03-program-plan.md

Goal

Implement TARL's five executable memory operations and its accepted/pending/rejected ledger states as a layer on top of memory writes that are already proof-gated by ADR-194/047.

This is deliberately smaller scope than the program's first pass assumed: the underlying proof gate already exists, so this WP adds the transactional ledger semantics above it rather than building gating from scratch.

Evidence

TARL (Transaction-Aware Reliable Ledgers) — arXiv:2608.03699, submitted 2026-08-04. Each incoming statement maps to exactly one of five executable actions:

add / ignore / revise-outdated-belief / reject-unreliable / defer-for-verification

maintaining accepted, pending, and rejected ledgers. Explicitly framed as reducing memory pollution and limiting cumulative corruption — this is the memory-poisoning defense, and it is what satisfies invariant 2 ("every memory change is transactional").

Always spell out "TARL (Transaction-Aware Reliable Ledgers)" on first use. The acronym is heavily overloaded: Taint Analysis and RL (arXiv:2005.03813), Target-Aligned RL (arXiv:2603.29501), a separate test-time-adapted RL concept, and an unrelated GitHub repo. None relate to agent memory ledgers.

Acceptance criteria

• All five TARL operations implemented, with accepted / pending / rejected as distinct queryable states.
• A poisoning-style adversarial test, per TARL's own evaluation, shows rejected and deferred writes never reach transactional memory. This is the criterion that matters most.
• Contradicting-but-credible statements trigger revise-outdated-belief rather than a silent add.
• Every transition is transactional — no partial application is observable.
• Every ledger transition emits an RVM witness record conforming to the ADR-134 witness schema (cite ADR-134-witness-schema-log-format.md by filename — ADR-134 is one of the duplicate numbers WP0a is remediating).
• No RVF write is possible without a corresponding witness entry — enforced at the API boundary, with a bypass-attempt test.
• The witness chain is independently verifiable: a verifier reconstructs it from persisted records alone, with no access to the writing process, and detects an injected tamper.
• Constitutional capability-expansion approvals (WP11) are logged distinctly from ordinary transitions, so WP12 can query "zero unapproved capability expansion" directly rather than inferring it.
• npx @claude-flow/cli@latest security scan clean — this touches capability tables and witness signing.

Dependencies

WP3 (#839). Coordinates with WP8 (ruvnet/rvm#35) on the shared witness record schema — target the agreed schema, not a soon-to-change one. Blocks WP5 and WP12.

Start with docs/research/perpetual-intelligence-runtime/03-program-plan.md and ADR-134-witness-schema-log-format.md, then trace the existing ADR-194/047 proof-gated memory-write entry point. Use the acceptance criteria to define completion: five queryable ledger operations and states, transactional transitions, witness verification and bypass tests, distinct capability-expansion records, and a clean named security scan.