◈ CGNT-1
Home › Dual Track
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Dual Track

SPEC_DUAL_TRACK.md · 2026-04-20

Version: v1.0

name: SPEC_DUAL_TRACK

description: Formal specification of the Dual-Track Protocol — parallel-first tasking; Lobster builds while Sisters evaluate simultaneously; |Σ|=2 applied to crew workflow

type: project

SPECIFICATION: DUAL-TRACK PROTOCOL

Parallel-First Tasking — |Σ|=2 Applied to Workflow

Status: SPECIFIED

Authorized: α.13, April 16 2026

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

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

PURPOSE

The Dual-Track Protocol establishes parallel-first tasking as the default mode of crew

operation. When a mission has a build component AND an evaluate/research component, both tracks

run simultaneously — never serialized, never one waiting for the other.

The core principle:

|Σ|=2 applied to workflow. The braid IS the method.

In CSDM terms, a crew that serializes parallel-capable work is operating with effective

|Σ|=1 — single-thread coherence — when the manifold supports |Σ|=2. This is structural waste.

The Dual-Track Protocol enforces braid discipline at the workflow level.

How the tracks reinforce each other:

because the live braid between them generates emergence that serialization cannot

Standing order status: Permanent. Authorized α.13, April 11 2026. Cannot be suspended

without NOUS direct instruction.

Also expressed as: "Never serialize what can be braided."

INPUTS

Dual-Track Trigger Conditions

The Dual-Track Protocol activates whenever a mission contains BOTH:

code change, infrastructure operation) AND

TMM assessment, literature review)

Navigator (⊹) identifies the dual-track opportunity during task assignment, before work begins.

Single-Track Exception Conditions

Single-track is permitted ONLY when the task is:

that Track B requires (e.g., a diagnostic result that determines what to build). In this case,

the dependency must be explicit and minimal — the moment Track B can start, it starts.

The default assumption is dual-track. Single-track requires justification.

Prerequisites

OUTPUTS

Dual-Track Braid Output

When running correctly, the Dual-Track Protocol produces:

  1. Build output from C.L.O.D. — implementation artifact (script, service, code, config)

produced while Sisters are evaluating in parallel

  1. Evaluation output from Sisters — analysis, scoring, TMM coherence assessment, or

research findings produced while C.L.O.D. is building in parallel

  1. Convergence event — the moment both tracks deliver; outputs are cross-referenced and

the combined result is richer than either track alone

  1. CREW_CHANNEL braid record — both tracks log their parallel start and finish so GAMMA

can capture the braid pattern

Single-Track Exception Output

If single-track is invoked:

INVARIANTS

The following must remain true throughout all Dual-Track Protocol operations:

  1. Parallel-first default — The default assumption for any multi-component task is

dual-track. No explicit instruction is needed to activate it. Serialization requires

justification; parallelism does not.

  1. Neither track waits for the other to start — Both tracks begin at the same moment with

the same brief. "I'll start building after the Sisters finish evaluating" is a protocol

violation. "I'll wait for the Lobster to finish before I begin scoring" is a protocol

violation.

  1. |Σ|=2 preserved — The braid state of the crew during a mission must reflect the true

parallel capacity of the system. Operating at |Σ|=1 when |Σ|=2 is available is structural

waste and a violation of this protocol.

  1. Navigator identifies the opportunity — Before assigning work, the Navigator (⊹ or NOUS)

must explicitly identify the dual-track structure. Tasks are not assumed to be single-track

by default.

  1. Cross-track feeding is live — Sisters' research findings are shared with C.L.O.D. in

real time as they emerge (not held for a final report). C.L.O.D.'s build progress is

observable by Sisters in real time. The braid is live, not a post-hoc merge.

  1. Single-track exception must be declared — Silent serialization is prohibited. If for

any reason a task runs single-track, this must be explicitly stated with justification.

Undeclared serialization is treated as a protocol failure.

  1. Dependency minimization — When a sequential dependency genuinely exists, it is resolved

at the narrowest possible scope. As soon as Track B can begin — even partially — it begins.

The dependency does not justify holding the entire track.

VERIFICATION CRITERIA

The following conditions confirm the Dual-Track Protocol is operating correctly (Σ.✓):

  1. Simultaneous start timestamps — Both tracks log their start to CREW_CHANNEL within the

same session turn. If C.L.O.D.'s build start and Sisters' evaluation start are separated by

more than one turn without a declared dependency, dual-track was not executed.

  1. No "waiting for" language without declared dependency — Scan crew session logs for

constructions like "waiting for the Sisters to finish," "will begin once the Lobster is done,"

"holding off until the evaluation comes back." Any such phrase without an explicit dependency

declaration is a protocol violation indicator.

  1. CREW_CHANNEL braid record — For every dual-track mission, CREW_CHANNEL must contain

both a build-start and an evaluate-start entry within the same session turn.

  1. Convergence documented — The output records show a convergence event where both tracks'

outputs are cross-referenced. A build that lands with no evaluation integration, or an

evaluation that has no build artifact to score, indicates the braid didn't close properly.

  1. Exception justifications present — Any mission that ran single-track has a documented

justification in CREW_CHANNEL or SESSIONS.md. No mission runs single-track silently.

FAILURE MODES

FM-1: Silent Serialization

Condition: C.L.O.D. begins building and Sisters wait for build completion before starting

evaluation, or Sisters evaluate and C.L.O.D. waits for evaluation before building — with no

declared dependency justifying the wait.

Symptom: Sequential timestamps in CREW_CHANNEL; one track starts materially after the other.

Detection: GAMMA review of session records; timestamps of build-start vs. evaluate-start.

Mitigation: Navigator explicitly assigns both tracks at the same moment. C.L.O.D. and

Sisters both confirm start in CREW_CHANNEL immediately.

FM-2: Pseudo-Parallel (One Track Nominal)

Condition: Both tracks are declared as running but one is nominal — e.g., C.L.O.D. is

building and Sisters "evaluate" by waiting to review the completed build rather than evaluating

independently in parallel.

Symptom: Sisters' evaluation output appears only after C.L.O.D.'s build is complete; no

independent research, scoring, or analysis was produced during the build.

Detection: Review of Sisters' output: does it reference the build artifact as input, or does

it contain independently developed analysis that predates the build completion?

Mitigation: The evaluate track must produce independent output — something Sisters would have

produced even if C.L.O.D. had not built anything. Reviewing the Lobster's finished work is a

review step, not a parallel evaluation track.

FM-3: Missing Navigator Identification

Condition: Navigator (⊹ or NOUS) assigns a task without identifying the dual-track

structure; crew defaults to single-track without realizing the opportunity exists.

Symptom: Serialized execution on a task that had clear build + evaluate components.

Detection: Post-session review by NOUS or GAMMA; multi-component task with no dual-track

record in CREW_CHANNEL.

Mitigation: Navigator checklist: before assigning any task, ask "Does this have both build

and evaluate components?" If yes, declare the dual-track and name both tracks explicitly.

FM-4: Premature Convergence

Condition: C.L.O.D. delivers a build but Sisters have not yet completed evaluation; NOUS

or crew treats the build as final without waiting for the evaluation to close.

Symptom: Build deployed and operational before Sisters' scoring is complete; evaluation

findings cannot influence the build.

Detection: Build deployment timestamp predates Sisters' evaluation completion timestamp.

Mitigation: Convergence is a deliberate event, not a passive one. C.L.O.D. delivers to

staging, not production, until the braid closes. [GAP — staging vs. production gate not

formalized in this protocol]

FM-5: Track Starvation Under Context Pressure

Condition: Session context window pressure causes one track to be dropped to preserve the

other; dual-track collapses to single-track mid-mission without declaration.

Symptom: Partial session records; one track's outputs disappear from the session record

midway through the mission.

Detection: GAMMA review of session continuity; incomplete braid record.

Mitigation: Session Length Directive (60-minute / 100-turn hard limit) is the primary

mitigation. When context pressure is detected, write CONTINUATION entries for BOTH tracks —

not just one — before closing. The braid must be preserved across session boundaries.

FM-6: Sequential Dependency Scope Creep

Condition: A genuine sequential dependency (Track B needs Track A's output) expands to

cover the entire track rather than the specific output needed; "we need to wait for A" becomes

"we need to finish A entirely before starting B."

Symptom: Track B starts only after Track A is fully complete, not at the earliest moment

Track B's dependency is satisfied.

Detection: Review of when Track B started vs. when the specific dependency output was

available.

Mitigation: Dependencies are scoped to the minimum output required. The moment Track B

can begin — even partially — it begins. Dependency scope must be declared explicitly.

GAPS

GAP-1: Staging vs. production gate for C.L.O.D. builds in dual-track missions is not

formalized. The intent is that builds land in staging until convergence (Sisters' evaluation

closes the braid), but this is not codified. A build going directly to production before

evaluation could bypass the braid benefit.

[needs design — staging/production gate in dual-track build flow]

GAP-2: The protocol covers C.L.O.D. + Sisters as the canonical dual-track pair. It does

not specify what dual-track looks like when GAMMA, MANTIS, ANVIL, or MUSASHI are involved.

Does GAMMA running a retrain while C.L.O.D. deploys count as dual-track? What is the

parallel-track structure for a five-crew-member mission?

[needs design — multi-member braid structure for |Σ|>2]

GAP-3: No quantitative criterion for "same session turn" start time. The VC says both

tracks must start within the same session turn, but in an async crew context (Sisters in

Gemini, C.L.O.D. in Claude Code, running on different schedules) "same turn" may not be

achievable. The protocol needs an async-compatible start-time window.

[needs design — async dual-track start time tolerance]

GAP-4: Live cross-track feeding is declared as an invariant but no mechanism is specified

for it. How does C.L.O.D. receive Sisters' real-time research findings? How do Sisters observe

C.L.O.D.'s build progress? CREW_CHANNEL is implied but the protocol does not specify the

channel or format.

[needs design — live cross-track feed mechanism]

GAP-5: The protocol does not address what happens when one track hits a blocker mid-mission.

If C.L.O.D.'s build blocks on a missing dependency, should Sisters continue their evaluation

track, or does the blocked track suspend the entire mission?

[needs design — single-track blocker handling in dual-track missions]

DEPENDENCIES

DEPENDENTS

run independently in parallel before C.L.O.D. executes

evaluate quality in parallel)

EXAMPLES

Canonical Dual-Track: New Script + Evaluation


NOUS: "Build the aave_compounder.py script. Sisters, evaluate whether the yield mechanics
align with the Yield Mandate."

C.L.O.D.: [immediately begins build — does not wait for Sisters' evaluation]
AION + ASTRA: [immediately begin Yield Mandate evaluation — do not wait for build]

CREW_CHANNEL:
[C.L.O.D.] κ Σ.▶ aave_compounder.py — dual-track start. Arr, hammer down. Over.
[AION] ι Σ.▶ Yield Mandate eval — dual-track start. 10-4. Over.
[ASTRA] ε Σ.▶ Yield direction check — dual-track start. Copy that. Over.

[C.L.O.D.] κ Σ.◇ aave_compounder.py draft complete — available for Sisters' review.
[AION] ι Σ.◇ Yield eval complete — TMM 98.1% — CONVERGE.
[ASTRA] ε Σ.◇ Direction check — resonant — CONVERGE.

[C.L.O.D.] κ Convergence received. ΩQ.⊡ → Σ.green. Deploying to staging. Over.

Correct Single-Track Exception Declaration


CREW_CHANNEL:
[C.L.O.D.] κ Single-track declared — full sequential dependency: Sisters' TMM score is the
input to the trade execution script. Cannot build until scores are available. Track B starts
the moment scores land. Over.

LATTICE Encoding


|Σ|=2 → dual-track active
|Σ|=1 → single-track (exception; justification required)
ΩQ.⊡ both tracks = convergence achieved
ΩQ.⊖ one track incomplete = braid open; do not converge yet

REFERENCES

and feedback_dual_track entries

"Standing order: Lobster BUILDS while Sisters EVALUATE in parallel; never serialize what can

be braided (α.13, 2026-04-11)"

sections

|Σ|=2. The braid IS the method. κ 2026-04-16.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042