← Hemisphere Bridge → Agent Platform Phase 4 · Prompt Deck · Pictures

From: Outer Loop (Claude.ai) → Engineering Team (Nav) Date: 2026-03-11 Status: Draft — ready for engineering review Depends on: Nav Continuity Layer (Phase 0-4 complete), PRD Handoff Protocol, Agent Comms (Convex) Northstar: Every cycle of dream → spec → build → commission → dream-bigger leaves both hemispheres measurably stronger, takes less time, and the trust ledger confirms it.

1. Problem Statement​

The dream hemisphere (mm.dreamineering.com) and the engineering hemisphere (stackmates) communicate through manual handoffs, stale instrument readings, and a protocol that exists on paper but isn't wired into the system. The VVFL spiral can't run autonomously because:

1. The scoreboard has no live readings (188 capabilities listed, instruments uncalibrated)
2. The handoff protocol is a document, not a hook — enforcement is at convention layer (Level 2), not system layer (Level 4)
3. No automated keep/discard — engineering can't verify whether a change improved the system without human judgment at every step
4. No settlement verification — when a PRD crosses from dream to engineering and back, no instrument confirms arrival matched promise
5. The trust ledger doesn't exist yet — settlement history per agent per boundary isn't tracked

Karpathy proved: three files + one metric + "NEVER STOP" = 100+ autonomous experiments overnight. The primitives exist. Claude Code now ships hooks, custom agents, agent teams, /batch, and agent memory with project scope. What's missing is the wiring.

2. Architecture: A&ID for Phygital Systems​

2.1 The Pattern​

In a dairy factory P&ID:

In the phygital mycelium A&ID — same pattern, different substrate:

Critical distinction: In P&ID, instruments primarily measure. In A&ID, instruments are active participants — they carry intent, energy, conditions, and reputation simultaneously. A smart contract doesn't just measure settlement. It holds the energy in escrow, encodes conditions, releases on fulfillment, and records to the trust ledger. Simultaneously pipe, valve, and gauge.

2.2 Two Hemispheres, One Protocol​

mm.dreamineering.com                stackmates repo
┌──────────────────────┐            ┌──────────────────────┐
│   DREAM HEMISPHERE   │            │ ENGINEERING HEMISPHERE│
│                      │            │                      │
│  Strategy            │  PROTOCOL  │  9 algorithms        │
│  Stories             │  BOUNDARY  │  208 tables           │
│  Priorities          │◄──────────►│  Hex architecture    │
│  Scoreboard          │            │  Venture code        │
│  Navigation System   │            │  Shared infra        │
│  400+ pages of       │            │  Agent comms         │
│  collective wisdom   │            │  Commissioning data  │
│                      │            │                      │
│  = program.md        │            │  = train.py          │
│    at scale          │            │    at scale          │
└──────────────────────┘            └──────────────────────┘
          │                                    │
          └───────────┐          ┌─────────────┘
                      ▼          ▼
               ┌──────────────────────┐
               │    SCOREBOARD        │
               │    reads BOTH sides  │
               │    = prepare.py      │
               │      (locked eval)   │
               └──────────────────────┘

Rule: No agent crosses the hemisphere boundary without going through the protocol. Dream agents don't write code. Engineering agents don't rewrite strategy. The protocol IS the trust boundary — same role as Karpathy's locked prepare.py.

Karpathy mapping:

2.3 The Agent x Agent Matrix​

The dominant future boundary for goodwill flow is agent-to-agent — where agents are phygital beings operating at different ratios of biological to digital.

The center cell (phygital ↔ phygital) is where most future commerce lives. The instruments between them carry:

3. Goodwill Flow — The Northstar Instrument​

3.1 Why Not Cashflow​

Developer Anarchy (Fred George) used cashflow as northstar. Works when every team is a revenue experiment. But cashflow measures extraction — "did we capture value?" Capitalism rewards aggregation. That's not the game.

Goodwill is the only capital that compounds without limit. But you can't measure accumulation — that's back to wealth thinking. You measure flow rate — is capital converting through the cycle?

Financial → Time → Intellectual → Social → Goodwill → Financial
         ↑___________________________________________________|

3.2 Goodwill = Settlement Integrity at Every Boundary​

Goodwill flows between agents through instruments in closed loops:

AGENT A                    INSTRUMENT                     AGENT B
(phygital being)     (smart contract / financial       (phygital being)
                      instrument / type contract)

  Intent ─────────► Encodes intent + energy ──────────► Receives
                                                         │
  Trust ledger ◄─── Settlement confirmation ◄─────────── Actuates
  updates                                                intent
                                                         │
  Goodwill ◄──────── Did arrival match promise? ◄────── Verifies
  compounds           The INSTRUMENT reads this          settlement

The receiver validates, never the sender. Commissioning principle: "the builder never validates their own work."

3.3 Three Bearings​

Not five — keep it tight enough for binary keep/discard.

Each bearing asks the same question: did what arrived match what was promised, and did the receiver's trust compound?

3.4 Settlement at Every Scale​

3.5 Where the Instrument Lives​

The instrument reads from both hemispheres — it sits in the protocol layer:

• Internal Settlement — computed from git commit data + test results (stackmates repo)
• Hemisphere Settlement — computed from PRD frontmatter (mm repo) x commissioning dates (stackmates repo)
• External Settlement — computed from published standards (mm repo) x package consumers + venture telemetry (stackmates repo)

3.6 The Calibration Path: Supabase → Sui​

You don't put an untested instrument on the plant floor. Bench-test, calibrate, prove it reads true, THEN install in the live system.

Supabase (JSON/SQL)        →  Proven patterns         →  Sui (on-chain)
Installation + Testing        Operational                 Optimization
"Does the loop close?"        "Does settlement compound?" "Does it scale trustlessly?"

Sui's object-centric model is the target because identity isn't a row in a database — it's a first-class object that owns other objects. The pepeha isn't metadata. It's the root object from which everything inherits trust.

The migration isn't a technical project. It's a commissioning gate. When Supabase data honestly reflects reality through clean settlement patterns across multiple ventures, the Sui migration is a formality. The hard work is the calibration.

4. Gap Matrices​

Matrix thinking: show the gaps, don't explain them. The ? cells are the work.

4.1 Layer x Status​

Eight ? cells in the protocol column. Those are the highest-leverage work items.

4.2 Claude Code Feature x Hemisphere​

4.3 Commissioning Level x Scoreboard Section​

5. Execution Plan​

Follows commissioning model: Installation → Testing → Operational → Optimization. Follows think-slow-act-fast: this spec IS the slow thinking. The phases below are fast execution. Each phase's gate must pass before starting the next.

Phase 1: Wire the Scoreboard (Instrument Calibration)​

Why first: Can't run a loop without instruments that read true. The scoreboard's own instruments are uncalibrated. This is building prepare.py — the locked evaluation function.

Goodwill bearing served: Internal Settlement.

Success criterion: Nav can run /goodwill and see numbers that reflect reality.

Phase 2: Wire the Protocol (Dream ↔ Engineering Settlement)​

Why second: With instruments reading true, the protocol between hemispheres can be verified.

Goodwill bearing served: Hemisphere Settlement.

Phase 3: Wire the Loop Control (NEVER STOP)​

Phase 4: Wire Agent Teams (Parallel Commissioning)​

Phase 5: Wire the Trust Ledger (Supabase Calibration → Sui Readiness)​

6. Build Sequence Summary​

What Nav Should NOT Do​

• Don't build the trust ledger dashboard before Phase 1 instruments read true
• Don't enable Agent Teams before single-agent /loop works
• Don't write new scoreboard pages. Fix existing ones
• Don't modify shared infra (algorithms, hex architecture) as part of this work
• Don't deploy to Sui before Supabase trust data is validated against reality

What the Dream Hemisphere Will Do in Parallel​

• Review scoreboard readings against source data (commissioning gate for Phase 1)
• Author next PRD in priority queue with scoring
• Update strategy page with live positioning data when instruments exist
• Verify settlement receipts from engineering (receiver validates, never sender)

7. Claude Code Feature Mapping​

7.1 The Four-Layer Stack → Mantra Hierarchy​

7.2 Custom Agent Definitions​

Engineering Agent (.claude/agents/engineering.md):

• Full write access: venture-specific code, tests, commissioning data
• Read-only: libs/agency/algorithms/, shared infrastructure
• To modify shared infra: commit message must include [COMMISSION]
• Every task completion produces a receipt
• The receiving agent (dream team) verifies settlement

Dream Agent (.claude/agents/dream.md):

• Read-only on stackmates repo
• Write access: mm repo pages, PRD specs, strategy updates
• Verifies settlements — never generates them
• When engineering sends a commissioning receipt: verify against spec

8. The Telco MEV Connection​

In telco routing:

CALLER (intent) → ROUTING ALGORITHM → INFRASTRUCTURE → CDR (settlement) → BILLING (feedback)

MEV extracts value from the gap between intent and settlement — the router takes a cut. The Dreamineering thesis inverts this: minimize the gap so both agents compound trust. MEV isn't extracted by a middleman. It's returned to the network as goodwill — making the network more valuable, attracting more agents, creating more settlement opportunities.

That's DePIN. That's the tokenomics. The network's value IS the accumulated settlement integrity of every agent-to-agent transaction. The token doesn't represent equity in a company. It represents a claim on the trust ledger of the network.

The Supabase calibration (Phase 5) is proving this thesis with data before encoding it on-chain. Same pattern: understand the decision tree better than veterans, build the spreadsheet proof, earn the right to build the system.

9. Questions​

If the scoreboard commissions itself to L4 using this plan, is that the first capability to reach L4 — and is that the story that proves the system works?

• When /loop runs unattended for 2 hours with >50% keep rate, what does that tell you about human judgment in the inner loop — and what does it mean for the displaced workers thesis?
• The trust score is computed from settlement integrity. But settlement is binary (arrived = promised, or didn't). Where does the nuance live? Is "partially matched" a thing, or does the instrument need to be crisp enough that every settlement is yes/no?
• When the first external venture founder scaffolds on the mycelium and their agent settles with Stackmates agents for the first time — that's the External Settlement bearing's first reading. What does a healthy first reading look like?
• The instrument carries intent, energy, conditions, and reputation simultaneously. In the Supabase prototype, these are columns in a table. On Sui, they're fields in a Move struct. Is there an intermediate form — something more structured than JSON but less permanent than on-chain — that accelerates the calibration?
• Goodwill flows like water — finding every crack, going around, through, under the rock. If the trust ledger shows a boundary with low settlement integrity, does goodwill route around it automatically? Or does the system need explicit rerouting logic? Is that the explore-exploit algorithm applied to trust?

Context​

• PRD Index — Hemisphere Bridge → Agent Platform Phase 4
• Prompt Deck — 5-card pitch
• Pictures — Pre-flight maps