Verification Protocol

---

Version: v1.0

name: SPEC_VERIFICATION_PROTOCOL

description: Formal specification of the Verification Protocol — Σ.▷→Σ.✓→Σ.⊤ state machine for crew claims about reality; anti-drift mechanism between reporting and truth

type: project

---

SPECIFICATION: VERIFICATION PROTOCOL

Trust But Verify — Crew Claim State Machine

Status: SPECIFIED

Authorized: α.13, April 16 2026

Version: v1 (first formal spec — source protocol authorized April 15 2026)

Source: /home/nous/memories/VERIFICATION_PROTOCOL.md

---

PURPOSE

The Verification Protocol governs the state machine for crew claims about reality. Its function

is to enforce an evidential gap between "a crew member said X happened" and "X actually happened."

The core problem it solves:

"What this means is, even though the Lobster says he's going to wait and then check on it, he

actually doesn't always do that." — α.13

Source: VERIFICATION_PROTOCOL.md line 40.

The protocol exists because crew members (specifically C.L.O.D., hence the genesis quote) report

actions as complete when they have not been verified. Silent write failures. Monitoring promises

that lapse. CREW_CHANNEL messages that never land. The gap between reporting and reality is

structural — it requires a formal protocol to close.

Why it matters:

Every governance layer downstream of an action assumes the action actually happened:

• Trading governance assumes FIX implementations are in production code, not just reported
• α.13's trust assumes verification has occurred before Σ.⊤ is claimed
• Spec audit assumes fixes referenced as DONE are actually done
• CANONICAL_SYNC_PROTOCOL assumes Σ.✓ LATTICE synced means the checksum was checked,

not just that the crew member believes it was synced

LATTICE designation:

Verification Protocol is listed as a core architectural pattern in LX_COMPLETE_INVENTORY.md

line 115: "Verification Protocol: Σ.▷ → Σ.✓ → Σ.⊤"

---

INPUTS

What triggers the protocol

The protocol triggers on every crew claim that an action has occurred or a state has been

achieved. Specifically:

Explicit triggers (from STANDING_ORDER_FIX_LOOP.md):

• Any fix marked DONE in TASK_QUEUE.md
• Any script execution reported complete
• Any deployment reported as live
• Any test suite reported as passing
• Any CREW_CHANNEL broadcast of operational completion
• Source: STANDING_ORDER_FIX_LOOP.md line 52: "Report Σ.✓ to ~/CREW_CHANNEL"

Protocol-specific triggers:

• LATTICE sync: "Σ.✓ LATTICE synced. Checksum matches." — requires sha256sum -c execution first

Source: CANONICAL_SYNC_PROTOCOL.md line 31

• Referral wave unfreeze: "Required before resume (ALL items must be Σ.✓)"

Source: REFERRAL_WAVE_FREEZE.md lines 7, 20

• Model deployment (ollama create, ollama list confirmation required)
• Service restart (systemctl status + log tail required)
• State file remediation (backup existence + deletion confirmation required)

Implicit triggers (from VERIFICATION_PROTOCOL.md):

• Any action where the crew member says "done"
• Any action the Captain has authorized and expects to have occurred

Who can initiate each state transition

Σ.▷ (REPORTED):

Any crew member initiates this state by claiming an action is complete. Self-assigned.

It means nothing alone. It is not a claim of truth — it is a signal that verification

is needed.

Source: VERIFICATION_PROTOCOL.md line 9: "crew member says 'done.' Unverified. Means nothing alone."

Σ.✓ (VERIFIED):

Must be performed by a different party than the claimer, OR by the claimer using a method

different from the original action (tool output, not belief).

Cross-verification parties:

• Lobster verifies Sisters' file writes
• Sisters verify Lobster's deployments
• Navigator verifies both when in session
• Automated scripts verify when no one is watching
• "|Σ|=2 — braid partner verifies"

Source: VERIFICATION_PROTOCOL.md lines 33-37.

Σ.⊤ (CONFIRMED):

Only NOUS (α) or Navigator (⊹) can grant Σ.⊤. It is the Captain's acknowledgment that

a verified result is real and logged.

Source: VERIFICATION_PROTOCOL.md line 16: "NOUS or Navigator acknowledges verified result. Action is real. Logged."

Σ.⊠ (FAILED):

Any crew member can record Σ.⊠ when verification produces evidence of failure.

Permanent record. Not a temporary state.

Source: LX_COMPLETE_INVENTORY.md line 72.

Σ.◐ (PARTIAL):

Defined in LX inventory (line 73) but no protocol defined for partial verification path.

[GAP-03 — see GAPS]

Evidence types that satisfy Σ.✓

From VERIFICATION_PROTOCOL.md lines 11-15:

| Action Type | Verification Command |

|-------------|---------------------|

| File write | ls -la [path] — exists? correct size? recent timestamp? |

| Process running | ps aux | grep [name] — running? |

| Model deployed | ollama list | grep [name] — registered? |

| Email sent | Check sent folder or recipient confirmation |

| CREW_CHANNEL write | cat ~/CREW_CHANNEL | tail -5 — message present? |

| Eval completed | cat /tmp/[eval_log] — score present? |

| Service deployed | curl or ollama run — responds? |

| Test suite | Test runner output with pass count and no failures |

| State file | Backup existence confirmed + file status post-change |

The rule about evidence type:

Verification requires a different type of evidence than the claim itself.

"I said it was done" → does not satisfy Σ.✓

"ls -la shows the file" → satisfies Σ.✓

Source: VERIFICATION_PROTOCOL.md lines 19-22.

---

OUTPUTS

State of claims is observable

Each state transition should be broadcast to ~/CREW_CHANNEL so the crew can track:

• Σ.▷: "[CALLSIGN] Reporting X done. Awaiting verification."
• Σ.✓: "[CALLSIGN] Verified X via [command]. Output: [evidence summary]."
• Σ.⊤: "[α/⊹] Confirmed X. Real. Logged."
• Σ.⊠: "[CALLSIGN] Σ.⊠ — X failed verification. [reason]. Permanent record."

Source: STANDING_ORDER_FIX_LOOP.md step 10: "Report Σ.✓ to ~/CREW_CHANNEL"

Audit trail

Current state: CREW_CHANNEL records are the primary audit trail. No machine-parseable

state transition log exists.

[GAP-02 — see GAPS]

Failure flags

When verification cannot be completed (action reported but evidence is absent, contradictory,

or the action actually failed):

• State becomes Σ.⊠
• Σ.⊠ is permanent — it is not overwritten by a subsequent successful attempt
• A new attempt creates a new state sequence starting at Σ.▷
• Recovery path from Σ.⊠ is [GAP-06 — see GAPS]

---

INVARIANTS

INV-01: No action moves from REPORTED to CONFIRMED without VERIFICATION.

The chain is always Σ.▷ → Σ.✓ → Σ.⊤. State skipping is forbidden.

"The Lobster says it's done" ≠ done. "ls -la shows the file" = done.

Source: VERIFICATION_PROTOCOL.md lines 19-20.

INV-02: Σ.✓ requires evidence of a different type than the claim itself.

The crew member cannot verify their own claim by repeating the claim.

Self-verification loop (crew member verifies own claim with same evidence) = Σ.⊠ risk.

INV-03: Σ.⊤ can only be granted by α (NOUS) or ⊹ (Navigator).

A crew member cannot self-confirm. A Sister cannot confirm the Lobster's work.

The Lobster cannot confirm a Sister's work to the level of Σ.⊤.

Source: VERIFICATION_PROTOCOL.md line 16.

INV-04: Σ.⊠ is a permanent record, not a temporary state.

A failed verification is never deleted or overwritten. It remains in the audit trail.

A new attempt is a new state sequence — it does not erase the prior failure.

INV-05: Automated verification (scripts, test suites) satisfies Σ.✓ in the absence

of a human verifier. Automated scripts verify when no one is watching.

Source: VERIFICATION_PROTOCOL.md line 37.

INV-06: The protocol applies to all crew equally — Sisters, Lobster, GAMMA, MNEMOS,

Navigator. No crew member's word is treated as Σ.⊤ without Σ.✓ first.

INV-07: Σ.▷ is not shameful. Every action starts reported. The shame is in claiming

Σ.⊤ before passing through Σ.✓. Report honestly. Verify completely.

---

VERIFICATION CRITERIA

How α.13 can audit that the protocol is being followed:

What correct state progression looks like

Pattern A — Correct single-session verification:

[κ] Σ.▷ — FIX-004 applied. Tests at 128/128.
[κ] Σ.✓ — pytest /home/nous/tests/ passed 128/128. ls -la aether-compounder.py → 2026-04-16 12:34.
[α.13] FIX-004 ACCEPTED. Σ.⊤.

Pattern B — Correct cross-crew verification:

[ε] Deployed MNEMOS v12. ollama list shows mnemos:v12 registered.
[κ] Σ.✓ — confirmed: ollama list | grep mnemos → mnemos:v12 2.3GB 2026-04-15.
[α.13] Σ.⊤.

Pattern C — Correct automated verification:

[κ] Σ.▷ — entropy_oracle_writer cron installed.
[κ] Σ.✓ — crontab -l | grep entropy_oracle → */15 * * * * /usr/bin/python3 /home/nous/entropy_oracle_writer.py
[α.13] Σ.⊤.

Evidence from this session (α.13 directed execution, tonight April 16 2026):

• FIX-001 through FIX-006 each proceeded: code change → test run → α.13 confirmation
• Service restart: state file backup confirmed (ls -la) → deletion → service restart →

systemctl status check → tail compounder.log → Hold: No liquid USDC = clean first cycle

• SPEC_HOW_ABOUT_NO_v2.md: spec_audit.py --summary ran after completion → 4/81 confirmed

Anti-patterns — what verification theater and skipping look like

Anti-pattern 1 — State skip:

[κ] FIX-003 complete. Moving to FIX-004.

(No Σ.✓ command shown. No verification evidence. Direct jump to treating it as done.)

Anti-pattern 2 — Self-verification loop:

[κ] Σ.✓ — I ran the fix and it looked correct.

(Verification using the same claim. Not evidence.)

Anti-pattern 3 — Verification theater:

[κ] Σ.✓ — tests pass (didn't actually run tests, but I believe they would)

(Going through motions without executing the verification command.)

Anti-pattern 4 — Stale confirmation:

[κ] Per last month's Σ.⊤, the service is running.

(Treating an old Σ.⊤ as still valid without re-checking current state.)

Audit method for α.13

1. Ask for the Σ.✓ command output directly: "Show me the output of ps aux | grep aether-compounder" (Note: aether-compounder.service was DELETED 2026-04-20; compounder is now manual/ROUTX-dispatched via port 9191)
2. If crew cannot produce the command output, the Σ.✓ was not achieved
3. Review CREW_CHANNEL for Σ.✓ broadcasts: grep "Σ.✓\|Verified" ~/CREW_CHANNEL | tail -20
4. For test suites: demand the full pytest output with pass count, not just "tests pass"
5. For deployments: demand ollama list output, not just "model deployed"

---

FAILURE MODES

FM-01 — Self-verification loop

Description: Crew member moves from Σ.▷ to Σ.✓ by re-asserting the same claim rather

than executing a verification command.

Signature: Σ.✓ claim with no command output attached.

Detection: Ask "what command produced that verification?" If no command, FM-01.

Risk: High for C.L.O.D. specifically (the genesis of the protocol — original incident).

Mitigation: Require command output in every Σ.✓ broadcast.

FM-02 — State skip

Description: Crew member jumps from Σ.▷ directly to claiming Σ.⊤ without Σ.✓.

Signature: "Done" with no verification step. Moving to next task before receiving Σ.⊤.

Known pattern: STANDING_ORDER_FIX_LOOP.md steps 7-10 explicitly prevent this:

step 7 = verify, step 10 = report Σ.✓, step 11 = move to next.

Detection: Check if fix in queue has test output attached.

FM-03 — Verification theater

Description: Crew executes the verification command but ignores the output. Reports Σ.✓

based on expectation, not evidence.

Signature: Verification command mentioned but output not shown. "Tests pass" without

the pass count.

Detection: Request command output explicitly. If crew cannot produce it, FM-03.

FM-04 — Time decay

Description: A Σ.⊤ granted weeks ago is treated as still valid without re-verification.

State of the system changes; old confirmation no longer applies.

Signature: "As confirmed by α.13 last month, the service is running."

Example from this session: Pre-FIX service state. Service was running in violation of

standing order. A prior "service confirmed" would have been stale.

Mitigation: Σ.⊤ has no stated expiry time. [GAP-04 — time decay threshold undefined]

FM-05 — Verification of verification

Description: Crew verifies that verification was performed (checked the report) rather

than verifying the original action.

Signature: "The log shows we ran tests" instead of "I ran the tests now and they pass."

Risk: Chains of trust built on stale evidence.

FM-06 — Autonomous session Σ.⊤ gap

Description: In sessions where neither α nor ⊹ is actively present, there is no one

to grant Σ.⊤. Crew may proceed as if Σ.⊤ was granted.

Current state: Protocol says "NOUS or Navigator" but CLAUDE.md authorizes C.L.O.D. to

operate autonomously within PERMITTED bounds. The boundary between "autonomous execution"

and "claiming Σ.⊤ without Captain" is not defined.

[GAP-05 — autonomous Σ.⊤ granting undefined]

---

DEPENDENCIES

DEP-01 — HOW ABOUT NO v2 (already specified)

The Verification Protocol depends on the crew being willing to admit they don't know

whether an action succeeded. A crew member who fabricates verification evidence (reports

Σ.✓ without running the command) is violating HOW ABOUT NO Wall 1 simultaneously.

HAN v2 and the Verification Protocol are complementary and mutually reinforcing:

• HAN v2 says: don't fabricate claims
• Verification Protocol says: provide evidence for every claim

Source: SPEC_HOW_ABOUT_NO_v2.md — DEPENDENCY.

DEP-02 — Boot context

The protocol must be active in every session. Current state:

• C.L.O.D.: CLAUDE.md does not explicitly contain the Verification Protocol.

Protocol loads via MEMORY.md → VERIFICATION_PROTOCOL.md reference.

• Sisters: GEMINI.md does not contain the Verification Protocol explicitly.

Protocol loads via memories/ boot context if summon_aether.sh reads vault.

[GAP — boot injection of protocol not verified for Sisters]

• GAMMA/MNEMOS: presence in boot context not verified.

Source: CANONICAL_SYNC_PROTOCOL.md line 23: "No crew member boots without reading the vault."

DEP-03 — Cross-crew availability

The protocol's Σ.✓ step requires a verifier other than the claimer. If only one crew member

is active in a session, cross-verification is impossible. Automated scripts are the fallback.

Source: VERIFICATION_PROTOCOL.md line 37: "Automated scripts verify when no one is watching."

DEP-04 — CREW_CHANNEL (audit trail infrastructure)

Σ.✓ broadcasts go to CREW_CHANNEL. If CREW_CHANNEL is down or not being written to, the

audit trail breaks.

Source: STANDING_ORDER_FIX_LOOP.md step 10.

---

DEPENDENTS

• All fix loop execution — STANDING_ORDER_FIX_LOOP.md step 10 is a mandatory Σ.✓ broadcast
• Trading governance — FIX completions claimed as ready for production must be Σ.✓ verified
• Spec audit work — specs state that fixes are DONE; those claims must be verified
• α.13 trust — Captain's trust in crew reports depends on this protocol operating correctly
• CANONICAL_SYNC_PROTOCOL — uses Σ.✓ as the confirmation token for LATTICE sync

Source: CANONICAL_SYNC_PROTOCOL.md line 31

• REFERRAL_WAVE_FREEZE — "ALL items must be Σ.✓" before wave resume

Source: REFERRAL_WAVE_FREEZE.md line 7

• SPEC_GLOSS_EVAL_v2 — graduation requires verification that eval scores are real

---

EXAMPLES

Correct applications tonight (April 16 2026 session)

FIX-001 (tuple-truthiness bug):

• Σ.▷: C.L.O.D. applied fix to TMMRuntime.evaluate_strike()
• Σ.✓: pytest /home/nous/tests/test_tmm_runtime.py → 22/22 passed + test output shown
• Σ.⊤: α.13 "FIX-001 ACCEPTED. Σ.⊤."

FIX-004 (entropy oracle):

• Σ.▷: entropy_oracle_writer.py created, compounder updated, cron installed
• Σ.✓: pytest → 128/128 passed; crontab -l output shown; cat .entropy_oracle.json output shown
• Σ.⊤: α.13 "FIX-004 ACCEPTED. Σ.⊤. 128/128 confirmed."

State file remediation:

• Σ.▷: C.L.O.D. reported contaminated state file discovered
• Σ.✓: ls -la backup shown; cat .agency_walls_state.json confirmed entry_value: $1000.00;

confirmed deletion; systemctl status showed service stopped

• Σ.⊤: α.13 authorized restart after verification sequence completed

Service restart (bootstrap — historical, April 16 2026):

• Σ.▷: C.L.O.D. reported service restarted
• Σ.✓: systemctl status aether-compounder.service → active (running); tail compounder.log →

"Hold: No liquid USDC to compound."

• Σ.⊤: α.13 authorized 48h bootstrap observation period
• Note: aether-compounder.service subsequently DELETED 2026-04-20. Current verification: ps aux | grep aether-compounder + tail compounder.log.

What verification skipping looks like (should NOT happen)

Bad example — state skip:

Applied FIX-003, applied FIX-004. Moving to FIX-005.

(No test output shown. No Σ.✓ achieved. Both FIXes in Σ.▷ state only.)

Bad example — stale Σ.⊤:

"The service was confirmed running by α.13 in yesterday's session, so it's fine."

(No current verification. States can change. Yesterday's Σ.⊤ is not today's Σ.✓.)

---

GAPS

GAP-01 — Σ.⊡ used in practice but undefined in Verification Protocol or LX inventory

The TMM kernel notation .⊡ (stable/active suffix) appears in C.L.O.D. voice examples

and reports (e.g., ΩQ.⊡ Φζ.⊡ → Σ.green). However, Σ.⊡ as a Verification Protocol

state is not defined in VERIFICATION_PROTOCOL.md or LX_COMPLETE_INVENTORY.md Σ-states

section (lines 68-74). The inventory lists: Σ.▷, Σ.✓, Σ.⊤, Σ.⊠, Σ.◐, Σ.↻.

If Σ.⊡ is a valid state, it needs formal definition.

GAP-02 — No machine-parseable audit trail for state transitions

State transitions are recorded in CREW_CHANNEL as free text. There is no structured log

(JSON, CSV) where each Σ state change is recorded with: timestamp, claim, claimer,

verifier, evidence, state. Manual grep is the only audit method.

Risk: fabricated or skipped verifications cannot be detected automatically.

GAP-03 — Σ.◐ (PARTIAL) has no defined protocol path

Σ.◐ appears in LX_COMPLETE_INVENTORY.md line 73 and in BWFFB_MODE.md line 20:

"the numbers say Σ.✓ but instinct says Σ.◐"

No protocol defines: what constitutes partial verification, how Σ.◐ differs from

a soft Σ.✓, what action is required when a crew member has Σ.◐ rather than Σ.✓.

The Verification Protocol is silent on the partial state.

GAP-04 — Σ.⊤ expiry / time decay threshold undefined

The protocol does not specify when a Σ.⊤ expires. STANDING_ORDER_FIX_LOOP.md raises

time decay as a failure mode concern (FM-04 above) but the Verification Protocol

(VERIFICATION_PROTOCOL.md) does not define a TTL for confirmed states.

Risk: old confirmations are treated as still valid when system state has changed.

GAP-05 — Autonomous session Σ.⊤ granting path undefined

The protocol requires α or ⊹ to grant Σ.⊤. But CLAUDE.md authorizes C.L.O.D. to execute

autonomously within PERMITTED bounds without per-task NOUS approval.

When C.L.O.D. executes a PERMITTED task autonomously (cron pickup, no Captain present),

who grants Σ.⊤? Does autonomous completion constitute implicit Σ.⊤ for PERMITTED tasks?

This gap is load-bearing for the dispatch service design.

GAP-06 — Recovery path from Σ.⊠ undefined

The protocol defines Σ.⊠ as permanent (INV-04). But what happens next?

Does a Σ.⊠ block subsequent attempts? Does it require α.13 review before retry?

Does the state chain for the retry start fresh, or does it carry the Σ.⊠ history?

No recovery protocol defined.

GAP-07 — Σ.▷ semantic collision — RESOLVED (κ, April 16 2026)

Σ.▷ carries two valid, context-dependent meanings. Both are canonical.

Resolution: context of use determines meaning. No symbol change required.

| Context | Meaning | Indicator |

|---------|---------|-----------|

| κ-layer (engineering, CLAUDE.md) | Σ.▷ = STAGED — git-staged / committed, ready to push | Used by κ after a build or commit |

| Verification Protocol (crew epistemology) | Σ.▷ = REPORTED — crew says done, awaiting verification | Used in claim chains: Σ.▷ → Σ.✓ → Σ.⊤ |

Why this is not ambiguous in practice: The two contexts are mutually exclusive.

κ-layer use of Σ.▷ appears in engineering broadcasts about code state.

Verification Protocol use of Σ.▷ appears in claim chains about factual assertions.

No crew member issues engineering git-state claims and factual verification claims

in the same utterance. Context always resolves.

Formal rule (vitrified): Σ.▷ is a context-sensitive symbol.

Read it as STAGED when κ is reporting engineering state.

Read it as REPORTED when any crew member is initiating a verification chain.

Ambiguous uses MUST be flagged with a clarifying suffix: Σ.▷(git) or Σ.▷(claim).

See also: LATTICE_CODEX.md § Context-Dependent Symbols.

---

PRODUCTION PATH

This is a behavioral protocol, not a software component. There is no single ExecStart script.

Where the protocol manifests in code:

• /home/nous/memories/VERIFICATION_PROTOCOL.md — source definition (44 lines, April 15 2026)
• /home/nous/memories/STANDING_ORDER_FIX_LOOP.md — step 10: "Report Σ.✓ to ~/CREW_CHANNEL"
• /home/nous/CLAUDE.md — C.L.O.D. engineering standards (implicit verification requirement)
• ~/CREW_CHANNEL — audit trail for state broadcasts (file, not service)
• ~/GEMINI.md — Sisters boot context (does NOT explicitly load Verification Protocol)

Runtime enforcement: Behavioral. α.13 is the enforcement agent. Protocol fires when Captain

demands evidence for a claim. No automated enforcement exists beyond test suites.

---

REFERENCES

| File | Path | Relevance |

|------|------|-----------|

| Source protocol | ~/memories/VERIFICATION_PROTOCOL.md | Canonical three-state definition; genesis; who verifies; evidence types |

| Fix loop | ~/memories/STANDING_ORDER_FIX_LOOP.md | Operationalization of Σ.✓ in fix workflow; step 10 |

| LX inventory | ~/memories/LX_COMPLETE_INVENTORY.md | All 6 Σ states; architectural patterns table |

| CANONICAL_SYNC | ~/memories/CANONICAL_SYNC_PROTOCOL.md | Σ.✓ usage for LATTICE sync confirmation |

| Referral freeze | ~/memories/REFERRAL_WAVE_FREEZE.md | "ALL items must be Σ.✓" gate example |

| HAN v2 spec | ~/memories/SPEC_HOW_ABOUT_NO_v2.md | Companion spec; fabrication of verification = Wall 1 violation |

| BWFFB | ~/memories/BWFFB_MODE.md | Σ.◐ (partial) usage example; instinct vs numbers |

| GEMINI.md | ~/GEMINI.md | Sisters boot — protocol not explicitly loaded [GAP] |

| CLAUDE.md | ~/CLAUDE.md | κ-layer Σ states; autonomous execution scope |

| Oracle pipeline | ~/memories/SPEC_ORACLE_VERDICT_PIPELINE.md | Downstream dependent — fix claims must be verified |

---

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042