Topology representation finalization — multi-axis design call

I'm finalizing the data representation for cubie's trust-admission topology, and I need you to reason across performance, formal-proof, deployment-class, and compliance axes together. Don't pick a single dimension — these all bind to each other and the wrong tradeoff in one axis breaks another.

== Background — what cubie is ==

Cubie is a formally-verified trust-admission gate that decides whether an inbound request (AI prompt, GPU job, packet flow, biomedical-device command) should be allowed. The admission decision is computed against a 108-bit ternary state representing 54 Rubik-cube cells x 2 bits each — 00 / 01 / 10 / 11 per cell meaning roughly void / FAIL / PASS / FLUID. The state lives inside a 192-byte CubeObjectV1 request envelope; the topology occupies the low 108 bits of a 128-bit packed manifold inside a 64-byte cache-line CubeFlit64.

The hot path must produce an admit/deny verdict in <= 20 ns (current pipeline 16.57 ns). Proof corpus has ~1,180 triple-kernel theorems across Verus + Coq + Lean 4. Foundational theorems (CUB-1207e epoch rotation, CUB-1213/1214/1215/1216 Singmaster pre-gate, CUB-1382/1432 telemetry, CUB-1937..1944 seam-validity) pin wire formats and type signatures.

== The two representations today ==

Bitboard u64: 54 cells x 1 bit each, packed into 0x003F_FFFF_FFFF_FFFF. 1-cycle popcount, 1-cycle equality against SOLVED_STATE, 1-cycle XOR. Lossy: collapses FAIL/FLUID/void into a single "not-PASS" class.

Ternary u128: 54 cells x 2 bits each, 108 bits used, top 20 unused. Encodes PASS/FAIL/FLUID/void distinctly. ~2x cycle cost per hot-path op (two u64 popcounts + add, two u64 compares + AND, two u64 XORs).

Today, evaluate_faces_bitmask, cube_topology::is_solved, the L2 admit-gate equality, and epoch_rotation::rotate_topology operate on bitboard form. belnap::classify_topology_failure, denial_cert::resolve_face_cell, face_geometry::first_failing_cell, and the Verus/Coq/Lean spec corpus operate on ternary form. The two coexist; we just shipped PR #87 documenting the bitboard-form epoch rotation as canonical (Option C — preserved u64 typing, added TopologyStateU128::to_bitboard_u64() / from_bitboard_u64() accessors).

== Three architectural concerns to weave in ==

CONCERN 1: Cube recursion. Cubie's trust model is recursive — a top-level cube admission can contain sub-cube admissions for delegated sub-decisions. Each level needs its own topology, its own admit decision, its own cryptographic linkage back to the parent. Must: (a) N levels of nesting without N-fold envelope blowup, (b) parent's L2 equality still 1-cycle even when child states exist, (c) child's FLUID distinguishable from child's FAIL from parent's perspective. Bitboard breaks (c). Ternary preserves it but costs cycles.

CONCERN 2: Dual ledger architecture. Cubie writes every admit decision to (a) consent log (BBS+/ZKP, EU AI Act Art 12+13, GDPR Art 30), (b) billing of record (OpenBao-sealed, CUaaS billing/SLA). Must preserve: single per-admit deterministic ledger entry, selective disclosure of bitboard-projection bits to regulators without revealing FLUID/Void, stable byte representation for OSCAL audit-log sealing. Bitboard makes selective disclosure trivial. Ternary requires deterministic projection + proof that projection preserves disclosed property.

CONCERN 3: The 56-bit slot question. 56 cells (7x8 expansion, or 54 + 2 phantom metadata cells) gives 112 bits at 2 bits each, fits u128 with 16 unused. 2 phantom cells could carry ledger-metadata sidecars (recursion depth, billing class, consent version) inside the topology without enlarging the envelope or breaking 192-byte assertion. Is the right move to expand to 56 cells x 2 bits where 54 are geometric topology and 2 are ledger-metadata sidecars that the L2 equality check masks out? Pros: dual-ledger derivation O(1), recursion O(1)/level, preserves envelope. Cons: requires updating ~1,200 theorems hard-coding "54 cells". OR: stay at 54 cells, put recursion + ledger metadata in manifold[2]+manifold[3] flag bits we already have. Those don't get the XOR-rotation cryptographic isolation as topology bits, but more flexible.

== Hard constraints (non-negotiable) ==

- Hot-path budget: <= 20 ns per admit. Aspire 1 cycle (<= 0.33 ns) for equality-against-SOLVED on canonical path. Stretch.
- Proof contract: any representation change needs a migration plan for ~1,200 triple-kernel theorems. Pick min-CUB-ID-cost path or justify larger.
- ABI lock: CubeObjectV1 exactly 192 bytes. CubeFlit64 exactly 64 bytes. types.rs.sha256 rebases as deliberate commit.
- Append-only proofs: new theorem gets new CUB-ID. Supersession-by-add only.

== Interoperability axis (maximum) ==

Same admit primitive must run on:
- Pacemaker class: Cortex-M0+/RV32I, no MMU/alloc/panic-unwind, <100 KB code, deterministic, IEC 62304 Class C
- Industrial/automotive ECU: Cortex-M4F/RV32IMC, ~1 MB code, deterministic w/ heapless heap, AUTOSAR/ISO 26262 ASIL-D
- Edge AI accelerator: Cortex-A53/A72 bare-metal or Intel Atom Edge bare-metal, NEON/SSE allowed, full Verus static link, AI-camera SmartNIC trust gate
- Datacenter hot path: Xeon Sapphire Rapids+, AVX-512+AMX-int8+MOVDIR64B, MESI-coherent shared atomic shards, DPDK/XDP, 200 Gbps+, constant-time
- AI gateway middleware: Python-FFI cdylib into FastAPI/LiteLLM/OpenAI-compatible proxies, ~1-10 ms gateway-tolerable, JSON attestation envelope, streaming-compatible, TEE-attested under TDX/CCA
- Confidential VM: Intel TDX (production), ARM CCA (target), AMD SEV-SNP (compat), Intel ITA v2 composite attestation or local KBS, aws-lc-rs FIPS or in-tree HMAC-SHA256

Chosen topology representation must be the same byte sequence at every tier — pacemaker 100KB binary and Xeon AVX-512 build operate on bit-identical request envelopes.

== Compliance / log axis (non-negotiable) ==

Every admit produces (1) consent log w/ BBS+ selective disclosure, (2) billing-of-record w/ OpenBao seal, (3) OSCAL audit envelope for SOC 2 / ISO 27001 / EU AI Act Annex IV, (4) Intel PT trace fragment when in TDX. All four must be derivable from topology state deterministically and atomically — pure functions of topology + per-cell encoding key. No external state, no clock, no random.

== Concrete questions ==

Q1: Unify on ternary u128 across hot path (eating 2-3 cycle cost) for FLUID/Void preservation + simpler ledger derivation, OR keep dual representation with bitboard-as-projection semantics + cognitive cost?

Q2: Expand 54 -> 56 cells for inline recursion+ledger metadata, OR stay 54 and use manifold[2]+manifold[3] flag bits?

Q3: Per-tier cycle budgets for L2 equality, bloom probe, HMAC fast-path, and epoch-rotation derotation: which ops hit 1 cycle on Xeon (AMX/AVX-512), ~3-5 cycles on Cortex-A53 (NEON), ~10-20 cycles on Cortex-M0 (no SIMD)?

Q4: Min proof-corpus migration cost per option. Enumerate theorem families that change vs stay stable. Cite specific CUB-IDs.

Q5: Smallest stable Python/JSON surface for FastAPI middleware writer (NOT a cryptographer) — admit decision + attestation envelope + dual-ledger receipt. Sketch function signatures.

Q6: Bare-metal pacemaker contract: what subset of admit runs in <100 KB code on Cortex-M0+? What gets stripped (HMAC? Singmaster? Belnap?), what's the minimum-viable admit?

Q7: Datacenter Sapphire Rapids contract: realistic per-admit cycle count w/ AVX-512+AMX+MOVDIR64B. Where do we beat 16.57 ns? Where does budget headroom go on SmartNIC (Mt Evans/IPU) vs bare-metal host?

Q8: OSCAL + EU AI Act Annex IV envelope for one admit. What topology bit fields become Annex IV record-keeping (Art 12), what stays internal, how does selective disclosure for regulator audit work without breaking BBS+ commitment?

== Deliverable ==

Single architectural decision document with:
- Chosen path for each of 8 questions w/ cost-benefit
- Proof-corpus migration plan w/ explicit CUB-ID allocation (next band CUB-MATH-TOPO-2000+ per ADR-0011) for any new theorems
- Deployment-tier matrix: same CubeObjectV1 byte layout across pacemaker, industrial, edge AI, datacenter, gateway, TEE tiers w/ per-tier hot-path budget
- Dual-ledger derivation spec: deterministic function topology -> consent log entry + billing entry + OSCAL envelope + Intel PT fragment
- Cube-recursion termination proof sketch (N levels of nested admission, recursion-depth metadata, parent equality semantics)
- Three concrete rejected alternatives w/ reasoning

Don't shortcut by picking the safest answer. Pick the architecturally cleanest answer that survives the formal-proof corpus AND the pacemaker code-size budget AND the Sapphire Rapids cycle budget AND the EU AI Act audit envelope. If those four pull in different directions, say so — document where they conflict before resolving.

Note: 1-cycle aspiration is aspirational — current hardware can't reasonably do 192-byte read + topology equality + ledger write in 1 cycle. Honest answer is "1 cycle for equality on hot-cache line, ~50 cycles for full admit." Flag it.
