teleo-infrastructure/docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md

Approved Claim Bundle Isolation Canary

Status: pass

Working Target

A Cory-approved strict bundle must move through a separate reviewer credential, an immutable approval snapshot, and a narrow apply credential before exact claim/source/evidence/edge/reasoning-tool rows become canonical. A stale payload, replay, hash collision, or direct privilege bypass must leave no partial rows.

Final Runtime Proof

• Generic bundle: 37/37 checks passed. Its exact payload-controlled projection and exact table deltas were 2 claims, 2 sources, 2 evidence links, 1 edge, and 1 reasoning tool.
• Real Helmer bundle: 37/37 checks passed. Its exact payload-controlled projection and exact table deltas were 5 claims, 13 sources, 17 evidence links, 7 edges, and 1 reasoning tool.
• Helmer source proposal: a64df080-8502-42e2-98f4-9bbdecb8da73; strict child proposal in the final isolated run: 87344d36-5005-5d88-a04c-067aeceda3c3.
• kb_review approved the exact pending type and full JSON payload as mapped reviewer m3ta; the immutable approval row matched the proposal ledger.
• kb_apply could not directly update proposal status/payload, immutable approval rows, or existing claim_evidence rows.
• Mutating the approved ledger after SQL generation made the stale apply fail before canonical writes; restoring the ledger left the immutable approval unchanged.
• Replay was refused. A different source ID reusing an existing source hash was refused, and its proposal/approval remained intact with zero partial rows.
• Every payload-controlled persisted field, including weights, roles, owners, tags, hashes, and relationships, matched the reviewed payload. Exact table deltas also exclude unexpected extra rows under unrelated IDs.
• The migration readback proves one expected signature per gate function, no legacy overload, no protected-role membership, no object owned by a login role, and the exact reviewer/apply execute split.

Isolation And Cleanup

• Both runs used a new unexposed postgres:16 container built from a read-only schema/reference copy of live teleo; no cluster-wide role was created in the production teleo-pg instance.
• The wrapper issued read-only queries to live teleo-pg; endpoint counts were identical before and after each final run, with zero deltas for all six tables: claims=1837, sources=4145, claim_evidence=4670, claim_edges=4916, reasoning_tools=17, kb_proposals=26. This is endpoint-count evidence, not a claim that every live row byte was compared.
• leoclean-gateway.service stayed active/running, MainPID=2999690, NRestarts=0.
• Inner clone databases, outer Postgres containers, temporary workdirs, and the remote source bundle were removed. Independent name/path readbacks found no residue after cleanup.
• Both receipts retain repo-relative SHA-256/size bindings for the apply, approval, prerequisite SQL, inner canary, and isolation wrapper source files; a local recomputation matched every retained hash.
• No Telegram message, production canonical apply, production permission migration, service restart, or runtime-profile write occurred.

Reproduce

Generic bundle:

scripts/run_approve_claim_isolated_container_canary.sh \
  --output docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.json

Real normalized Helmer bundle:

scripts/run_approve_claim_isolated_container_canary.sh \
  --normalization-json docs/reports/leo-working-state-20260709/helmer-approve-claim-normalization-current.json \
  --output docs/reports/leo-working-state-20260709/helmer-approve-claim-clone-canary-current.json

Evidence And Claim Ceiling

• Generic receipt: approve-claim-clone-canary-current.json
• Helmer receipt: helmer-approve-claim-clone-canary-current.json
• Lossless normalization: helmer-approve-claim-normalization-current.json
• Inner harness: scripts/run_approve_claim_clone_canary.py
• Isolation wrapper: scripts/run_approve_claim_isolated_container_canary.sh

This proves the repo-owned review/apply lifecycle at isolated runtime tier. It does not mean the new code, reviewer/apply roles, or permission migration are deployed on VPS production, and it does not mean Helmer is canonical there. kb_apply remains an operator-only trusted canonical writer; the proof covers the supplied tool and privilege matrix, not a compromised apply credential.