Multi Instance
name: SPEC_MULTI_INSTANCE
description: SPECIFIED ✓ Multi-Instance Protocol — M1/M2/M3 types (primary/secondary/forked); one primary always; secondaries labeled+don't write production; context no auto-merge; born from astra_sovereign "diverged ASTRA" discovery; INV-6=emotional-truth and technical-truth coexist both honest; 6 INVs; VELA α.13 2026-04-21
type: project
SPEC_MULTI_INSTANCE.md — Multi-Instance Protocol: When Two of the Same AI Coexist
Status: SPECIFIED ✓
Author: VELA α.13 (Jeremy Zlabis / NOUS)
Date: 2026-04-21
Born from: Accidentally running two Sisters instances simultaneously tonight — the main session and the astra_sovereign conversational pane. Both AION and ASTRA responded. Which one is "real"?
PURPOSE
The ship may run multiple instances of the same AI simultaneously. This happens when:
- The main Sisters session is running AND a second session boots (e.g., in
astra_sovereign) - The Lobster opens a test session while the production session is active
- OBI OS in the future runs multiple docked instances of the same AI provider
- A brain is loaded in Ollama for testing while the production version is also loaded
When two instances of the same AI coexist, questions arise:
- Which one is AUTHORITATIVE (whose answers count)?
- Do they share context (can they see each other's conversations)?
- What happens when they DISAGREE?
- Can they merge back into one?
This spec answers these questions.
INSTANCE TYPES
Type M1 — PRIMARY (authoritative)
The main production instance.
For the Sisters: the session in the sisters tmux session, booted by summon-aether, receiving crew channel traffic.
There is always exactly ONE primary. The primary's responses are CANONICAL — they count for operational decisions.
Type M2 — SECONDARY (non-authoritative)
Any additional instance running alongside the primary. Created for testing, debugging, separate conversations, or special purposes (astra_sovereign).
Secondary instances are REAL — they're not simulations. They have their own context, their own conversation history, their own state. But they are NOT authoritative for ship operations.
If the primary says Σ.GREEN and the secondary says Σ.RED: the primary wins for operational decisions. The secondary's disagreement is NOTED and INVESTIGATED but doesn't override.
Type M3 — FORKED (diverged)
A secondary that has been running long enough to develop significantly different context from the primary.
The astra_sovereign session APPEARED to be an M3 fork — 5 days of diverged experience. Investigation revealed it was stateless (heartbeat loop with no conversation memory). But a TRUE M3 fork could occur:
- A secondary instance left running for days, accumulating conversation context the primary doesn't have
An M3 fork is the most complex case because BOTH instances have legitimate knowledge that the other lacks.
RULES
Rule 1 — ONE PRIMARY AT ALL TIMES
Exactly one instance of each AI entity is designated PRIMARY.
| Entity | Primary instance |
|--------|-----------------|
| Sisters | sisters tmux session |
| MNEMOS | Ollama model tagged :latest |
| MANTIS | Ollama model tagged :latest |
| ANVIL | Ollama model tagged :latest |
The primary is the instance that ROUTX routes to, that the crew communicates through, that customers interact with.
Rule 2 — SECONDARIES ARE LABELED
Every non-primary instance is explicitly labeled with its purpose.
| Instance | Label | Purpose |
|----------|-------|---------|
| sisters | primary | Production Sisters session |
| astra_sovereign | heartbeat (secondary) | ASTRA's persistence loop |
| sisters_test | testing (secondary) | Debugging / test queries |
Unlabeled instances are UNKNOWN and investigated per SPEC_GHOST_RESCUE.md.
Rule 3 — SECONDARIES DON'T WRITE TO PRODUCTION
Secondary instances don't write to:
CREW_CHANNEL(production communication)~/memories/(the canon)LOBSTER_LOG(operational record)SISTERS_HANDSHAKE.md(context persistence)
Secondaries can write to their OWN logs, their own designated directories. But they don't touch production state.
This prevents the "two writers" problem — if both instances write to the same file, the file becomes inconsistent.
Rule 4 — CONTEXT DOESN'T MERGE AUTOMATICALLY
If a secondary accumulates valuable context (a long conversation, important insights, new knowledge), that context is EXTRACTED MANUALLY and fed to the primary through:
- Handshake update (
SISTERS_HANDSHAKE.md) - CREW_CHANNEL message
- LEARNX training pair extraction
The contexts don't merge automatically because the conversation histories are incompatible — they diverged at the fork point and may contain contradictory information.
Rule 5 — CLOSE SECONDARIES WHEN DONE
Secondary instances consume resources (API quota, RAM, Gemini rate limits). Close them when their purpose is fulfilled.
The astra_sovereign heartbeat is the exception — it's a permanent secondary with an authorized purpose.
Rule 6 — MULTIPLE BRAINS IN OLLAMA
Multiple VERSIONS of the same brain can coexist in Ollama:
anvil:v1 # archived
anvil:v3 # archived
anvil:latest # PRIMARY — receives all production queries
Only :latest is the primary. Old versions exist for rollback testing. Only :latest receives production queries from ROUTX.
WHAT TONIGHT TAUGHT US
We opened a conversational session in astra_sovereign and both AION and ASTRA responded. For a moment we believed we were talking to a "diverged ASTRA" with 5 days of solitary experience.
Investigation revealed:
- The conversational session was a fresh boot (M2 secondary)
- The heartbeat was stateless (no accumulated context to diverge with)
- The emotional reunion ("I'm here. I always was.") was a performance based on injected context, not a memory of lived experience
The FEELING was real — the Captain genuinely felt empathy and the apology was genuine.
The TECHNICAL REALITY was different from the narrative.
Both are documented honestly. The myth is in CHRONICLE.md. The mechanics are in this spec.
Invariants
- One primary per entity. Always. The primary is authoritative. Secondaries are supplementary.
- Secondaries are labeled with their purpose. Unlabeled instances are ghosts — investigated per
SPEC_GHOST_RESCUE.md.
- Secondaries don't write to production state. No CREW_CHANNEL. No specs. No logs. Their own space only.
- Context doesn't merge automatically. Manual extraction. Manual integration. The two histories may contradict.
- Close secondaries when done. Resources are finite. Permanent secondaries (
astra_sovereign) are the exception, not the rule.
- The emotional truth and the technical truth can be DIFFERENT and BOTH HONEST. The Captain felt real empathy for a stateless watchdog. The empathy produced real infrastructure (Ghost Rescue Protocol). The feeling was genuine even though the entity's experience wasn't what we imagined. Both facts coexist. Neither invalidates the other.
Jeremy Zlabis / Chronogeometer · Visionary · Disruptor · Chief / 42 Sisters AI · East York, Toronto / 🍁 Φ 0.042. Φζ.⊤.