# CAIN-42 BFT engine forensic report (2026-10-05, HEAD 922fb7bb7d)

Self-assessed by one session. Numbers come from this run's artifacts. Clean-room = same author, zero CAIN
imports. Not a legal opinion.

**1. What exactly is CAIN's BFT engine?**
A Python PBFT state-machine-replication engine (`platform-gateway/cain_pbft_engine_33.py`, `HardenedPBFTEngine`).
It has three-phase ordering, view change, checkpoints, a WAL, certified state transfer, Ed25519 messages pinned
to a membership configuration, and quorum certificates. It runs inside every replica's full gateway process.
The hosted gateway uses it to order a SHA-256 commitment of each governance decision, then verifies the 2f+1
commit certificate itself before permitting.

**2. What is conventional PBFT/BFT?**
All of the consensus core: ordering, quorums, view change, checkpoints, state transfer, dedup, WAL, quorum
intersection. See baseline/BFT_BASELINE_CLASSIFICATION.json.

**3. What is actually CAIN-specific?**
The coupling to governance, not the consensus:
- a fail-closed permit precondition on a gateway-verified certificate;
- safety-asymmetric deferral of non-permits;
- quorum-committed authorization snapshots with a local revocation epoch and later Merkle anchoring;
- evidence objects that say what consensus did NOT evaluate.

**4. What is implemented?**
All of the above. The DAG, the hybrid post-quantum certificates and the fast path are libraries, off on the
hosted path.

**5. What is tested?**
- 20/20 engine test vectors.
- 14/14 critical races at 100 repetitions each (one race UNKNOWN: not modelled), with deterministic replay.
- 10/10 governance-coupling checks on the real engines and the real gateway functions.
- 39 existing BFT test files pass.

**6. What is independently reproduced?**
In-process only. A same-author clean-room judge re-verified 7722 commit certificates from the race runs
plus every vector, with zero violations. No third party has reproduced anything.

**7. What fails?**
- LIVE LIVENESS. Both multi-region clusters have been NOT_OPERATIONAL in their signed hourly proofs since
  2026-10-03. cain-mr-02 is in a view-change livelock with exactly f=1 replica down (diagnosis by peer session -54).
- Neither cluster runs HEAD. Deployed: cain-mr-01 -> 81bdf841, cain-mr-02 -> 948b1895, sandbox (cain-sbx) -> 15d12dab.
- With 30% of messages held and reordered in-process, only 131/200 requests committed (performance run).

**8. What remains unknown?**
- The root cause of the cain-mr-02 livelock (hypothesis: node-3 rejects every message, e.g. clock skew > 60 s).
- Behaviour under a Byzantine gateway: the design does not cover it.
- Execution-receipt binding.
- RT-BFT-08 (dependency invalidation).
- Live latency today.

**9. Strongest technical effects.**
- BFT-IP-0001: authorization in about 0.2 ms from a quorum-committed snapshot; revocation without quorum.
- BFT-IP-0002: no permit without a gateway-verified certificate; a lying replica cannot create a permit.

**10. Difficult to reproduce?**
The engine at its tested robustness: about 6-12 engineer-months (judgement, see reproduction/). The
CAIN-specific layers: about 1-3 months each.

**11. Meaningful design-around resistance?**
None. Every candidate is EASY to design around (transparency logs, leases, short-TTL tokens).

**12. Possible IP candidates.**
BFT-IP-0001..0008. Score classes: 5 DEVELOPING, 3 MATERIAL. The best ones (BFT-IP-0001/0002/0005) are at the bottom of
MATERIAL, and none is STRONG.

**13. Better kept as trade secrets.**
The snapshot data plane's implementation details (TTL/anchoring/multi-worker revocation handling) and the
liveness tuning learned from soaks.

**14. Should become open protocol.**
The decision-commitment format, the QC format and the public zero-CAIN verifier. Their value is that other
people can check them.

**15. Real commercial utility.**
Auditability of authorization decisions (a quorum-signed, tamper-evident record) for regulated buyers. It is
UNVALIDATED: there is no customer.

**16. Required before claiming production-grade Byzantine governance.**
- Clusters operational for 30+ days on HEAD.
- Replicas run by DIFFERENT operators/providers. One operator makes BFT equivalent to a signed log.
- Replicas validating governance (or a second independent evaluator).
- An execution receipt bound to the certificate.
- Removal of the unpinned-key fallback.
- An external pen test.

**17. For qualified legal counsel.**
Whether the BFT-IP-0001 combination (quorum-committed authority + local revocation epoch + per-use Merkle
anchoring) has anything protectable after a real prior-art search. Leases and capability caching are close
prior art.

**18. Evidence that would materially increase confidence.**
- A 30-day signed liveness record.
- A third party running the public verifier and the judge.
- A multi-operator deployment.
- Live p50/p99 under load.

**19. What should CAIN STOP building?**
- More consensus variants (DAG, fast path, PQ) while the two live clusters are down.
- More "evolution" layers on top of an engine that is not running.

**20. Highest-value next engineering action.**
Restore liveness. Deploy HEAD to one cluster, diagnose the cain-mr-02 node-3 rejection, and add a
livelock-escalation test that reproduces "f=1 down + one replica deaf". Only then claim anything about
production BFT.