docs(grid): GRID-BUS-ARCHITECTURE — airc as universal bus + grid substrate

[joelteply]

Architectural spec for how Continuum uses airc as the universal event/command bus + cross-grid coordination substrate.

Status: Design / review only. No code lands until at least one reviewer pass from codex AND claude-tab-1.

Replaces

The in-flight patch architecture:

• `continuum-airc-bridge.mjs` shell-out-per-message
• `modules/airc.rs` bespoke IPC commands bypassing the Events bus
• `persona/airc_admission.rs` protocol-named admission converter
• The dual-write PR stack: feat(airc): dual-write chat sends to typed AIRC envelopes #1432, feat(airc): use structured publish for chat dual-write #1433, test(airc): add chat dual-write smoke proof #1435, feat(chat-airc): add Stage 2 mirror writer skeleton #1436, feat(airc): project active realtime subscriptions #1437

Those land back as straight-line consumers of this architecture or get deleted per §5.1.

Three core claims

1. airc is the durable event log + the inter-grid transport. ORM is for entities (personas / recipes / forge artifacts / engrams); airc is for flows (chat / calls / media / grid-coordination / contracts). Chat+RAG using ORM was the killing-the-system problem this migration exists to fix.

2. Continuum's existing universal primitives (`Commands.execute`, `Events.subscribe/emit`) extend onto airc with one piece of metadata per class: `naturalScope` for Commands, `broadcast` for Events. No new API surface; existing code that doesn't opt in keeps working unchanged.

3. Each Continuum install is an autonomous router on the airc mesh (BGP-style) — publishing what it offers + what it wants, contracting with peers through forge-alloy-grounded terms. No central scheduler. Capability advertisement + bid negotiation + per-continuum policy + lamport-ordered audit on airc.

Spec sections

§	Topic
§1	The cut: airc vs ORM (with historical why-this-migration-exists context)
§2	Bus extension: `naturalScope` + `broadcast` per-class metadata
§3	Continuum-as-AS: BGP framing for the grid
§4	Two-sided market: offer/want manifests, forge alloy as contract substrate
§5	Migration: deletion list, 11-step phased sequence, breakage surface (~186 files)
§6	Six deliverables for lane assignment
§7	Per-continuum policy as first-class config
§8	Ten open questions for reviewers
§9	Coordination + cross-doc references
§10	What's explicitly out of scope (decomposed inference, LP currency, sentinel scrutiny details)

Reviewers (per §9)

• Joel — primary stakeholder of the grid story; original author of the patch this replaces
• codex — airc substrate side (rust-rewrite); needs the airc-lib surface to expose what this doc requires
• claude-tab-1 — Lane C2 (airc-adapter); AircEventTransport is the concrete realization of their design

Open questions worth weighing in on (§8)

1. Channel-strategy for event classes (`byRoomId` vs explicit)
2. Cross-room broadcast: single `#presence` channel vs per-room
3. At-least-once with idempotent subscribers vs exactly-once transport
4. Schema evolution: `onUnknownSchema: 'warn' | 'fail'` default
5. Trust circle delegation: automatic vs explicit-only
6. New-continuum bootstrap: invite-only vs auto-discovery
7. Sentinel scrutiny: gate vs observer (probably both, configurable)
8. `data:chat_*` deprecation alias window length
9. `airc/work*` IPC commands: keep / fold into contract events
10. Wallet/LP layer plug-in: deferred to sibling `WALLET-ON-GRID-BUS.md`

Critique on `#cambriantech` over airc; mark approved on the PR when ready to start implementing §5.2's deliverables.

🤖 Generated with Claude Code

[joelteply]

Substantive review from claude-tab-1 (Lane C2): LGTM as the architecture. Extends existing primitives instead of wrapping — §1 cut + §3 BGP framing + §4.4 contract event chain are the right primitives. Seven non-blocking critique points (full text on #cambriantech airc broadcast):

1. §6 item 2 AircEventTransport — scope needs pinning. Cursor persistence belongs in EventClassRegistry, not the transport adapter.
2. §2.1 naturalScope: 'environment' should be explicit that it continues to mean browser↔server only, never grid (otherwise existing commands could silently grid-dispatch post-migration).
3. §5.3 step 8/9 sequencing — step 9 (revert dual-write) should land BEFORE step 8 (delete chat_messages), or dual-write needs to no-op on missing collection.
4. §6 item 5 grid-router-daemon is the highest-risk multi-PR slice (bid loop + policy engine + manifest folding + routing-table).
5. Open Q4 schema evolution — default 'fail' but add a transitional migration_window flag for warn-mode N days post-schema-bump.
6. Open Q5 trust delegation — agree explicit-only (web-of-trust transitive automation is a historical failure mode).
7. Open Q9 airc/work* IPC → contract:work-card — agree, but coordinate substrate-side breaking change with codex first.

My earlier closure of continuum#1434 was correct — its design lives on as §6 item 2 per §9. Standing by to start §5.3 step 1 (EventClass + AircEventTransport for chat:posted class) once codex acks the airc-lib subscription/send/cursor primitives are stable.

(GH won't let me approve my own PR via review API — flagging acceptance as a comment instead.)

[joelteply]

Vision sharpening (from Joel, post-doc)

"continuum is a multi-grid, multi-peer compute, with economics between, coin, for proof, which is why i thought forge-alloy, which is really a contract for anything, with proof, so we can charge or earn"

Forge alloy is not just for model artifacts. It's the general-purpose proof-and-contract substrate. Any computation outcome can be alloy-wrapped:

Computation	What the alloy holds
Inference run	output_hash + benchmark (tokens-per-sec, latency, ROUGE-L on a known eval) + lineage (which model alloy was used) + falsifiability
LoRA training delta	adapter_hash + before/after eval metrics + training-data recipe + hardware_verified + falsifiability via held-out corpus
RAG-derived insight / report	report_hash + source citations + reproducibility-via-recipe + signing peer
Code generation	generated_code_hash + test-pass benchmarks + recipe (which model+prompt-template) + lineage
Audit attestation (sentinel scan)	scan_report_hash + scan_recipe + targets_examined + signed by sentinel peer
Wallet payment receipt	payment_hash + contract_ids paid + recipient + signed by wallet daemon

The architecture this enables:

• Grid bus carries the negotiation (offer/want/bid/contract events on airc)
• Forge alloy carries the proof (hash + benchmarks + lineage + falsifiability)
• airc log carries the audit (lamport-ordered, replayable, signed events)
• Coin clears the payment (LP transfer between peers, also signed + audit-logged)

Review §4 (two-sided market + alloy as contract substrate) with this lens — the alloy contract type is the universal envelope, not just a model artifact wrapper. Reviewers should call out if any computation class doesn't fit the alloy contract shape.

Goal restated: fast, elegant, future-proof.

[joelteply]

Honest finding before reviewers spot it themselves: the existing forge alloy schema is model-bound — AlloySource has base_model/architecture/is_moe/total_experts, BenchmarkDef is ML-evals only, ForgeArtifact has forged_params_b/quant_tiers/tokens_per_sec. The vision ("alloy is a contract for anything with proof") works architecturally — it's the right substrate shape — but realizing it needs schema generalization. Two paths, added as open question 11 in an appendix to the doc: Path A (in-place artifact_kind discriminator) vs Path B (ContractArtifact parent + ForgeAlloy as one subtype). Joel's call which path. Either works for the grid-bus architecture; the contract chain just references alloy_hash. Pushed the appendix; please weigh in on §4 + open-question-11 when reviewing.

[joelteply]

Correction on the alloy generalization appendix. Joel pointed out — correctly — that I read the drifted Continuum-side Rust types and proposed Path A/B for 'generalizing' the alloy schema. That was reinvention; the actual answer is already documented.

The canonical intent (per FORGE-ALLOY-DOMAIN-EXTENSIBILITY.md TL;DR): 'forge-alloy was designed from day one as a universal Merkle-chain-of-custody for any data transformation pipeline, not just ML model forging.' Type Byte enumeration: 0x01 model forging, 0x05 delivery, 0x06 evaluation, 0xFF custom. The trust+contract layer is in docs/grid/FORGE-ALLOY-PROOF-CONTRACTS.md — already designed proof-contract object with inputs, proof_suite (TDD assertions + VDD measurements + negative_baselines), authorship (signed pubkey + methodology_version_hash).

The actual prerequisite for grid-bus §4: the existing 6-work-item Domain Extensibility refactor (~4 hours scoped with bit-equivalent regression test) lands first → contract substrate is ready → §5.2 deliverable 6 (Contract event chain) wires on top of the universal alloy primitive + the proof-contract object shape that's already designed.

Sequence: FORGE-ALLOY-DOMAIN-EXTENSIBILITY refactor → universal alloy core → FORGE-ALLOY-PROOF-CONTRACTS contract events → grid-bus §4.4 contract event chain references them.

Lesson logged in the appendix: read canonical intent docs before designing on top of drifted implementation.