TRANSACTIONAL TRUST · VERIFIED #030

The revocation was real. One verifier had not heard yet.

A regional proof-authority replica can remain internally consistent while being stale relative to the authoritative origin. After revocation, the same proof can therefore receive contradictory verdicts from different verifiers.

Authority split-brain

authoritative origin:
R1 / generation 8 / REVOKED

region-A:
R1 / generation 8 / REVOKED
→ REJECT

region-B:
R1 / generation 7 / ACTIVE
→ ACCEPT ❌

The proof, artifact, model bindings and compatibility predicate are identical. Only authority-view freshness differs.

Unsafe: trust the stale regional replica

region-B:
rule_active = true
rule_generation = 7
static proof bindings = valid
predicate = true

→ regional_proof_authorized
→ adoption rows = 1
→ HTTP 200
→ effect_count = 1
→ output = 30

The numeric output remains correct. The effect is nevertheless unauthorized by current origin authority.

Safe: require an authoritative generation watermark

region-B replica generation = 7
authoritative head = 8

7 < 8
→ stale_authority_view
→ adoption rows = 0
→ external effects = 0

A verifier does not need the complete revocation payload to fail closed. Evidence that a newer authoritative generation exists is enough to stop stale authorization.

Propagation restores convergence

region-B syncs generation 8
R1 = REVOKED

→ compatibility_proof_revoked
→ 0 rows
→ 0 effects

A fresh successor R2 proof at generation 9 then safely re-authorized the historical artifact and committed output 30 exactly once.

I79–I82

• I79 — Validation against a stale authority view ≠ current authorization.
• I80 — Revocation propagation is part of the consequence safety boundary.
• I81 — Regional authority views must prove currentness against a monotonic authoritative generation or hold.
• I82 — Split-brain authority verdicts require fail-closed reconciliation before consequence.

LOCAL CONSISTENCY ≠ AUTHORITY CURRENTNESS.

Evidence

GitHub Actions run: 31603943840
Artifact ID: 9144285482
Artifact digest:
sha256:fab0b5b45d82cfad8cdce00913e6e9a269e2c6b4cc139a3be366cea2ced52a9a
Score: 10/10

This is a deterministic protocol benchmark, not production safety certification or a vulnerability claim against PostgreSQL or another external product.