# Low Passage A coordination substrate for teams of minds, written in Erlang/OTP. Cognition is a swappable dependency. Work is durable; processes are not. The project is **Low Passage**. A running instance is a **ship**; a reusable topology is a **ship class**; a stable role inside a ship is a **station**, which OpenRig calls a seat. This is not OpenRig. It borrows OpenRig's parts — seats, pods, rigs, an intent tree, a queue, proof — and rebuilds them on OTP, because most of those parts are message passing and supervision, which Erlang already is. The evidence behind that claim is in [[Low Passage Research]]. **Why that name.** *Low Passage* is the Traveller term for the cheap berth: the one you take when the money matters more than the odds, and the one where a few passengers are expected not to wake up. That is the bargain this design makes — breadth bought with failures, because a ship is cheap and a fleet can lose one — and the log, the judge and the missing-row accounting exist so that a failure is a row somebody can see rather than a quiet disappearance. *High Passage* was the first thought; Low Passage is the honest one. ## Why this exists OpenRig proves it works. Two years of running a fleet produced a set of invariants worth keeping: stable stations, a durable watch bill where a handover requires a reason, an intent tree where only the leaf is fully specified, proof that is derived rather than declared, and a ship's log that explains everything after the fact. It also produced a product that requires macOS or Linux, tmux, and Claude Code or Codex. The development host is Windows and has no WSL; the daily harness is Bionic. Porting the product is the wrong job. Rebuilding the invariants is the right one. The observation that started this: a large fraction of OpenRig's architecture is interprocess communication that Erlang has had since the late 1980s. Stations are named processes with mailboxes. Departments are process groups. Ships are supervision trees. Mission instances are state machines. The audit trail is a ship's log. What OpenRig builds by hand — launch, restore, readiness, delivery, durable work, crash recovery — is OTP's default behavior. So the split is simple: **coordination is Erlang's, cognition is borrowed.** Stations are processes. Minds are adapters. Harnesses and models are replaceable dependencies. The ship's job is to keep addresses, work, and intent durable while everything else is swapped out. **How to read this.** It runs from general to particular, and the section order is the reading order. *Why this exists*, *Constraints*, *Platform*, and *Scope* bound the project. *Principles* and *Vocabulary* give the rules and the words, and the vocabulary table is the definition of record — where prose and the table disagree, the table is right. The middle sections describe the machinery: *The ship*, *Work and records*, *Minds and equipment*, *Missions and the bridge*, and *Distribution and growth*. *Command* says who may decide what; *Force design* says how to decide what to build; *Bootstrap* is the smallest working version of the whole thing. Then how the ship judges itself: *Metacognition*, *Metrics*, *Failure modes*, *Milestones*, and *Open questions*. The **worked examples come last**, because everything before them supplies the words and the reasoning they depend on — read them with the rest of the document behind you. The decision log closes the document as the record of what changed and why. **How it is maintained.** Four rules keep this document honest. The **vocabulary table is normative** — where prose and table disagree, the table wins, and a term used but never defined is a gap rather than a style choice. The **decision log is append-only**: an overtaken decision gets a new dated entry naming what replaced it, never an edit to the old one, because the reason a thing changed is as useful as the thing. A **rule and a worked example are meant to agree** — when they don't, one of them is wrong, and the same sitting that notices fixes it rather than leaving both on the page to drift. The fourth is about naming. **No undefined container words.** *Shape*, *arrangement*, *element*, *property*, *dial* and *promise* were each doing a noun's work badly, and the test is literal: cover the word and ask what you would point at. If the answer is a ship, a tool, a file, a turn, or a pen, name that and let the abstraction go. Abstraction is earned when the thing does not exist yet, or when the vocabulary defines it — *ship*, *station*, *mind*, *watch*, *capacity* and *authority* are all abstractions, and they stay because they are defined. ## Constraints - Cross-platform by design. Erlang/OTP runs on Windows, Linux, and macOS, and the code should not care which. Windows 10 is the development host, not the target. - No WSL2, and no tmux on any platform. The coordination layer must not depend on a terminal multiplexer. - Erlang/OTP 29 is installed on the development host, with `erl`, `erlc`, and `escript`. `rebar3` is not installed and is not needed for the first spike. - Bionic is the harness in daily use and the subscription being paid for. Claude Code and Codex are not in the picture. - One development machine now. Distribution to Linux boxes and VPSs later, without a VPN if TLS distribution holds up. - Bionic's local model endpoint is the only documented way in, and it serves local models only. The subscription is not exposed there. - Context is expensive. Local models at 100k-plus tokens are slow and limited. They are useful for grunt work, not for the jobs that need a long conversation. ## Platform The target is not "Windows software that happens to run elsewhere." It is Erlang software that runs anywhere OTP does, with Windows as the development host. - **Development host:** Windows 10, OTP 29. - **Expected targets:** Linux boxes and VPSs for stations that outlive the desktop, and macOS if it ever comes up. - **No POSIX-only assumptions.** The coordination layer must not need a shell, a pty, or a fork. - **Paths go through `filename:join/1` and `filename:absname/1`.** No string concatenation and no hard-coded separators. - **Case sensitivity differs.** Windows paths are case-insensitive; Linux paths are not. Names that differ only by case are a bug on both. - **File locking differs.** Do not assume `file:open` with `exclusive` behaves identically. The ship's log and watch bill own their files; nothing else opens them for writing. - **Signals and service startup are platform adapters.** A station does not care how its node was started. - **Line endings normalize at the boundary.** Specs and standing orders are UTF-8 with LF; readers tolerate CRLF. - **Distribution ports and EPMD are configured per host.** The TLS setup is the same; the firewall rules are not. - **Platform coverage is a test matrix, not a milestone sentence.** The handoff test runs on Windows→Linux and Linux→Linux before a VPS station is trusted; the M6 criterion itself stays platform-neutral. ## Scope **In scope for the design.** - Fleets, task forces, ships, departments, stations, equipment, and consorts; stable addresses; inheritance of standing orders. - A durable watch bill with reasoned handovers; an append-only ship's log. - A work tree of campaigns, missions, and sorties, and derived proof. - A mind behaviour with swappable adapters. - A separate bridge with declared and observed topology. - Distribution over TLS, task handoff, and migration of work. - Metacognition: an analyst that proposes topology changes and is scored on them. **Out of scope for v0.** - A terminal UI. The bridge is one HTML page. - Bundles, permission policies, compose services, multi-tenant auth. - A general-purpose agent framework. This is a ship class, not a platform. - Reimplementing a coding harness's tool loop from scratch. Tools belong to the station. ## Principles 1. **Coordination is Erlang's; cognition is borrowed.** No station knows which mind answered. Swapping a mind is a configuration change. 2. **The address is stable; the occupant is replaceable.** A station outlives every process that sits in it and every mind it uses. 3. **Log is truth, watch bill is projection, mailbox is a doorbell.** Durable messages never live in a process mailbox. The mailbox wakes a process; the ship's log tells it what to do. 4. **Content in files, coordination in the log.** Specs, standing orders, and proof are human-readable files. Watch-bill state, events, and mission instances are durable coordination records. 5. **Only the sortie says what to do.** Campaigns and missions carry intent — why the work exists, and what it should produce. The sortie is the only level that says what to do about it: a full specification, and the proof the result has to carry. 6. **Readiness is derived, never declared.** A proof is a set of attributed judgments, not a checkbox someone set. 7. **Declared topology is data; observed topology is derived.** The bridge shows both. A hierarchy is a pattern part of the graph takes, not a mode the fleet is switched into. 8. **Fail closed on identity.** If the model that answered is not the model requested, that is an error, not a warning. 9. **Bound recursion and budget in the runtime.** An analyst that can spawn ships gets a depth cap and a budget, enforced by code rather than by prompt. 10. **No silent degradation.** A failed resume, a substituted model, a dropped message, and a stalled watch bill all surface as errors. 11. **A mind is not part of a station.** A station is a cheap process with a config and a message list; a mind is cognition — a model in memory, or a human's attention. Nothing requires them to share a machine, and the mind's address is a routing decision, not something the station's location settles. 12. **Standing orders are promoted, not accumulated.** Memory from a station, an external harness, a compacted summary, or a passing observation belongs in the rough log until it is promoted with a source, evidence, and confidence. Nothing writes to standing orders directly. 13. **Rank is scope, not intelligence.** A commission names authority over a subset; the occupant may be human or model, except the one at the top of the ladder, which is a human's. A station holds one where it must answer for what it decides; a station that follows orders holds none. 14. **Never infer intent.** A crew that needs a fact it does not have asks whoever owns it — up, down, or across. Guessing at what someone meant is a defect, and blocking on a question is not. Underneath roughly half of these rules sits a single Erlang preference: **a failure is recoverable and a wrong answer is not.** A process that dies is a fact a supervisor can act on; a process that carries on confused is a fact that lies, and every layer above inherits the lie. "Let it crash" is not recklessness — it is a refusal to make a bad state look like a good one. The same preference runs through the design: fail closed on identity, refuse rather than substitute a model, let a stale tool error instead of guessing, degrade an alert to less information rather than to less truth, keep a watch open rather than let it expire into a false failure, and derive readiness instead of accepting a declaration. **Less information is acceptable only while it is enough.** A degraded report that still answers the question is a success with a thinner margin. A degraded report that no longer answers it is the wrong report wearing a helpful face, because a reader cannot tell a thin answer from a complete one without knowing the threshold. So a station knows what its output must contain for the work to continue, and when degradation takes it below that line it fails rather than reports. The shortfall is itself the event worth recording: it means the margin the design assumed was wrong, and it will be wrong again. The price is visible crashes, flat refusals, and alarms that sometimes say less than a person would like. The alternative is a fleet that is confidently wrong with no way of finding out where — and a wrong report, unlike a dead process, leaves nothing to restart. ## Vocabulary The unit is a **station**. OpenRig calls the same abstraction a seat; that word appears here only when quoting OpenRig. **Formations** | Term | Meaning | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fleet | A set of task forces under an admiral. Owns the fleet's standing orders and the fleet mind pool. Every ship is in one: the flagship included, because a commodore is the lowest commission that may muster a ship. | | Task force | An assembly of ships for a campaign or mission, commanded by a commodore. | | Grand fleet | A set of fleets under a grand admiral. The top of the ladder, for as long as one is needed. | | Ship | One running Low Passage instance: its own registry, watch bill, and log. A separate node is a deployment choice, not part of the definition. A reusable topology is a ship class. This is the word used when the question is whether some work needs a separate instance rather than a working party. The name is the label; the ID is the address-safe prefix. | | Department | A bounded context group. The ID is an address segment; the label is yours. It is a supervision group and a message scope, not an authority tier, and it holds stations rather than other departments. | | Station | A stable role and address with a crew, a sensor suite, an effector suite, and a mind binding. The ID is the address segment; the label is the role. | | Equipment | A sensor, effector, or other non-crew part of a station. A tool is equipment. | | Fitting | Attaching equipment to a station. A topology change, because it changes what the station can do. | | Store | The fleet's catalogue of proven equipment: what it can touch, where it came from, and how it expects to be sandboxed. | | Consort | A federated agent: an allied runtime with its own crew and mind, outside the chain. | | Flagship | The ship that carries the flag deck and the minimum command crew. The fleet's command ship, whatever rank the flag officer aboard holds. | | Flag deck | The commodore, the flag staff, and the flag log, aboard the command ship. A set of stations, not the bridge — the bridge is the monitor. | | Command ship | The ship in a task force that carries the flag deck. Otherwise it is a ship like any other — its own log, its own standing orders — and it is where the task force's staff stations live. | | Tender | A ship class for a standing function rather than a mission. It keeps that function's standing orders and outlives the missions that use it. | | Working party | A station mustered for one sortie, with a role, a mind binding, a budget, a lifetime, and a stop condition. Retired when the sortie closes, its rough log folded into the parent's; the parent stays accountable for the outcome. | | In reserve (mothballed) | A ship, formation, or campaign out of rotation but kept: its name, structure, and standing orders survive, and its log shows a gap. Reversible; decommissioning is not. | | Definition library | The fleet's store of reusable definitions at every level of composition — station roles, department patterns, ship classes. Ships muster from it; they do not own it. | **Station parts** | Term | Meaning | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Crew | The station's own process: the part that decides what the station does, on its own rules or by consulting a mind. The mind it consults is a separate service and not part of the station, which is why this table can list the crew as a part and still put minds outside it. | | Crew name | The occupant's name; the role and address stay stable when the occupant changes. | | Sensor | An input channel: camera, microphone, log tail, API poll, file watcher, queue feed. | | Effector | An output channel: shell command, file write, HTTP call, relay, display, speaker. | **Cognition** | Term | Meaning | |---|---| | Mind | A cognition service: a human or a model, reached through a behaviour. | | Model | The machine kind of mind. | | Mind binding | The mind or fallback chain a station names. It is not a pool. | | Mind host | A machine or process that can run model minds: QVAC, LM Studio, llama.cpp. | | Mind pool | The inventory of minds at a scope: fleet, task force, or ship. The fleet owns the inventory; task forces and ships hold allocations and local views. A station holds only a binding. | | Hail | A message sent to a human mind over a channel the person actually reads — a text, a chat message, a mail — rather than a turn. How the fleet asks for attention explicitly; deferred, and the reason a human mind can be reached without a bridge page. | **Operations** | Term | Meaning | |---|---| | Quartermaster | The station that provisions and retires model minds, and enrolls and releases human minds, within fleet policy and budget. | | Bosun | The station that musters and retires stations within fleet policy. | | Custodian | The station that keeps captured artifacts: stores, hashes, and indexes them, and records each hash in the ship's log. | | Muster | Bringing a station or ship into service and registering its address. Mustering a new ship creates an identity; reactivating a mothballed ship musters one that already has an identity. | Those stations recur often enough to be worth naming, but they are not a registry. A station's role is authored when it is mustered, which is why the examples elsewhere in this document — `survey:probe`, `enroll:firstlight` — exist without appearing in this table. **Command** | Term | Meaning | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Commission | A named scope of authority attached to a role. A station holds one where what it decides reaches past its own readings; a station that only watches and reports holds none. | | Grand Admiral | Grand-fleet scope. Intent across fleets, and allocation between them. | | Admiral | Fleet scope. The fleet's accountable officer — a human while the fleet is the top of the ladder, any kind of mind once a grand admiral stands above it. | | Commodore | Task-force scope. Coordinates ships and allocates mind-pool capacity. One per task force, local to it. | | Captain | Ship scope. Owns the ship's mission, release, and station-to-mind bindings. | | Commander | Department scope. Department context and approvals. | | Lieutenant | Station scope. Authority over what one station does and what it touches, held where that needs a name — the station writes something, acts on a shared resource, or leads other stations — and escalates anything above it. | | XO | Executive officer: the officer who turns a human's intent into work and answers for the command. A **post**, not a commission, held with whatever commission the work needs. Every human in a command post has one, because a mind reaches the work through the XO rather than interrupting the person. | | Captain of the Fleet | The XO of whoever stands at the top of the ladder, on the flag deck: a commodore's commission while there is one fleet, an admiral's once there is a grand fleet. Distinct from commanding any one task force. | | Principal | A commission without a station: a human or model who decides without occupying a post. | | Clarification request | A question to whoever owns a fact — up, down, or across — with the decision it blocks and a deadline. Asking for information, not for the decision or the work. | | Capacity request | A request for a station, a ship, or an allocation the asker cannot grant itself, climbing to the first scope that can. Unlike a clarification, it comes back as work. | **Records and work** | Term | Meaning | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ship's log | The append-only event log: what happened. | | Rough log | What has not been promoted: observations, summaries, external memory, rejected candidates. | | Rotating record | A bounded local file of high-frequency samples that drops its oldest entries. Only the transitions it observes reach the ship's log. | | Standing orders | Promoted rules with provenance: what we act on. | | Watch bill | The work queue: jobs, watches, and handovers. | | Watch | A time-bounded lease on a job. Not a duty period: the ship keeps no shifts, so "watch" never means a span of the clock. | | Standing watch | A watch that renews instead of closing: a recurring liveness claim on capacity, not on work. | | Handover | Closure with a reason and, where required, a target. | | Reassignment | A ship leaving one formation for another. Its address, log, and standing orders stay with it; only the formation prefix changes. | | Order of battle | The Commodore's design for a ship or task force: stations, edges, minds, proof obligations, and budget. | | Topology | Which stations exist and which edges join them. A class records one; the bridge shows the declared one against the observed one. | | Context domain | A body of work that shares one context — the same facts, the same purpose — and so can be held in one station's working memory. Force design finds the domains before it draws the stations. | | Campaign | One purpose and the missions that serve it, open beside other campaigns rather than as a phase of one. | | Mission | A series of sorties. One mission can run more than once: the same work against another device or another machine is another **instance** of it, in the same sense that a ship is an instance of a class. | | Sortie | A slice: one bounded action with a spec and a proof. | | Proof | The record that a sortie is done: the captured artifacts plus the attributed judgments made about them. Readiness is derived from it and never declared. | | Bridge | The monitor: topology, watch bill, health. | | Analyst | Reads metrics, compares declared topology against observed, and writes proposals with predictions. Does not command. | | Ceremony | Work that produces no proof and moves nothing toward one: a handover that changes no state, a station that only repeats another's judgment. Counted, because a topology is judged by how little of it there is. | | Cohort | The set of runs that may honestly be compared with one another: same task class, same mind version, same topology version, same spec version, same prompt and skill version. Metrics mean nothing outside one. | **Node kinds** | Term | Meaning | |---|---| | Manned station | A thinking node: a crew with cognition (intrinsic or bound), sensors, and effectors. | | Department | A composite: sends what it receives to its stations by a declared policy, with no mind of its own. | | Unmanned station | A leaf: sensors and effectors only. | ## The ship ``` ship_sup (one_for_one) ├── registry address → pid | watch bill, ETS-backed ├── ship_log append-only ship's log, sequence numbers ├── watch_bill jobs, handover rules, watches ├── router address resolution and delivery ├── work_tree campaign/mission/sortie tree, cached from disk ├── mind_pool local view: minds, health, quotas ├── quartermaster mind lifecycle within policy ├── bosun musters and retires stations within policy ├── mind_host_sup host adapters: QVAC, LM Studio, llama.cpp ├── department_sup (dynamic) │ ├── station_sup (dynamic) │ │ └── station_builder, station_qa, ... │ └── equipment_sup (dynamic) ├── mission_sup (dynamic) gen_statem per mission instance ├── analyst reads metrics, writes proposals, never applies └── health periodic projections and alerts ``` | Process | Responsibility | |---|---| | `registry` | Maps addresses to pids, or to watch-bill handles when nothing is live. Enforces uniqueness at registration. | | `ship_log` | Accepts events, assigns sequence numbers, never edits a past record. | | `watch_bill` | Owns jobs, watches, attempts, and handover rules. The only place work can be marked done. | | `router` | Resolves an address, applies a department's rule for which station gets the message, and records the hop. | | `work_tree` | Reads the work tree from disk, validates it, caches it, and refuses malformed intent. | | `mind_pool` | The ship's view of the fleet inventory: local health, quota, and per-mind concurrency. | | `quartermaster` | Selects hosts, loads and unloads model minds, enrolls and releases human minds, drains before retirement, and records the life-cycle events. | | `bosun` | Creates and retires stations on request, coordinates the mind binding with the quartermaster, and records the muster events. | | `mind_host_*` | One adapter per host. Reports free capacity and loads or unloads a model on request. | | `station_*` | One crew process per station. Holds config, standing orders, current job, and mind reference. | | `mission_*` | One `gen_statem` per mission instance. Closes a step and creates the next in one transition. | | `analyst` | Reads metrics, compares declared topology against observed, and writes proposals with predictions. It never applies one. | | `health` | Computes ceremony/progress ratios, watch-bill latency, and stall warnings from the log. | ### Addressing The local grammar is colon-separated: ``` alpha:review:qa alpha:review:qa:tools alpha:review (composite: the department itself) tf1:alpha:review:qa (cross-ship: task force, ship, department, station) ``` Rules: - **Colons internally, slashes in HTTP.** A local address becomes `/ship/alpha/review/qa` on the bridge's routes. A cross-ship address becomes `/fleet/tf1/ship/alpha/review/qa`. The two grammars never collide, and neither needs escaping. - **`@` is reserved for Erlang node names.** An address containing `@` is a bug by definition, and it is obvious at a glance. - **Uniqueness is enforced at registration.** Two nodes claiming a designated address fail at registration, not at delivery, where the symptom is a lost message hours later. - **An address can exist with no live process.** Resolution returns a watch-bill handle. Liveness is a separate question from existence, which is what lets the bridge message a station that is currently stopped. ### Node kinds and delivery Three kinds: - **manned station** — has a mind and handles messages itself. - **department** — has no mind; sends what it receives to its stations by a declared policy. - **unmanned station** — a sensor, effector, or queue consumer. Delivery policies are `broadcast`, `designated`, `first_ready`, `by_predicate`, and `round_robin`. They are declared in the spec and shown on the bridge. A department that invents one at runtime is a bug, because an invisible delivery rule is an invisible hierarchy. ### Station composition A station has two interfaces and one occupant: | Part | Function | Examples | |---|---|---| | Sensor | Brings information in | camera, microphone, log tail, API poll, file watcher, queue feed | | Effector | Acts on the world | shell command, file write, HTTP call, relay, display, speaker | | Crew | Decides what to do; may consult a mind | the station's process | A station can be sensor-only (a listening post), effector-only (a relay or actuator), or both. The crew may consult a local or remote mind; the mind is not part of the station. That split is what lets the same `station` concept cover a camera watcher, a shell runner, and a station that reasons, without pretending they are the same kind of thing. **An effector has exactly one owner.** Two stations never share an effector. A resource that several stations must act on gets one station that owns the acting, and the others ask it to act — many sensors, one hand. Sensors multiply freely, because coverage costs nothing but tokens; effectors are singled, because the alternative is two processes believing they hold the same pen. This is ordinary Erlang rather than something this design invented: one process owns the port, the file, or the device, and everyone else sends it messages. The architectural consequence is that contention becomes a design question with a queue attached instead of a race nobody can see — the owning station's inbox is where demand meets capacity, and its discipline for ordering that inbox is declared like any other policy. Two stations whose effector lists overlap is a topology error caught at design time, not a runtime hazard to be managed. ### Messaging - `cast(Addr, Msg)` — at-least-once, no reply. A department may broadcast or designate; either is safe because nobody waits. - `call(Addr, Msg, Timeout)` — exactly one reply. A department must have a designated responder or return `{error, ambiguous}` at send time, rather than letting the caller time out and guess. - `scatter(Addr, Msg, Timeout, Agg)` — fan-out with a collector process when an aggregate is genuinely wanted. It is its own operation; do not overload `call`. Every message carries an id, an idempotency key, a causation id, and a correlation id. A reply goes to the sender of the message it answers, so an exchange walks back one hop at a time; the correlation id is what makes the hops one exchange, and the causation id says which message caused which. Nothing is ever passed along: a hop is a new message. Dead letters are recorded, never dropped. ## Work and records ### Watch bill and handover Jobs move through `pending`, `in-progress`, `done`, `blocked`, `failed`, `denied`, `canceled`, and `handed-off`. A handover requires a reason from a fixed set: handed off, blocked, denied, canceled, finished with no follow-on, failed, escalated, awaiting clarification, or superseded. Handoff, block, escalation, and clarification also require a target; a clarification carries a deadline and a fallback, so a question that goes unanswered resolves instead of hanging; a supersession names the directive that replaced the work. The watch-bill process enforces this atomically. In Erlang, that is one message to one process, so the transaction is free. Watches carry epochs. A dead node's watch expires and the job returns to `pending` with an incremented attempt count. Two nodes can never both believe they own the same job. A block is not an expiry. While a job waits on a dependency or on an answer, its watch is **kept open** rather than left to lapse, because a legitimate wait and a dead node look identical to a clock, and the retry count exists to catch failures rather than patience. **Jobs run in parallel by default.** A ship is a supervision tree, so its stations are concurrent processes whether or not anybody planned for it. No scheduler hands a ship a turn, and no rule says only one job may be in flight: departments run beside each other, and so do stations inside a department. What limits that parallelism is specific and visible rather than architectural. - **Cognition**, because the mind pool admits a bounded number of turns, and a station waiting for one is idle rather than stuck. - **Effector ownership**, because an effector has exactly one owner and every other station asks it rather than reaching past it. Demand for a resource therefore lands as a queue in one station's inbox, with a declared order, instead of as a race on the resource itself. - **Ordering**, because work that must happen in sequence is an edge in the topology rather than a hope. Two sorties with no edge between them are allowed to run at once, and the design should mean it. So how much runs at once comes from the declared graph and from how many turns the pool admits — nobody switches it on. The bridge shows both halves: the declared graph says what may run together, and the observed graph says what did. A watch is normally closed by a handover. A **standing watch** closes by renewing: its lease is re-taken on a schedule, and a lapsed renewal is the failure signal. That is for liveness claims on capacity the fleet relies on — a mind host that must still answer tomorrow — rather than for work that will finish. It is also the only honest way to hold a claim about something that can decay without anyone touching it. ### Ship's log Every event carries the same fields: ```erlang #{seq := integer(), ts := integer(), ship := binary(), actor := binary(), node := binary(), type := atom(), item := binary() | undefined, causation_id := binary() | undefined, correlation_id := binary(), payload := map()} ``` The ship's log is append-only. Domain code may add, never edit. Several things read it — the bridge's live state, the metrics cohort table, the audit trail, and the observed-topology graph — and so does any station that needs the history, such as a station reading back a night of evidence or the analyst mining clarification traffic. Replay is always possible, which is what makes every other guarantee debuggable. **The log records transitions, not ticks.** A check that runs every fifteen minutes writes ninety-six entries a night and buries the things worth reading. High-frequency samples belong in a **rotating record** — a bounded local file that drops its oldest entries — and only the transitions reach the ship's log: started, failed, recovered, escalated, superseded. The rotating record is a station's working memory; the log is the ship's history. Confusing the two turns history into a metronome. The ship's log is what happened. The rough log is what might be worth knowing. They are separate stores with separate readers: the ship's log is for coordination, audit and replay; the rough log is for promotion into standing orders. Merging them would make the coordination record carry opinion, and the knowledge record carry every event that was never a claim. ### Work tree ``` campaigns/alpha/ # when the work needs more than one mission ├── SPEC.md # intent only ├── campaign.yaml └── missions/MIS-001/ ├── SPEC.md # intent only ├── mission.yaml └── sorties/SOR-001/ ├── SPEC.md # the only level with a full specification ├── sortie.yaml ├── PROGRESS.md ├── PROOF.md └── proof/ ``` **A campaign is earned, not required.** The three levels narrow intent, and a task that is one mission's worth of work has no business growing a campaign above it — it is a mission with sorties under it, `missions/MIS-001/sorties/SOR-001/`, and it takes a campaign only when a second mission arrives to sit beside the first — a different piece of work with its own intent, not the same work again. Repeating one mission against another device, another machine or another repository makes instances, not missions and not campaigns; when the repetitions outgrow one ship, they add ships of the same class to the task force, which changes nothing above the mission. An instance is a run of that mission and lives in the watch bill and the log, not in a new directory: the tree holds what the work is, and the coordination records hold each time it was done. Match the structure to the work, the way the choice between a ship and a working party is made at the other end of the hierarchy. **Campaigns are contexts, and they run side by side.** A campaign is not a phase the fleet passes through; it is a partition of intent, and several can be open at once — `campaigns/alpha` and `campaigns/beta` are siblings on disk because they are siblings in the work, not chapters of one story. The partition matters for cognition as much as for bookkeeping: a station's context holds one campaign's intent or it holds a blur, and a mind asked to serve two projects at once will answer each with the other's assumptions. So a task force serves a campaign when there is one above it, a ship belongs to one task force at a time, and the sortie — which is where the work is fully specified — names the task force it runs under and the campaign above that, if there is one. What concurrent campaigns share is the scope above them: one mind pool, one definition library, one set of standing orders at the top. Those sit with whichever rung is highest — the fleet, or the grand fleet once there is more than one — so promoting the human at the top to grand admiral moves that common layer up with them instead of changing what it is. Intent is the one thing the campaigns do not share, and keeping it apart is why a fleet has more than one. Campaigns and missions carry intent in the frontmatter of one authored `SPEC.md` and go no further. The sortie is where the work itself is written down — what to do, what to capture, and what would count as proof. Proof has three distinct operations: capture an artifact, record an attributed judgment, and read derived readiness. Approval records that somebody with the authority accepted the result; it is not a claim that the work is correct, which is what the proof carries. ### Standing orders One Markdown file per station, `standing-orders.md`, owned by a single writer process. Humans edit the file directly; the process watches mtime and reloads. That gives human-editable content with a serialization point and no lost updates. A fleet or ship may keep its own `standing-orders.md` for rules that outrank a station's; the station's file is the local layer, the fleet's is the top layer. **Nothing writes to standing orders directly.** A station's own memory, an external harness's memory, a compacted summary, and a passing observation all belong in the rough log. Promotion is a separate step: an entry reaches the standing orders only with a source (station, human, sortie, or consort), evidence, and confidence. That rule is not a distrust of external runtimes; it applies to every source, because a confident summary is the easiest way for a bad idea to acquire a citation. **Rough log.** What has not been promoted is kept, not discarded: a per-station `rough-log.md`, append-only. ```markdown ## 2026-10-14 · workshop:builder - claim: staging resets at 03:00. source: observation · evidence: none · status: rejected reason: wrong clock; human ruling 2026-10-15 confirms 02:00. - claim: staging resets at 02:00; migrations must be idempotent. source: SOR-014 · evidence: proof/migration-rerun.md · status: promoted promoted_to: standing-orders#staging-reset ``` Status is `raw`, `candidate`, `rejected`, `superseded`, or `promoted`. Promotion writes the standing order and marks the rough-log entry; it does not delete it. Retiring a standing order sets `superseded_by` and leaves the reason here. The rough log is queried on demand — by sortie, by text, by recency — never loaded wholesale into a station's startup context, and a compaction summary belongs in the rough log rather than in the standing orders. Every entry carries provenance, and human rulings outrank station entries: ```markdown ## 2026-11-07 · workshop:builder - The staging database resets nightly at 02:00; migrations must be idempotent. source: SOR-014 · evidence: proof/migration-rerun.md · confidence: high - Human ruling: never touch `prod/`. source: human · overrides: station entries ``` ## Minds and equipment ### Minds ```erlang describe() -> #{id, kind := model | human, provider, model, context_window, max_output, tools, streaming, json_mode, vision, statefulness := stateless | thread, latency := #{p50_ms, p95_ms}, availability := always | intermittent, capacity := pos_integer(), footprint := none | #{ram_mb, vram_mb, disk_mb}, priority := low | normal | high, pricing := #{input, cached_input, output}}. open(Config) -> {ok, Ref} | {error, Reason}. submit(Ref, Req) -> {ok, TurnId} | {error, Err}. await(Ref, TurnId, Timeout) -> {ok, Resp} | {error, Err}. cancel(Ref, TurnId) -> ok. close(Ref) -> ok. ``` `submit` starts a turn and returns a `TurnId`; `await` waits for the answer or times out; `cancel` stops it. That is what lets a station stay idle rather than blocked while a human thinks, and it handles a slow model the same way. A model queued behind a rate limit and a human in a meeting are both "not yet"; the station does not need to know which. `Resp` carries content, tool calls, finish reason, usage, the model that actually answered, and latency. `describe` carries what a scheduler needs before it commits: kind, latency, availability, and capacity. Each of those earns its place: - **`kind`** — model or human. The pool treats them the same way; the scheduler does not. - **`latency`, `availability`, `capacity`** — a model mind may take seconds; a human mind takes minutes or hours and may not answer at all. Capacity is concurrent turns, and a human's is one. - **`pricing`** — tokens for a model; a human's attention has a different price. Both are recorded, so a routing decision can compare them. - **`footprint`** — what the mind costs on a host: RAM, VRAM, disk. A human mind's footprint is attention, not memory; it is `none` for compute. - **`priority`** — scheduling class. A high-priority mind can preempt a low one when capacity is tight. | Kind | Examples | Capacity | Footprint | Availability | |---|---|---|---|---| | Model | QVAC, LM Studio, a cloud model | N concurrent turns | RAM, VRAM, disk | mostly always | | Human | an advisor, a captain, an auditor | 1 | attention | intermittent | - **`model`** — routers substitute silently. Without it, cost attribution and reproducibility are both fiction. - **`usage`** — the only per-station accounting, because the account-level API is aggregate. - **`finish`** — `stop` means the mind had finished; `length` means it ran out of room mid-answer; `content_filter` means it was cut off on purpose. Only the first is an answer, and a proof built on either of the others is a proof of a fragment. - **`statefulness`** — declared, not assumed. It decides whether migration is trivial or a research project. - **`describe`** — probed at startup, never trusted from config. Cost and latency are recorded per turn and sampled by the bridge. They do not need continuous watching, but they are always available when a routing decision or a budget question comes up. Errors are typed: `rate_limited`, `context_exceeded`, `auth`, `unavailable`, `timeout`, `invalid_request`, `content_filter`, `cancelled`, `declined`. Each drives a different policy: back off, compact, escalate, fail over, or stop. A human mind can decline; a model can be filtered. Both are outcomes the station handles, not exceptions. Routing, fallback, budgets, and idempotency live outside the mind. Context assembly belongs to the station. A stateless model mind is preferred, so a station can migrate by shipping its message list rather than exporting a vendor-side thread. Two local model providers fit this interface today: LM Studio's server at `127.0.0.1:1235`, which is tied to this desktop, and QVAC's OpenAI-compatible server at `127.0.0.1:11434`, which runs on Linux and small devices, so it could serve a VPS station or a station elsewhere on the LAN. Neither reaches the Bionic subscription. The adapter is the same either way: a base URL, a model alias, and the identity and usage checks. **A mind is not part of a station.** A station is a config, a current job, and a message list — cheap enough to run anywhere. A mind is cognition: a model resident in memory, or a human's attention. The model is the chunky part; the human is the scarce part. Nothing requires the mind to share a machine with the station: a station on the laptop can use a model on the desktop, a phone, or a VPS; a station on a VPS can use a model at home. Because the station holds the conversation, either side can move without the other. That makes minds an inventory the fleet keeps, rather than something a machine owns. `mind_pool` keeps the registry — endpoint, model alias, context limit, pricing, location, health, and concurrent-turn capacity — and a station names a mind or a fallback chain. Admission control sits at the mind, because the chunky resource is the one that needs a limit. A station waiting for a turn is idle, not blocked; a failed mind is a typed error with a fallback, not a dead station. **A binding may be episodic.** A station whose work is mostly noticing runs unbound and acquires a mind only when there is something to think about, then releases it. A watch between events then holds no capacity at all, and the quartermaster is free to cull the mind outright — which is what makes an always-on ship affordable, since the resident cost of a ship that mostly watches is a process and a rule rather than a model. Nothing is lost when such a mind is swapped, because the facts are in the station and the log and never in a model's context. **One mind can serve many stations.** Capacity buys concurrency, not capability. A single mind admitted to a dozen stations serves them in turn and the dozen wait, so a wide force can run on a narrow pool — a census of twenty machines on one mind is a long afternoon rather than an impossibility. When the budget will not stretch to a mind per ship, the mind is bound across the task force and the queue does the work. Stateless minds make that rotation cheap in machinery and expensive in context, since every turn re-assembles what the last one knew. **Pool scopes.** The inventory is fleet-wide; the allocations are local. | Scope | Holds | May do | |---|---|---| | Fleet | The inventory: every mind, pricing, global policy | Add or remove minds; set quotas | | Task force | An allocation for a campaign | Reserve capacity; route across ships | | Ship | A local view: health, latency, per-ship quota | Bind stations; fail over | | Station | A binding: mind id and fallback chain | Use; never allocate | A station never owns a pool. It names a mind or a fallback chain; the ship's view resolves it, and the commodore's allocation bounds it. **Mind states.** A mind can be **ready** and unallocated: present in the pool, capacity available, bound to no station. A human advisor on standby is the clearest case. Allocation is a commodore's or captain's act; binding is a station's config. | State | Meaning | |---|---| | Provisioning | Host selected; model loading | | Ready | Health probe passed; unallocated, bound to nothing | | Allocated | Reserved to a task force or ship | | Bound | Named by a station's config | | Draining | No new turns; existing turns finishing | | Retired | Unloaded or released; removed from the pool | | Offline | Unavailable; health probe failing | An unallocated human mind is not idle compute; it is attention that can be committed when a question is worth it. **Spin-up.** A quartermaster selects a host with free capacity, asks the host adapter to load the model, waits for the health probe, and registers the mind as ready. Human minds are not spun up; they are enrolled and released. Policy bounds it: min/max capacity, budget, priority, cooldown. **Cull.** A cull drains before it unloads. No new turns; in-flight turns finish or time out; bound stations must have a fallback or be rebound; then the host unloads the model and the mind is retired. A human mind is not culled — it is released: open questions are handed off, and the person is marked unavailable. **Who decides.** The admiral sets fleet policy and budget; the commodore allocates across ships; the captain binds; the quartermaster executes. A cull that would strand a bound station needs the captain's approval; one that affects another ship's allocation needs the commodore's. Remote minds need a bearer token and a network rule. QVAC supports `--api-key`; LM Studio does not, so a non-local LM Studio endpoint belongs behind a reverse proxy or on a trusted LAN. In practice LM Studio stays the desktop provider: no token, and a GUI app rather than a service. A box whose only job is serving models should run QVAC or llama.cpp instead. The bridge shows the pool — attached stations, watch-bill depth, latency, and which mind answered each turn — and the response's `model` field, or the mind id for a human, is what makes that attribution honest. A **model** mind needs room for the model and its KV cache. The practical floor is about 2 GB of RAM, and 4 GB is where small chat models stop being painful. A **human** mind needs attention and time, not RAM. A 512 MB device is station-side, not model-mind-side: it can call a mind, not be one. ### Harness When the model mind is stateless, the station owns the loop: assemble context, call the mind, execute tools, feed results back, compact, repeat. Tools run in a sandboxed runner. Duplicate tool calls within a single turn are a real failure mode, not a theoretical one. The executor needs a declared per-turn policy — dedupe by `(name, canonical_args)` or execute all — because the difference between a clock and a delete is the difference between an annoyance and an incident. A harness can also be external. A NullClaw, PicoClaw, or ZeroClaw gateway can sit behind a station or federate over A2A, with the ship keeping coordination and the external runtime keeping the tool loop. Its memory then belongs in the station's own rough log, not the ship's standing orders. Tool execution can be sandboxed in a rootless container. Podman is the candidate on Linux nodes; it is not an option on the Windows development host without WSL2, which the project has ruled out. ### Tools and equipment A tool is a piece of **equipment** — the word the vocabulary already uses for the non-crew parts of a station. That settles most of the question: tools are not a separate species here, they are the fittings on a station, and the rules that govern effectors govern them. **Use is ordinary.** The crew decides, the station's loop executes, the tool runs in the sandboxed runner. A tool call is effector use, so it cannot reach past the ownership rule and two stations never share one. **Tools are made where the work is.** A station that keeps solving the same problem by hand writes a tool for it, and a station that needs a tool it cannot write asks for one: its department lead can have another station write it, or a station whose whole role is making tools can be mustered for the purpose. That is unusual rather than forbidden — a tool is ordinary equipment, and nothing says a station may only fit what it made itself. What a mind produces is a **candidate** until it has run. The run is what proves a tool, and anybody's run counts, the author's included: a tool that has never been run is a claim rather than equipment. What a second party adds is not permission but evidence — somebody else's run says the tool works on inputs its author did not choose, which is the only thing worth knowing when it is fitted somewhere new. **Fitting is a topology change.** Attaching equipment changes what a station can *do*, so it goes through a commission like a muster, and it is checked the way a reused station's effectors are checked — against what this design says may touch that resource. A tool that helps within reach the station already has is a setting change. A tool that grants new reach is a **fitting**, and that is the moment to ask what else now touches the resource. **A tool inherits its station's authority, never more.** It cannot be handed a power the station does not have, and a tool that seems to need one is evidence the station is wrong rather than the tool. This is the rule that matters most, because a tool written by a mind, running with whatever its station can reach, is the most direct path by which a mind acquires powers nobody granted it. For v0 that is the entire permission model: no per-tool policies and no capability lists beyond the station's own effectors. **Equipment goes stale; it does not wear.** A tool is code, and code does not degrade by sitting in a store — but the world it was proved against moves. So a tool declares what it depends on: an API and its version, a binary, a file format, an operating system. When one of those moves, the proof stops speaking for the tool and the tool is marked **stale**. That list only covers the dependencies somebody thought of. Hardware gets replaced by something that behaves almost the same, a specification is amended without a version bump, a library quietly changes what it does — and none of it is announced. Those arrive the way they always have: the tool fails. A failure is therefore evidence about the world rather than a verdict on the tool, and the first response is a stop rather than a retry — mark it stale, and keep the inputs, the output, and the environment of the failing run, because that run may be the only record of what changed. Which makes one thing worth stating plainly: **a tool should fail rather than guess.** A guessing tool produces confident wrongness downstream, where some proof will vouch for it and nobody will look again; an erring tool produces an event. Failures stay cheap only while they stay failures. The states are candidate, proven, fitted, in service, stale, and retired. A stale tool is either re-proved against the world as it is now, or retired; a patched tool is a **new candidate** rather than a repaired one, because a patch is a version nobody proved. There is no calendar in this — staleness is caused by something, and re-proving on a schedule would be busywork dressed as diligence. The fleet keeps a **store**: the catalogue of proven equipment with its source, its version, what it is able to touch, and how it expects to be sandboxed. What reaches the store keeps its provenance: where the tool came from, what it ran against, and what it proved. A tool without that is a file somebody liked. ## Missions and the bridge ### Missions One `gen_statem` per mission instance. Closing the active step is a single transition: close the step, create the next step's job, append the audit entry, update the instance. The runtime is a scribe, not a gatekeeper. The watch bill's handover rule remains the authority. ### Bridge A separate OTP application, deployable on its own node, subscribing to the ship's log stream. It never polls stations and never talks to Bionic. One page, with routes: - `/ship/alpha` — topology, watch-bill depth, health. - `/ship/alpha/review` — department detail. - `/ship/alpha/review/qa` — station detail: current job, last transition, transcript, standing orders, cost. Every route also lists open clarification requests, because a blocked job with a named question and a named person is the most actionable alert a ship can raise. It shows the **declared** topology from the spec and the **observed** topology from message edges in the log. If a swarm has grown a hub, or a hierarchy has grown a bypass, both are visible. The bridge can send a message to any address at any altitude. A message to a department is delivered to one of its stations by that department's declared policy, which is how "tell the review department" keeps working when membership changes. Served by the ship, rendered in a browser. No CORS, because nothing in the browser talks to the model endpoint. ## Distribution and growth ### Distribution TLS distribution with a self-signed CA. Certificates are files, not a service. The cookie still authorizes; TLS authenticates and encrypts. Pin the same OTP major on every node, fix the distribution ports, and open EPMD. No VPN is required on a trusted network or with TLS. Consistency is a separate problem: one owner per watch bill, watches with epochs, and no promise of consensus. Partitions are survivable and visible, not invisible. Migration moves work, not processes: 1. The watch bill closes the job with `handed off`, naming the destination. 2. The station serializes pure data — no pids, ports, or funs — and the destination adopts it. 3. Conversation history comes from the ship's log, not from a memory dump. 4. Open ports are closed and reopened, never transferred. ### Enrollment and self-extension Capacity is gained at whatever scope needs it — a ship, a task force, a fleet — and the enrolling is done by a station with the effector for it; what the scope gains is the node, the mind, or the consort. There are three kinds, because the control plane, the mind plane, and the consort plane have different costs. **Node enrollment (control plane).** A new Windows, Linux, or macOS box joins as an Erlang node. One portable artifact — an escript or a release tarball — plus a short-lived join token. The sequence is fixed: 1. Check the OTP major and the platform. 2. Install the code and the service wrapper: a Windows service, a systemd unit, or a launchd job. 3. Generate a keypair, have the fleet CA sign the node certificate, and write the distribution config. 4. Write the node's identity: ship name, cookie, seed nodes, and the roles it may host. 5. Start, register with `registry`, and pass a health check that includes a real `net_kernel` connection. `lowpassage node join <token>` and `lowpassage node leave` are idempotent; `lowpassage node upgrade` replaces the code without dropping the identity. An air-gapped bundle carries the code, the CA, and the config, so the target needs no internet. The token is single-use and expires, the certificate is per node, and the cookie rotates on join. A Linux node can also be packaged as a container image and run under a Quadlet unit. That is an option, not the default: distribution ports, the certificate's hostname SAN, and persistent volumes turn a simple release into a networking problem. **Mind enrollment (data plane).** A model mind enrolls as an endpoint serving an OpenAI-compatible API, with a bearer token and a health probe. A human mind enrolls as a mind with a console and a delivery channel; it has capacity one and intermittent availability. Neither joins the cluster. `mind_pool` records both. **Consort enrollment (federation).** A runtime that already owns its loop and tools joins as a consort over A2A or HTTP, not as an Erlang node and not as a mind. It needs an address, a capability card, and a token; `router` hands its messages to the federation adapter, and the ship's log records what it was asked and what came back. What a consort adds is reach and a loop the ship did not have to write: its own tools, its own channels into places the ship cannot go — a chat service, a mail account, a device API — all held behind one address. It is neither a host for stations nor a mind to consult; it is a worker that brings its own hands. NullClaw, PicoClaw, and ZeroClaw fit here. **Android.** There are three possible roles, and two are worth designing for. - **Android as a mind host** is plausible. QVAC's SDK runs on Android through Expo, and there is a Kotlin SDK for native apps; the CLI's HTTP server does not run there. So this is a small app that embeds QVAC, serves `/v1` on the LAN, and runs as a foreground service. USB is the deployment channel: install and configure with ADB, grant the foreground-service and battery permissions, then untether. Runtime is Wi-Fi: the app serves `/v1` on the LAN and registers with the mind pool. USB is not the production transport. The app and its provisioning are specified in [[Low Passage Mind Host]]. Treat it as best-effort capacity: charging, screen off, same network, thermal limits, and a battery that will eventually win. - **Android as a consort** is possible. PicoClaw ships an Android APK, so the device can run an agent runtime and expose its gateway. It is still not an Erlang node; it is an external agent with an address and a capability card. - **Android as a station** is not a target. Erlang/OTP can be made to run under Termux or as a cross-compiled release, but it is experimental, fights the Android sandbox, and has no reliable background execution. A phone is not a node. ### Topology and hierarchy A ship is a directed graph. A hierarchy is a tree-shaped region with fan-out limits and one path upward. A swarm is a denser region. They are the same data structure, so the ship does not have to choose a philosophy. The supervision tree is about failure ownership. It is not an authority hierarchy. Keeping those two graphs separate is what makes a flat peer group under one supervisor possible. The analyst observes the graph, compares it to the declared one, and proposes changes. It does not apply them. **A ship is built to spawn, and has one expensive part.** Structurally the design is built for spawning. A failed station costs its own work rather than the ship's, its address outlives it, the job returns to the watch bill, and a replacement takes over without ceremony — which is exactly the swarm habit of letting some fail and patching the holes. Three things make the holes patchable instead of mysterious: every job has one owner at a time, a missing result is recorded as missing with a reason — still running, failed, or never assigned — and every artifact has one writer. **Breadth is the native case.** Twenty systems surveyed at once is twenty ships each running an ordinary survey, plus a command ship to collate — not one solver working patiently through twenty systems. Each instance gets its own judge and its own proof, a ship that fails costs one row instead of the census, and the collator needs no mind at all, because assembling the report is a set difference against the expected list. Cost grows in step with the work rather than in leaps: twenty surveys are twenty sets of turns, and the twenty-first machine costs what the first one did. **Parallelism is implicit at every level.** Nothing needs switching on for two ships, two task forces, or two missions to run at the same time: they are separate processes with their own registries, watch bills, and logs, and the runtime carries them together without being asked. They may or may not sit on separate nodes — a ship is a separate instance either way, and sharing a node costs it its failure isolation, not its concurrency. Only a few things stop them — a shortage of minds, a resource two of them both reach for, or work that is ordered rather than independent — and the last is the designer's business, since two sorties with no edge between them are allowed to run at once. That is why breadth keeps being the cheap answer in three different tests without any of those tests mentioning scheduling: the fleet never decides to run in parallel, it decides what to build, and parallelism follows from there being more than one of something. **Redundancy is a different use of the same parts, and it is modelled rather than accidental.** The watch bill refuses dual ownership, so several attempts at one answer are never a side effect of spawning: that is N jobs against the same input plus a reconciler, and the reconciler is where the hole gets patched. Sometimes right, occasionally necessary — but it is the only way of working that spends turns without doing more work. **Cognition is the one thing that does not widen that way, and it only bites when the fleet races.** A station is nearly free: a process and a rule. A mind is not. In Erlang, spawning twenty workers for twenty units of work costs almost nothing beyond the work itself, and here it costs twenty sets of turns — proportional, and therefore fine. What does not transfer is spawning many *thinkers* at one question and keeping the survivor, because turns are the fleet's scarcest resource and a racing fleet pays twenty times the cognition to arrive at the same answer once. **Cheap units buy coverage, not capability — at every level.** A station is a process and a rule. A ship is a supervision tree, a log, and a set of addresses. A task force is a grouping and a command ship. None of those is expensive to add; only minds are. So the fleet widens wherever widening helps, and each level widens for a different reason: - **Stations** widen the senses and the hands: more places to watch, more sources to ingest, more devices to act through. - **Ships** widen isolation: each ship keeps its own judge, its own evidence, and its own log, so a failure costs one row rather than the whole result. - **Task forces** widen command: a commodore absorbs the ordinary failures of many ships without troubling the fleet. None of them widens cognition. The mind pool stays the mind, and the bottleneck stays turns. So the pattern is the same at every level — **edge filtering**: each unit does what it can locally with a rule or a small model and escalates only the distilled event upward. Without that, a fleet of any size is a token furnace with extra steps. ## Command ### Command and authority A **commission** is a named scope of authority attached to a role. It does not say who occupies the role, and it does not require a station. A station holds one where it must answer for what it decides — where it writes, acts on something shared, or leads other stations — and a station that only follows orders does its job and escalates. ```mermaid flowchart TB Fleet["Fleet — Admiral"] TF["Task Force — Commodore"] Ship["Ship — Captain"] Analyst["Analyst — station, no commission"] Dept["Department — Commander"] Stn["Station — Lieutenant"] Sensors["Sensors"] Effectors["Effectors"] Consort["Consort — allied, outside the chain"] Fleet --> TF TF --> Ship TF -.-> Consort Ship --> Analyst Ship --> Dept Dept --> Stn Stn --> Sensors Stn --> Effectors ``` A task force is a coordination layer, not a command over stations. It is commanded from a ship inside it — the **command ship** — carrying the flag deck and the flag log, so the commodore's staff watches ships and allocates minds without reaching into a ship's departments, and without needing a node of its own. A ship with a crew is cheaper to stand up than a node that does nothing but command, and it keeps its own record if the task force comes apart. **Problems stay local.** A ship that stumbles inside a task force is the task force's problem, not the fleet's: the commodore retries it, moves its work to another ship, or accepts the gap with a reason. What goes up is what a task force cannot answer for itself — capacity it does not hold, policy it does not set, or an irreversible fleet action. An escalation a commodore could have settled is a small failure of the same kind as a crew guessing at intent, and it is measured the same way. | Commission | Scope | Decides | |---|---|---| | **Grand Admiral** | Grand fleet | Intent across fleets, allocation between them, irreversible actions above a fleet | | **Admiral** | Fleet | Standing orders, fleet intent, irreversible fleet actions | | **Commodore** | Task force | Ship composition, mind-pool allocation, cross-ship conflicts | | **Captain** | Ship | Ship mission, release, ship-level irreversible actions | | **Commander** | Department | Department context and department approvals | | **Lieutenant** | Station | Actions within one post | The occupant is deliberately not a column, because it is not a distinction: any of these may be held by a human or a model. The single exception is the post at the top of the ladder, and that is a rule about the post rather than about the rank. **Allocation follows commission.** The admiral owns the inventory, the commodore allocates capacity, the captain binds stations, and the station uses. No station allocates its own capacity. Exactly one post in the whole structure is fixed to a human: whichever commission sits at the top of the ladder. Everything below it — admiral ranks included — may be held by either, which is how a human grand admiral can command admirals that are minds. The reason is accountability, not seniority: someone has to answer for the whole scope, and a mind can be swapped mid-question. The quartermaster is a station, not a commission: it acts within the budget and policy the admiral sets. Below the top, human occupancy is a capability rather than a habit. A commodore's day is allocating capacity and resolving other ships' failures at machine tempo, so a person in the post would need an XO to carry that tempo and would still be the fleet's slowest component. The post is almost always a mind's. **Advice is added, not substituted.** When inputs are strange enough to want a person, the fleet does not put a human in the commodore's chair and slow the chair down. It enrolls a human *mind* and gives it a console: the commodore keeps the watch bill and the allocations, the person is asked questions and answers them at the speed a person answers. That is `kind: human` doing its ordinary job — capacity one, intermittent availability, no different in kind from a model mind except that the slow turns are the ones worth waiting for. If the advisor has to answer for more than one ship, the console needs a ship of its own, and the smallest ship in the fleet is one station with one person aboard — captain and crew in the same head. That is not ceremony either: a console sitting on somebody else's ship belongs to that ship's commodore, its log, and its failure domain, so a person consulted by three ships should not be living inside one of them. If the pattern recurs, it becomes a class like any other; if it happens once, it is a working party and nobody writes anything down about it. **Posts are not ranks.** The Grand Admiral's staff is run by a **chief of staff**, which is a post rather than a commission: the occupant holds whatever commission the work needs — usually a Commander's, a Commodore's when the staff has to command rather than coordinate — so the post says what they do while the commission says what they may decide. A flagship's **flag captain** runs the ship while the admiral runs the fleet, on the same separation. That is also how the rank ladder stays short: staff work at any level is a post, so it never needs a rank invented for it. **The fleet's executive.** The Admiral is a principal with a console and no station, so the fleet needs one officer on the flag deck to turn intent into work: the **Captain of the Fleet**. That is the XO rule at fleet scale — the Admiral is the human in the post, so the work flows through an executive rather than queueing at one person's attention. It is a post rather than a commission — the occupant holds whatever commission the work needs, which at fleet level is a Commodore's, because composing task forces and allocating mind-pool capacity are precisely a commodore's powers. That post is not the same office as commanding a task force, and the difference only becomes visible once there is more than one. A fleet with three task forces has **three commodores, one per formation and local to it**, and one Captain of the Fleet who speaks for all of them to the Admiral. At bootstrap the two are a single station, because there is one task force holding one ship — which is why the smallest fleet looks as though the commodore is the admiral's deputy. It is, for as long as it is also the only task force commander. **One human, many commanders.** Past three or four subordinates the binding constraint at the top stops being coordination and becomes one person's attention. Nothing in the runtime fixes that, so the remedy is the command-level form of edge filtering: reports arrive distilled — the decision, its cost, and what it blocks — rather than as a retelling of the work. A human grand admiral over six admirals is not thinking more than a human admiral over three; they are reading shorter messages, which is why the analyst writes one page, and why a status report that takes an hour to read is a defect in the report. **Most stations are uncommissioned.** A sensor watcher, a relay, a queue consumer: no rank, no ceremony, because nothing it decides reaches further than its own readings. A commission appears where a station has to answer for a decision rather than carry out one. **A human can hold a commission at any level**, with or without a station. A human captain occupies the captain's station; a human commodore sits on the flag deck; a human auditor holds a commission and no post at all. The occupant is replaceable at every level — by another human at the Admiral, by either elsewhere — but the commission is not. **A principal** is a commission without a station. It has an address for decisions — a console, a phone, a notification channel — but no crew, sensors, or effectors. It exists so the architecture can represent an owner, an auditor, or a duty officer who is not posted anywhere. **Decision path.** Irreversible actions route to the lowest commissioned role with the right: ```mermaid flowchart TD A["Irreversible action requested"] --> B{"Lowest commissioned role with the right?"} B -->|yes| C["Route to its occupant: human or model"] B -->|no| D["Escalate to the next scope"] D --> B C --> E["Record the decision in the ship's log"] E --> F["Human ruling outranks a model ruling"] ``` **Vacancy rule.** An unfilled commission is not an authorization. If nobody holds the right, the action escalates or waits; it never silently proceeds. An empty captain's chair must not approve a release. **Attribution.** Every human ruling is an event with `source: human`, and it outranks a model ruling, exactly like the standing-orders provenance rule. That is how a local human decision remains visible to the rest of the fleet. ### Clarification A crew that needs a fact it does not have asks whoever owns the fact. That runs in every direction — up, down, and across — because the direction is set by where the fact lives, not by rank. A station asks its department head about local context. A Commodore asks the Admiral about fleet intent, because intent is the Admiral's to state. A captain asks a station what it actually observed. A station asks the peer whose sortie produced the artifact. Rank decides who may order what, and how far a question may climb — though never whether one may be asked. A fact owned inside your own command is a message away; one owned above it goes up a scope at a time — a station to its lead, a lead to its captain, a captain to its commodore, a commodore to the admiral — because the attention of whoever sits at the top is the fleet's scarcest resource, and the chain is what keeps it from becoming everybody's inbox. Each level answers if it can; where it cannot, it asks the level above itself, and says why. What it replaces is inference. Reading an order for what it probably means, instead of what it says, is the most expensive error available, because it produces work that is confidently wrong and expensive to unwind: a ship mustered for a one-off, a one-off treated as policy, a station designed around a constraint nobody imposed. A **clarification request** carries three things: the question, the decision it blocks, and the options with what each one costs. "What should I do?" is not a clarification request; it is handing the decision back, and the answer will be a question. - **Ask the owner directly when you know who that is and they are within your reach.** A peer station, your own department head, the quartermaster: routing those through the chain turns a commander into a switchboard and taxes the cheapest useful message in the system. - **But check what you already hold first.** A station carries its own standing orders, its ship's, and its fleet's, so the context a higher rank would bring is usually already on the shelf, and a question answered there is not a question. What is *not* on the shelf is not context either — it is somebody's memory — and the fleet's answer to memory is promotion, not routing. That is why checking first is right: a question answered on the shelf never needs an owner, and a question that does need one still does not need everybody's opinion on the way up. A chain that keeps being asked the same thing is a standing order that has not been written. - **Ask upward when you do not know who owns it.** Finding the owner is itself a command function, and that is the only reason an unaddressed question goes up rather than sideways at random. - **It climbs by being asked again.** A recipient who cannot answer does not pass the message on: it sends a new request at its own scope, saying why it could not settle the one it received, so what the next level sees is the question, the decision it blocks, and the reason it reached them. Each hop is a new message and a new sender, tied to the others by one correlation id. The answer comes back a hop at a time, each level replying to the one that asked it, and every hop lands in the log. - **The request stays where it was raised.** The hops are new messages, but the request is one thing: the job that is blocked sits on the station that asked, its fallback is what fires if no answer ever comes, and its lead is the target until the lead asks above itself. Who can answer a fact is a different question from who is holding the question at the moment. - **Not every question is entitled to an answer.** A station's orders bound what it may ask about: a probe sent to catalog this machine has no business asking what is on another one. The owner of the fact refuses, with the reason, so the refusal is a record rather than a silence — and the bound is the one set when the mission was commissioned, not one negotiated at the moment of asking. When the fact is genuinely needed, the question was the wrong request: what has to change is the scope, which means an amendment from the commission that issued the orders, or the work stopping and saying why. Exceptions exist and are narrow; that commission grants them, and a station does not claim them. - **It is a block, not a failure.** The job goes `blocked` with reason `awaiting_clarification` and a target. A ship waiting on a question is not stalled by accident, and the bridge can name the person who can unblock it. - **It carries a deadline and a fallback.** Every request states what happens if no answer comes: proceed on a named assumption, or escalate. The deadline is a duration the watch bill can time, or a step the work reaches anyway — the exposure approval, the next muster — and never a figure of speech like "end of watch", because the runtime has to be able to fire it. A question with no deadline is a deadlock with better manners. - **The answer may be work.** An owner who does not hold the fact can commission the work that finds it, so the reply can arrive as a mission's result rather than as a sentence. Most capacity requests start exactly this way. - **The answer is recorded as a ruling.** When the fact and the decision are the same thing — "will this recur?" — the answer is policy rather than lookup. It is recorded with its source, it outranks the asker's inference, and it becomes evidence for how that scope was run. **How it is written.** The question goes on its own line, the decision it blocks is named plainly, and each option is its own item with its cost. That layout is what lets an answer come back in one line instead of an exchange, and it is the difference between a crew handing over a problem and a crew handing over a decision to be made. It is a project convention rather than a house style: the same text is read by a human on the bridge and by a mind in its context window, and a paragraph carrying four conditional clauses is exactly where a reader of either kind loses one. Layout is part of the message, and it goes into the log with it. A reply is the inverse: the asker did the work of laying out the options, so the ruling is short — the decision and any bound on it, and nothing else. **Asking downward has its own hazards.** A question from an authority is not an order and must not quietly become one: the station's watch stays where it is, and if the asker wants the work done differently, that is a handover with a target rather than a question. An answer given downward comes from the record, and labels what is evidence and what is opinion, because a station asked by its captain will otherwise produce the answer it believes the captain wants. And "I do not know" is a valid answer, recorded as one — a fleet that punishes it gets confident fabrication instead. **Asked from outside the chain.** A consort owns facts and cannot be compelled, so a request to one is a request in the ordinary sense: it may be declined or ignored, and the deadline and fallback carry the whole weight. What a consort answers comes from outside, so it lands in the rough log with its source and never goes straight into standing orders. **Assuming instead.** Waiting is not always right. Where a decision is cheap to reverse, a crew may proceed on a stated assumption and flag it: *assumed one-off; if this recurs, the ship-or-party question reopens.* The line is reversibility. Ask when the answer changes what gets built — a ship or a party, a policy or an exception, a station or a department. Assume and flag when it only changes the order of the steps. A written assumption is not a guess; it is a debt with a due date. **And read the plain ones.** Not every terse instruction is an ambiguous one. A crew that asks about a sentence it could simply have read is as much a problem as one that guesses at a sentence it could not, because both spend a turn that the work did not need — one on a question, one on a rewrite later. The test is the same one: could the answer have changed what gets built. If not, it was never a question. **Repeated questions are a metric.** A question asked once is a gap in one crew's knowledge. The same question at the same address week after week is a standing order that is not saying what it means, and the analyst reads clarification traffic looking for exactly that: intent that keeps needing to be restated is intent that was never written down properly. ### Orders change A **directive** is an instruction for one mission; standing orders are the rules that outlive it. A directive is issued once and amended as often as its issuer likes. Nothing about being mid-mission freezes it, so the fleet needs a rule for what a change of orders does to work already under way — and the rule has to keep both intentions visible, because the interesting failure is not the crew that stops. It is the crew that quietly finishes something nobody wants any more, or the crew that decides its old order "really meant" the new one. **Who may amend.** The commission that issued the directive, or one above it, and never the crew executing it. A station that re-scopes its own job has promoted itself, and the same holds for a ship re-scoping the mission it was given. A crew that believes the order is wrong reports that and asks; that is an escalation, not an amendment. **Amend, stand down, or recall.** An **amendment** changes what the fleet is trying to do, and work it does not touch keeps going. A **stand-down** stops work at a named scope — a station, a department, a ship — while everything outside that scope carries on. A **recall** stops everything the directive covers, now. All three are scoped rather than absolute, because the system is parallel. Stopping one department is an ordinary act of the commission that owns that department; a recall reaches everything the directive touches, and it is an irreversible action recorded as one. Anything short of a recall lets a crew finish the step it is on, which is what keeps a change of mind from producing half-written artifacts: the sortie boundary is the commitment boundary. **Stopped is not paused.** A sortie that is stopped closes with reason `canceled`, and goes back to design if it is ever wanted again. A sortie that is only paused returns to `pending` with its state in its `PROGRESS.md`, so resuming costs a fresh crew a briefing rather than a re-derivation. The distinction is worth insisting on, because a pause that quietly becomes an abandonment leaves a job in the queue that nobody intends to do. **Work in flight is re-examined, not re-interpreted.** If the amendment does not touch what a sortie is proving, the sortie finishes and its handover says it finished under the old intent. If it does, the sortie closes with reason `superseded` and the job goes back to design. Either way the crew states which intent it was answering, and nobody reconciles the two by guessing. **Proofs stay true; their relevance does not.** A survey's report captured under last month's intent is still an accurate report. It is marked as belonging to a superseded intent — never deleted, and never quietly re-filed under the new one. That is what an append-only log is for. **Intent is versioned like a class.** An amended spec takes a new version, and cohorts do not mix across versions. A fleet that compares a run answering one question against a run answering another has learned nothing while believing it learned something. ### Muster and working parties A station can hand work to an existing station without ceremony. Creating a station is a topology change, so it goes through a commission. | Action | Who may do it | Mechanism | |---|---|---| | Delegate to an existing station | Any station | Watch-bill handover | | Request a new station | Any station, to its department head or captain | A request with role, sensors, effectors, mind, budget, lifetime | | Muster a station | The commission that owns the scope; the bosun executes | The bosun creates it and registers the address; the quartermaster binds a mind | | Request a consort | Any station, to the captain or commodore | Consort enrollment | **Authority cannot exceed the granter's commission.** A Commander may muster a Lieutenant within its department; a Lieutenant may not muster a Commander. A Captain may muster a department or a ship-level station; a Commodore may muster across ships. The final scope is whichever commission sits at the top of the ladder a fleet actually built, not a fixed rank — a Grand Admiral where there is one, an Admiral otherwise. **Asking for capacity.** A station that needs more than it has asks the same way it asks for a fact, and the request climbs the same chain, stopping at the first scope that can actually grant it. A station that needs another station asks its department head or captain, who can muster one inside the ship. A ship that needs another ship asks its commodore, who can muster one — and a commodore told that a survey needs twenty machines probed at once has an answer the captain does not: add a ship and let it do the work. A fleet short of a ship's worth of capacity asks the admiral, who owns the inventory. The admiral is not consulted in the ordinary case, because adding a ship needs neither fleet intent nor fleet policy. A commodore may simply add one. What comes back differs from a clarification. A clarification returns an answer; a capacity request returns **work** — the new ship does the thing, and the requesting station's job picks up from the result. That is why the request names the work and the proof it needs rather than just the capability: whoever grants it has to design against both. **A question is usually answered by work.** Most capacity requests begin as a clarification. A station asks for a fact it needs, the owner does not hold it — nobody has been to that machine, nobody has counted those devices — and the honest answer is not a guess but a job: commission the work that finds out. The request goes up as a question and comes back as the result of a mission, served by however many ships the work turns out to need. That is why the two share a chain: asking for a fact and asking for capacity are the same request until somebody establishes that the fact already exists. A station asking "what is on that machine?" is, without meaning to, asking for a survey. **Working parties.** A working party is a station mustered for one sortie, with a role, a mind binding, a budget, a lifetime, and a stop condition. It is retired when the sortie closes, and its rough log is folded into the parent's. The parent remains accountable for the outcome; it delegated the work, not the responsibility. **The request path.** request → approval by the scope's commission → the bosun musters the station → the quartermaster binds a mind → the registry assigns the address → the ship's log records the event. **Roles are authored, not assigned.** A station exists because some work needed a place to happen, so the role in the request is written for that work rather than chosen from a catalogue. `enroll:firstlight` exists because a phone had to prove it would answer untethered, and nothing about it required permission beyond the commission that mustered it. The commission bounds the scope and the bosun enforces the caps; neither keeps a list of permitted roles, by the same rule that keeps ship classes from turning into a taxonomy. What is not free is the address: the registry refuses a second claim on one, so an invented role is unambiguous the moment it registers. **Guards.** The runtime enforces max stations per department and ship, max delegation depth, budget per sortie and mission, mind capacity, and a lifetime with a stop condition. The numbers are settings the scope's commission owns, on the same footing as the idle threshold that sends a ship into reserve: the bosun proposes defaults, the analyst proposes changes when the fleet's behaviour shows one is wrong, and nobody derives them from first principles. Two are safety rather than tuning and cannot be set away — a working party with no stop condition is refused, and delegation depth stays under the same cap on recursion that binds the analyst. **No mind available.** A binding is a lease, not a guarantee. If the primary mind is at capacity or offline, the station tries its fallback chain. If none can serve it: - **`wait`** (the default): the station is **ready and unbound**. Its job is `blocked` with reason `mind_unavailable` and a target — the quartermaster for capacity, the captain for allocation. The pool notifies the station when capacity frees; there is no spin-wait. - **`escalate`**: the request goes to the captain or commodore; if the answer is budget or policy, to the Admiral. - **`fail`**: the binding fails with `no_mind_available`; the job fails with a reason. Reserve this for hard-real-time work. - The quartermaster may provision a model mind on a host. If no host has capacity, the answer is `no_host_capacity`; it may preempt a lower-priority mind, which returns that station to ready-unbound and re-queues its job. - A human mind is not provisioned; it is enrolled and available, or not. The request waits, escalates, or is declined. A **hail** is how a fleet asks for attention explicitly. It is deferred, and it is the piece that makes a human mind feel present rather than merely enrolled. **What an unbound station can still do.** Sensors, effectors, and deterministic rules keep working; cognition does not. A listening post is fine. A cognitive station is not; it waits or escalates. **A ship can need no mind at all.** If every station in it is a rule, the ship is a supervision tree, a watch bill and a log with nothing to consult: it is mustered, takes a mission, produces its proof and closes it, as long as nothing in the work needs a judgment a rule cannot make. Recon is that ship — its check is a hash comparison — and a picket spends most of its life that way. The moment one sortie needs a judgment, the ship needs a mind for that sortie and not for the rest, which is why binding is per station. ## Force design Stations follow work, not the org chart. Before the bosun musters anything, the Commodore writes an **order of battle**: the design for the ship or task force. 1. Restate the outcome and the evidence. 2. List the work: observe, transform, judge, command. 3. Group the work by context domain. 4. Give each domain one station with a reason to exist: a sensor, an effector, a judgment, or command. 5. Assign the proof obligations to independent judges. 6. Add command and commissions; draw the handovers. 7. Allocate minds: which stations need cognition, which are deterministic. 8. Check the budget and caps; start with the smallest topology that produces the proof. 9. Record the order of battle in the flag log; then muster. ```mermaid flowchart TB Intent["Intent + evidence"] --> Work["Work: observe, transform, judge, command"] Work --> Domains["Context domains"] Domains --> Stations["Stations: sensor, effector, judgment, command"] Stations --> Proof["Proof obligations + judges"] Proof --> OOB["Order of battle"] OOB --> Muster["Muster"] ``` **The budget check comes before the muster.** Step 8 is arithmetic, and for work that brings a device into the fleet it is the whole of the decision: compare what the vendor publishes for the device against the footprint of the smallest mind worth having. That check is a turn of the Commodore's own mind, musters no station, and opens no sortie, because it reads nothing off the device — which is also what keeps it honest. It can only refuse: passing it registers nothing, and the numbers that reach the mind pool are measured later, by a station, on the device. The line between a preflight and a sortie is what it reads. Published figures are design work; anything taken off the device is measurement, and measurement belongs to a station that owns the access. Every station must justify itself. A station with no sensor, no effector, no judgment, and no command is a passenger. A station that only repeats another station's judgment is ceremony. Add a station when a context domain or a proof obligation demands it, not because the org chart has a box. A ship class is the reusable topology; the order of battle is the instance rationale. If the design works, promote it to a class. If it does not, record why and retire it. **Reusing a class.** Check the definition library before designing anything. Most work resembles something already flown, and reusing a proven topology saves the expensive half of force design — deciding the context domains, keeping the judges independent, and sharing out the proof obligations. Designing from scratch when a class would have served is waste that looks like diligence. The harder question is how far a class can be bent before it is a different class. A class is a written order of battle — stations, edges, the mind each station needs, proof obligations, budget — with two short lists attached: the settings it allows, and the few things it guarantees. Those two lists settle it. The mind requirement belongs to the class, because it decides what the topology can do; the binding — which actual mind fills it — is made at muster, because a class has to outlive the minds of the day. - **Settings are changed.** How many minds and at what capacity; the turn budget; how wide a department fans out; the timeouts; how strict a proof threshold is; which station does the judging, provided it is one that can judge independently. Change any of those and it is the same class with a new version id. - **Guarantees are kept or given up.** A survey guarantees an independent check: its report is judged by someone who did not write it. A tender guarantees that every device is measured before it joins the fleet. A mission that wants the writer to judge their own work is not a survey with a shorter chain — it gives up the thing the survey was for, so it is a different class under a different name, and it carries the fact that independent proof was dropped. Only one of the two goes wrong quietly. Change a setting too low and the work slows, which somebody notices. Delete the judge and nothing fails: the report still gets written, the proof still gets signed, and the guarantee the class existed for is gone. The next crew inherits a topology that looks tried and was never tested. So: use the class if it fits; change the settings if that is all the difference is; fork if you would have to give up a guarantee, and record which one. Fork as well if you cannot tell which case you are in, because that usually means the guarantee was never written down — a defect in the class, and worth fixing before the next crew inherits it. Two signals follow. Changing the same setting the same way three missions running means the class was set wrong, not that three crews were inventive: fold the change in and re-promote. And a changed topology keeps its own version id, since cohorts compare only within a class — runs that are half original and half adjusted can support a claim about neither. **A fork in practice: recon.** Recon looks like a survey — go and look, write down what you found — and it is a separate class, because what it produces is a corpus rather than a claim. A survey's report says *this machine has 32 GB*, and somebody asked whether it does; a transcript asserts nothing, it simply is. That moves the guarantee: a survey guarantees its claims are faithful to the evidence and judged by someone who did not write them, while recon guarantees every artifact is traceable to a capture event and unmodified since. The choice between them is the question you are holding. If somebody has asked it and needs an answer, that is a survey: it spends turns and produces a claim. If nobody knows what to ask yet — an incident has just happened, a machine is about to be wiped, an audit is coming — that is recon: it spends disk and produces evidence, and it is the only one of the two that flies with no mind at all. The parts move with the guarantee. There is no scribe, because nothing is being synthesized; there is a **custodian**, which stores, hashes, and indexes, and writes each hash into the ship's log. And the check is deterministic rather than cognitive — recompute the hashes, compare the index against the corpus, confirm every item points at a capture the log already has. Recon can run with no mind in the loop — the capture plan is fixed in the sortie spec before the ship leaves — which is the clearest sign it is not a survey with the writing taken out. The work it maps to is capture-before-you-touch: event logs, process state, config dumps, a packet capture, a snapshot taken so a later audit has a baseline, an archive policy demands and nobody has read yet. What those share is that the artifact answers a question nobody has asked yet. A survey spends minds on synthesis; recon spends disk and keeps the minds out of it, which makes it the cheapest class a fleet can fly and the one most likely to be skipped until it is needed. **Reusing a station.** A station definition — role, sensors, effectors, mind requirement, standing orders — is reusable on the same terms as a ship, and more cheaply, because a part owes less than a whole. `survey:probe` on the next Windows machine is the same station pointed at a different target, and a census is that idea applied N times. Two things differ, and both are hazards. Reuse inherits **capability**, not just a name. A station that writes files will still write files wherever it is mustered, so a familiar role dropped into a new design can break a guarantee without anyone touching the guarantee: a topology that swore one writer quietly has two. Before a library station is mustered, its effectors are checked against what the design says may touch that resource — what can this station touch, against what did the design assume only one thing touches. That is a cheap check and it is the one that stops reuse from being a way to lose guarantees while feeling prudent. The other is that reusing parts does not validate the whole. A ship is a validated whole; a station is a validated part. A ship assembled from familiar stations has proven nothing *together*, so its proof obligations are re-derived rather than inherited. That is the whole difference between "we have used all of these before" and "these have worked together before," and only the second one is a reason to trust the result. Station definitions are promoted on the same terms as standing orders: one earns its place in the fleet's definition library with a source, the missions that used it, and what it proved. A role that exists because somebody copied it out of last month's ship is a habit, not a definition. **Reusing a department.** A department is a fragment of an order of battle: a set of stations, a delivery policy, and a commander. It is reusable as a fragment, and it inherits both hazards one level up — it arrives with its stations' capabilities, so a reused department brings its file-writers with it, and it validates the grouping rather than the ship it is dropped into. Its own guarantee is narrower than a class's and easier to state: messages addressed to the department reach exactly its stations, by a policy written at design time and shown on the bridge. Change the membership or the policy and it is the same department with a new version id. Let the policy be decided at runtime and it is not a department at all but an invisible hierarchy, which is the one thing the design refuses outright. A grouping that has now worked on three ships is a pattern worth naming in the library, on the same terms as a station or a class. **Composition recurs; the unit changes.** The same question — part, group, whole — arrives at every level, and the ladder does not stop at the top: equipment inside a station, stations inside a department, departments inside a ship, ships inside a task force, task forces inside a fleet, fleets inside a grand fleet, and upward as far as anyone needs to climb. What never happens is one unit inside another of the same kind: no department holds departments, no task force holds task forces. Each level groups the level below and never itself, so when a group of groups is wanted the answer is the next kind of unit up — a ship above departments, a task force above ships — because that is where a second layer of grouping gets its own command ship, log, watch bill, and standing orders. The address grammar follows the same slope. It names the task force and the ship — one segment each — and above a ship it stops adding segments, because the way to address a task force or a fleet is to address its command ship. Recursion is real here, but it climbs rather than loops, which is what keeps an address readable at a glance. **Climb only when it pays.** Every level costs another command ship and another hop on every escalation, so a level is added when fan-out has outgrown one commander's attention — not because the diagram looks unbalanced. A fleet of three ships in three task forces is three commanders and three logs to answer a question one captain could have. **And come back down when it stops paying.** When the work shrinks there are three honest routes. The ships can be reassigned to the level above and the intermediate formation mothballed or decommissioned once it is empty; the whole formation can be mothballed intact and reactivated when the work returns; or the whole formation can be decommissioned at once, ships and all, when the work is not coming back. Nothing about the ships changes on the first two routes, because a ship's own address is its ship, department, and station segments — the formation prefix is a route another formation uses to reach it, not part of the ship. So the first two are a registry update and a line in the log rather than a migration of work, the third is ordinary decommissioning done many times over, and the human at the top simply holds a smaller scope. **Ship or working party.** The **ship test** is the first question of every force design, asked before a single station is drawn: does this work get a ship of its own, or a working party on an existing one? A ship is not a reward for size, and a small task is not automatically a party. Three tests, and any one of them earns the ship: - **Memory.** Will the work produce standing orders, procedures, or proofs that need a durable home? A survey writes conventions for the vault that outlive the sortie; a tender writes down how to set up each kind of device. - **Queue.** Is it a standing function with recurring demand, its own backlog, and its own metrics? An errand is a party. A function is a class. - **Boundary.** Does it reach anything privileged — a key, a password, a write to somewhere it matters — that should not happen on the command ship? A ship is a separate instance, and giving it its own node costs little in Erlang, so the blast radius can be one ship's rather than the command ship's. That is the test that justifies the spend; the node is a deployment choice, not part of what makes a ship a ship. A task with none of the three is a working party: mustered for its sortie, retired when it closes, its rough log folded into the parent's. A task with any of them gets a ship, because the ship is where the memory, the queue, and the boundary can live. **Ship class or task force.** When the same job repeats across many machines and repositories — five to survey, a dozen to check — the answer is not a bigger ship. It is one ship per instance plus a command ship to collate, because then every instance keeps its own evidence, its own independent judge, and its own proof, and a ship that fails costs one row instead of the census. A census, concretely: a task force named **Full Accounting** — N survey ships each running an ordinary survey of one machine, and a command ship carrying the collation station. The collator holds the expected set from the order of battle beside the reported set as it arrives, so completeness is a set difference and a missing row is recorded as missing — still running, failed, and never assigned are three different facts and all three are visible. The collated document cites each ship's proof by reference rather than inlining it, so each machine still has exactly one source of truth. The test is breadth. If the instances differ only in what they are pointed at, the force is wide, not tall: a task force of small ships beats one ship with many stations, and the commodore absorbs the ordinary failures of the many without troubling the fleet. ## Bootstrap: the minimum viable fleet The smallest fleet is a flagship and nothing else. It has no production stations and no mission of its own; it exists to muster the first ship. ```mermaid flowchart TB Fleet["Fleet — Admiral (human principal)"] TF["Task Force — Commodore (one ship)"] Flag["Ship Assembly Required — Flagship"] FlagDept["Department flag"] Comm["Station commodore — Commodore, command mind"] Bosun["Station bosun — station lifecycle"] QM["Station quartermaster — mind lifecycle"] Fleet --> TF TF --> Flag Flag --> FlagDept FlagDept --> Comm FlagDept --> Bosun FlagDept --> QM ``` The Admiral is a principal: a fleet commission and a console, no station. The Commodore is a station on the flag deck, because mustering is an action and a principal has no effectors. The Commodore also holds the flagship's Captain commission; the two scopes are distinct, but at bootstrap they share a station. It is also the fleet's executive, the Captain of the Fleet, for exactly as long as it is the only task force commander. When the fleet grows, all three offices separate: flag deck executive, task force command, and the flagship's own chair. The bosun and quartermaster are uncommissioned support stations. The task force is a scope rather than a ship, and at bootstrap it holds one ship. That is not ceremony: a commodore is the lowest commission that may muster a ship, so a task-force scope has to exist before the fleet can build a second ship. The flag log is that task force's record — one ship's worth of history to start with, and the same log once the task force is a real formation. **Minimum viable mind allocation.** The floor depends on what the first ship has to do. A working party needs one model mind with capacity two and one host: one turn for the Commodore, one for the working party. A `starter` needs capacity three, or two model minds — `command` and `work` — with the work mind at capacity two, so the Commodore, the station making the change, and the station judging it can each hold a turn. The recommended floor is two model minds, which keeps the Commodore out of the ship's queue. Those figures count model minds, and a human in a post is that post's mind already — so the rare person at the Commodore's station takes one model off the floor rather than adding one. **Naming.** The bootstrap command is `lowpassage flagship init`; it records the flagship name, the initial crew names, the mind bindings, and the budget. It asks for the flagship's name and the initial crew's names. The flagship name becomes the address prefix (`assembly-required:flag:commodore`); a later ship gets a prefix of its own, so `survey:probe` on one ship and `survey:probe` on another are different addresses. The two kinds of name do different jobs: a class is named for what it does and every ship of that kind shares it — `survey`, `tender`, `picket` — while a ship's name belongs to one instance, so `survey` is the kind of ship and `known-quantity` is the ship. The crew name is the occupant's name and may change when the occupant is replaced. The role and address stay stable; the name is for humans, the log, and the standing orders. Task forces are named on the same principle — after what they are for rather than after who leads them. A census task force, a nightly watch, the group assembled to move a service: the name should survive a change of commodore, because the commodore will change and the task will not. A task force named after its commander is a task force that has to be renamed at the worst possible moment. **Renaming is a command act.** Whoever holds the commission over a scope may rename what sits inside it — a ship, a task force, a station's label, a department's label, a crew name. The rename is an event rather than an edit: the old name stays in the log, everything that referred to it is updated in the same breath, and past entries keep the old name so a reader can follow one occupant across the change. A rename touches labels and never addresses. A ship's name is a label; its ID is an address prefix, and changing that is a migration with new addresses and a registry entry, not a change of name. A crew name is a label too — what the fleet calls its occupant rather than who they are — which is why the role and the address stay put while the name moves. Beyond that, the only thing out of reach is what sits outside your commission. In practice this is a convenience for people, and a model mind will rarely bother — names exist so that logs and standing orders can be read, and the log does not care what a ship is called. Three layers sit on one post, and only the first of them routes. The **ID** is the address segment — `helm:helmsman`, honestly chosen, typed by hand, never decorative. The **label** is what a person reads on the bridge and in the log — *the Big Wheel* — set by whoever holds the commission over it, for usefulness or for memory, and replaced when it stops earning its place. The **crew name** belongs to the occupant — *Hikaru Sulu* — and changes when the occupant does, or when command has a better one. Nothing requires the label and the ID to resemble each other, and it is a mistake to make the address carry the joke. **The first ship follows the task.** Classes are discovered, not selected. A new kind of problem is expected to produce a new class, and the named ones are starting points rather than a taxonomy to squeeze the work into — designing around a class that nearly fits is worse than designing without one. Two come with the fleet and are on the shelf from the first day: `starter` for a bounded change, `workshop` for ongoing repository work. Everything else is discovered, and a new kind of problem is expected to add to the library rather than be squeezed into it. A specialist job may need no ship at all, only a working party. The Commodore looks for a class that fits before designing anything, and designs from the work only when none does. **Growth.** The fleet starts small and builds out as the work reveals what it needs: more ships, more departments, more stations, more minds. It can shrink back to the flagship when the campaign ends. **Mothballing.** A ship that is not needed now but will be needed again goes **into reserve** rather than out of service. It stops running — no processes, no bound minds, no node — and keeps its name, its addresses, its topology, and its standing orders. Its log simply has a gap in it, and its order of battle is written to its record so that reactivation is a muster rather than a redesign. **When is too long.** The observable half of that question is exact: the watch bill knows whether any job is in flight, the standing watch knows whether any lease is still renewing, and the log knows when the last one closed. A ship with no jobs and no standing watches is idle, and that is a fact rather than an opinion. The threshold is not. How long a ship may sit idle before it goes into reserve depends on what bringing it back costs in turns and waiting, on how scarce the node it occupies is, and on whether the work is coming back — which is the one thing nobody can see. So it is a setting the commission that owns the ship chooses and reviews rather than computes, and it should sit comfortably above the cost of reactivation: a ship that is reactivated as often as it is mothballed spends its life mustering. No number is given here, because the right one changes with the fleet's circumstances. A ship with a queue behind it should never go into reserve; one between campaigns should. The signal that a threshold is wrong is in the fleet's own behaviour: if several ships are reactivated and mothballed repeatedly, the number is too low, and the analyst is the station that proposes the correction. **Every level can be mothballed.** Reserve and decommissioning both work upward, unchanged. A task force can go into reserve with its ships mothballed beneath it and its order of battle kept; a campaign can be mothballed with its missions stood down and its work tree and intent left on disk. What reserve preserves at each level is the *relationship* — which ships were in which formation, which missions belonged to which campaign — because that is the expensive thing to rebuild and the cheap thing to write down. There is no separate operation for shrinking the ladder. Resources are freed by mothballing, and ships are moved by **reassignment** — a ship leaves one formation and joins another, keeping its own address, log, and standing orders while only its formation prefix changes. A formation reassigned down to nothing is then mothballed or decommissioned like any other empty thing. Two ordinary operations, in either order, and no destructive third one that a commodore might reach for to avoid the paperwork. The preconditions scale without changing. Every job closes, every mind is unbound, every standing watch moves to a station that can perform it — at a task force that means across all its ships and staff, and possibly to a ship outside it, and at a campaign it means before the last mission stands down, because a liveness claim on fleet capacity cannot be mothballed along with the ship that was making it. Three things happen before a ship can go into reserve, and each is a rule rather than a courtesy: - **Every job closes with a reason.** A ship in reserve cannot hold open work, and a job left open on a ship nobody is tending is worse than one that failed. - **Every mind is unbound and its allocation returned.** Capacity held by a ship in reserve is capacity the fleet cannot spend, and the commodore cannot reallocate what a ship is still holding. - **Every standing watch goes to a station that can perform it.** A liveness claim on capacity does not pause because the ship making it did — but a watch is a job on a station, and a station is its equipment, so the watch moves to a station that can actually perform this one rather than to whichever ship happens to stay in service. That may be on another ship, or it may be nowhere: if no such station exists, the claim is retired **out loud** with a reason, because a claim nobody can renew is exactly what this rule exists to prevent. Reactivation restores the topology from the record, musters a crew — the names belong to the occupants and may differ — and resumes the watch bill with the gap in the log accounted for rather than hidden. The ship comes back knowing everything it wrote down and nothing it merely remembered, which is the same bargain a station makes whenever a watch changes hands. **Decommissioning mid-process.** Decommissioning is also the stop of last resort: when a ship is compromised, wedged, or answering wrongly, recall it and then decommission it, and the work ends because the thing doing the work is gone. Every open job is closed with a reason — `canceled` where the decommissioning ends the work, `superseded` where an amendment had already replaced it — and where the ship is in no state to close its own jobs, the level above closes them and records why. A whole task force can be decommissioned the same way, ship by ship, by the commodore who owns it. The log remains either way, and it is the only part that has to. **Decommissioning.** The other end is terminal, and the ship is taken apart into the fleet. Its ship's log is append-only and remains; its rough log is folded into the fleet's; its standing orders are reviewed and promoted to the fleet with provenance; its proofs and metrics are archived. The crew is released, the minds are unbound, and the addresses are freed. The name can be reused or retired. The fleet keeps what the ship learned. ## Metacognition The analyst is a station with read access to metrics and write access to a proposals folder. Its tools are `metrics.query`, `topology.diff`, and `proposal.write`. It does not get `topology.apply`. A proposal is a diff plus a prediction: ``` proposal: split `review` department expected: ceremony_ratio 0.41 → 0.30, wall_ms -15% on class:refactor evidence: 38 runs, 3-week window, 62% of approvals routed via one station risk: one more handoff; needs a second independent judge requires: human approval · expires 2026-12-01 ``` A human or a designated approver station applies it. The next cohort scores the prediction. That last step is the point: the ship learns whether its own reasoning is any good, not just whether the work got done. ## Metrics Every run records enough context that a later comparison is honest: ``` run_id, ts, topology_hash, spec_version, station_id, mind_id, mind_version, task_class, sortie_id, outcome, wall_ms, tokens_in, tokens_cached, tokens_out, usd, human_interventions, ceremony_events, progress_events, proof_items, defects ``` Compare only within a cohort: same task class, same mind version, same topology version, same spec version, same prompt and skill version. If the model and the topology change in the same week, nothing has been learned. Topologies are not run side by side. They accrue across time, so the comparison problem is confounders, not parallelism. A small fixed benchmark suite, re-run after an architecture change, is the only honest way to compare a topology from March with one invented in November. Report confidence intervals. Do not conclude from n=1. ## Failure modes and guards | Failure | Guard | |---|---| | Silent model substitution | Verify the response's `model`; fail closed. | | Duplicate tool calls in one turn | Declared per-turn dedupe or execute-all policy. | | Orphaned work | Handover rule plus watches with epochs. | | Mind viruses | Provenance on every standing order; human rulings outrank station entries. | | Moonbase scope creep | Refocus from the sortie→mission→campaign chain; hard budget. | | Ceremonial stall | Ceremony/progress ratio from the log; alert to a context-aware station. | | Partition split-brain | One owner per watch bill; epochs; visible degradation. | | Certificate expiry | Long-lived certs and a calendar reminder; no hot reload. | | Runaway recursion | Depth and budget caps enforced by the runtime. | | Guessing at intent | Clarification request to the owner of the fact; ambiguity blocks with a target instead of proceeding. | | A downward question read as an order | A clarification carries no work; changing the job is a handover with a target. | | A question nobody answers | A deadline and a fallback on every clarification; the bridge lists open questions with their targets. | | A ship in reserve still holding a standing watch | The watch moves to a station that can perform it before the ship is mothballed, or the claim is retired out loud. A lapsed one fails silently, and nobody is watching the thing that stopped watching. | | Work continuing under a dead directive | A supersession closes the sortie with a reason; work in flight is re-examined, never re-interpreted, and nobody reconciles two intents by guessing. | | Two stations reaching the same resource | Effectors are never shared. One station owns the acting and the rest ask it; overlapping effector lists are a topology error. | | A tool granting reach nobody fitted | Equipment changes go through a commission; reach is read from the effector list, not trusted from the tool's description. | | A dependency moving silently | Declared dependencies catch the ones you can name. The rest arrive as a failure, which stops the tool and keeps the evidence of that run instead of retrying. | | Degrading below the threshold | Each station knows what its output must contain. Under that line it fails rather than reports, and the shortfall is logged as the design's error rather than the reader's puzzle. | ## Milestones | Phase | Scope | Exit criterion | |---|---|---| | M0 | Supervisor, registry, watch bill, router, one stub station | A mission survives killing the station mid-sortie; the job is still owned and the log explains it. | | M1 | Local mind adapter against `127.0.0.1:1235`, probe suite, identity guard | One sortie goes spec → build → proof on a real model. | | M2 | Bootstrap | The Admiral names a flagship, musters it with a command mind and a work mind, and the Commodore musters the first ship that follows the task; decommissioning folds its rough log and standing orders into the fleet. | | M3 | Force design | The Commodore turns a command into an order of battle — context domains, stations, edges, minds, proof obligations — and the bosun musters it; a rejected alternative is recorded. | | M4 | Work tree, proof capture/judgment/readiness, approval freeze | Readiness is derived; no status file is hand-edited. | | M5 | Bridge: one page, declared and observed topology, message-to-any-address | The bridge catches a stalled department before a human does, and an open clarification request names the person who can unblock it. | | M6 | TLS distribution, second node, handoff across nodes | A job moves between two independent nodes with no shared memory or disk; the log shows the handover, the watch transfer, and the proof. | | M7 | Muster and working parties | A Commander musters a temporary station for one sortie; the quartermaster binds a mind; the station is retired and its rough log folded into the parent's; a request with no mind available blocks with a reason rather than failing silently. | | M8 | Mind lifecycle | A quartermaster spins up a model mind on a host; a station is bound to it; the quartermaster drains and retires it without stranding a job; a human mind is added and released with a handoff. | | M9 | Second mind adapter | Swapping minds requires no change to any station. | | M10 | Analyst, cohort metrics, proposal loop | A proposal with a prediction is scored against the next cohort. | | M11 | Node, mind, and consort enrollment | A clean Windows or Linux box joins with one command, receives a certificate, registers, and takes a sortie; a QVAC endpoint on the LAN joins the mind pool without touching the cluster; a NullClaw gateway federates as a consort and takes one delegated sortie. | | M12 | Android mind host (optional) | A foreground-service app serves `/v1` on the LAN, runs untethered for a night, and the pool can route grunt work to it while charging. | Exit criteria state behavior, not hardware. Platform and configuration coverage live in a test matrix; a milestone is satisfied when the invariant holds, on any node. ## Open questions The research queue — each question with its test and what the answer changes — is in [[Low Passage Research#Next research]]. These are the ones that move the design: - **The subscription path.** Bionic's cloud models are not on the local endpoint. Is there a supported external route, or is the subscription only usable through the app? - **Context economics.** What is the largest context a local model can hold at usable speed on this machine, and which stations can live inside it? - **Second local backend.** Does QVAC's OpenAI-compatible server beat LM Studio for grunt stations, and does it run well enough on the Linux/VPS targets — and on the small devices already around the house — to carry a station's mind? - **Streaming and cancellation.** The endpoint's streaming semantics and whether a cancelled turn is actually stopped or merely abandoned. - **Observed-topology metrics.** Which graph measures are worth showing: degree, centrality, fan-in, approval depth, or something else? - **Composite aggregation.** Whether `scatter` should be the default for `call` on composites, or always explicit. - **Platform parity.** Which parts need shims for paths, file locking, signals, and service startup, and how much of the test suite has to run on Linux rather than Windows. - **Node bootstrap.** Which artifact is the smallest thing that works on all three hosts: an escript, a release tarball, or a platform installer? - **Android mind host.** Can a QVAC-embedded Android app be installed over USB, untethered, and serve `/v1` over Wi-Fi reliably enough under Doze and thermal limits to earn a pool slot? - **External harnesses.** Can a NullClaw or PicoClaw gateway federate as a consort over A2A and use the mind pool, or does the ship need its own harness for v0? - **Container isolation.** Does a rootless Podman sandbox for the tool runner hold up on Linux, and does a container-packaged node join over TLS without fighting its cert SAN? - **Mind autoscaling.** What are the load and unload times and memory footprints for QVAC and LM Studio hosts, and can a quartermaster spin up or cull minds on demand without thrashing? - **Muster policy.** What are the right caps for stations per department, delegation depth, and working-party lifetime, and when should a station preempt a lower-priority mind? - **Bootstrap mind floor.** What is the smallest mind allocation that lets a Commodore and one ship operate without collapsing independent review? - **Force design heuristics.** What heuristics choose the smallest station set that still produces independent proof, and when is a working party enough? - **The level shared resources live at.** The mind pool, the definition library and the top-layer standing orders currently sit with the highest rung — a fleet, or a grand fleet above it. Should they be declared at the top of the ladder instead, so that climbing again renames nothing and moves nothing? Costs a level of indirection while the fleet is small; buys an architecture that extends upward without a renaming. - **Tools in the ship's own language.** A tool is equipment, and the ship is Erlang, so a tool could be a small process or escript that shares the runtime instead of a shell command. Does that buy anything a sandboxed process does not — or does it couple a station to the ship in a way the equipment rules exist to prevent? - **How far a no-mind ship can go.** Recon flies without one. What is the largest piece of real work a ship of pure rules can complete — a census, a nightly watch, a rotation of certificates — before a judgment it cannot make forces a mind aboard? The first build task is M0: supervisor, registry, watch bill, router, one stub station, and the kill test. It is cheaper than another round of reading, and it answers whether the substrate holds. ## Worked examples Three missions, each designed from the work rather than from a template. The first is the bootstrap case and has no library to consult; the second earns a ship on all three tests; the third is the only one where a single sentence carries two unknowns. Read them in order — each one uses the machinery the previous one established. ### Known Quantity (survey class) Start with the flagship and nothing else. The Admiral issues one command: > "Do a hardware asset catalog of the system we're on and add it to the Obsidian Heterarchy vault." The task is data gathering and documentation, not a code change, so the first ship is not a `starter`. Nor is there anything else to reuse: the library holds only the two classes the fleet starts with, and neither is this job. What is unusual here is not that the Commodore designs from the work — every mission starts by reading the work, and a mission with no class that fits ends by designing from it — but that the shelf is nearly bare. **The ship test comes first.** Run against the three tests, the work earns a ship on **memory** — a catalog, the evidence behind it, and the judgment on it all need a home that outlives the sortie — and on **boundary**, because writing to the vault is privileged access that need not happen on the same node as the command. The **queue** case is not established: nothing yet says hardware surveys recur, so it is recorded as a prediction rather than given as a reason. So it is a ship, and it is a new kind of one — a `survey` class, **Known Quantity** (`known-quantity`). **The start.** ``` Fleet — Admiral (the owner) └── Task Force — Commodore └── Ship Assembly Required — Flagship └── Department flag ├── Station commodore — Commodore, command mind ├── Station bosun — station lifecycle └── Station quartermaster — mind lifecycle ``` **The decomposition.** One mission, four sorties. Nothing here needs a campaign — the work is one machine, catalogued once — so the mission is the top level and carries both why and what: *the box the fleet runs on is undocumented; produce an accurate catalog, in the vault, linked from `System Network Configuration.md`*. The work itself — what to do, what to capture, what counts as done — is in the four sorties: | Sortie | Station | Output | Handover | |---|---|---|---| | SOR-001 Probe | `survey:probe` | Raw hardware transcript | → `records:scribe` | | SOR-002 Catalog | `records:scribe` | `Hardware Asset Catalog.md` in staging | → `review:check` | | SOR-003 Verify | `review:check` | Proof judgment; corrections | → `command:lead` | | SOR-004 File | `command:lead`; `records:scribe` writes | Note in the vault; link added | done | ```mermaid flowchart TB Probe["SOR-001 Probe — survey:probe"] --> Scribe["SOR-002 Catalog — records:scribe"] Scribe --> Check["SOR-003 Verify — review:check"] Check --> Lead["SOR-004 File — command:lead"] Lead --> Vault["Heterarch vault"] ``` On disk that is `missions/MIS-001/sorties/`. Each sortie is a folder of its own with a `SPEC.md`, a `PROGRESS.md`, a `PROOF.md`, and a `proof/` directory. **How the Commodore designs the ship.** The command decomposes into four context domains and four proof obligations: | Work | Station | Reason to exist | |---|---|---| | Observe the hardware | `survey:probe` | Sensor suite; deterministic, no mind | | Transform evidence into the catalog | `records:scribe` | Vault effector and the conventions | | Judge coverage, validity, privacy | `review:check` | `proof.judge`; independent of the scribe | | Command and release | `command:lead` | Watch bill, handovers, the release | The proof obligations: every hardware class in the transcript is represented; frontmatter and wikilinks are valid; serial numbers and MAC addresses are approved or redacted; the note is placed at the vault root and linked from `System Network Configuration.md`. **Scope, read plainly.** "The system we're on" is the machine running the survey. Anything plugged into it — a drive, a phone, a printer — is an attachment to that system rather than part of it, so there is nothing to ask and nothing to assume: the catalog lists attached devices by model and descriptor, and says nothing about their internals, because their internals were never in scope. Not every terse instruction is an ambiguous one, and a turn spent querying a plain one is a turn not spent working. Four stations is the smallest set that keeps observation, inscription, and judgment in separate contexts. One probe covers all hardware classes; splitting by device would add handoffs without new proof. One judge covers all four obligations. A single working party could do the work, but it would judge its own inscription; the vault write is worth an independent check. Rejected alternatives: a single working party (self-judges; no independent review), one station per hardware class (more handoffs, no new proof), a `starter` or `workshop` (the wrong job — code changes, not a survey). This order of battle is the instance; a class is what an instance leaves behind if the work holds up, and this one is promoted at the end of the example. **The muster.** The Commodore musters **Known Quantity**, a survey ship with four stations, one per context domain: ```mermaid flowchart TB Fleet["Fleet — Admiral (the owner)"] TF["Task Force — Commodore"] Flag["Ship Assembly Required — Flagship"] Survey["Ship Known Quantity — Survey"] Lead["Station command:lead — Captain"] Probe["Station survey:probe — Hardware Probe"] Scribe["Station records:scribe — Catalog Scribe"] Check["Station review:check — Catalog Reviewer, proof.judge"] MindC["Command mind"] MindW["Work mind — capacity 3"] Fleet --> TF TF --> Flag TF --> Survey Survey --> Lead Survey --> Probe Survey --> Scribe Survey --> Check Probe -->|evidence| Scribe Scribe -->|catalog| Check Check -->|proof| Lead TF -.-> MindC Lead -.-> MindW Scribe -.-> MindW Check -.-> MindW ``` | Station | Sensors | Effectors | Mind | |---|---|---|---| | `command:lead` | watch bill, ship's log, station status | assign sorties, message, release | work | | `survey:probe` | WMI/CIM, PowerShell, `systeminfo`, device tree, disks, network | read-only; writes the raw transcript | none | | `records:scribe` | probe transcript, vault structure, templates | file write, wikilink insertion | work | | `review:check` | catalog, transcript, vault | proof judgment, annotations on the proof, block; never the catalog itself | work | Two stations write, and neither writes the other's artifact: the probe owns the transcript, the scribe owns the catalog, the reviewer writes judgments and never the catalog. Three effectors, three artifacts, one pen each — which is the ownership rule doing its work rather than an exception to it. Each is mustered with its equipment already fitted, too: the probe's query set, the scribe's templates, the reviewer's checks. A fitting is a line in the order of battle, not an afternoon of improvisation. **The mind allocation.** Two model minds: the Commodore's command mind, and the survey ship's work mind at capacity three for lead, scribe, and check. The probe is deterministic and needs none. If the work mind is only capacity two, all three still bind and one waits its turn — idle, not blocked — so the chain takes longer rather than stalling. Capacity buys concurrency, not capability. Only a mind absent altogether produces `mind_unavailable`, and even then the probe keeps collecting evidence. **The work.** The probe runs the hardware queries and writes the raw transcript to the sortie's `proof/probe.txt`. The scribe turns it into `Hardware Asset Catalog.md` in a staging path: system, CPU, memory, GPU, storage, network, peripherals, OS, and a provenance line. The reviewer checks that every hardware class in the transcript is represented, that the frontmatter and wikilinks are valid, and that serial numbers or MAC addresses are either approved for inclusion or redacted. That last is the one question nobody below can answer, and the reviewer does not guess at it: it checks its own standing orders, the ship's, and the fleet's, finds nothing about identifiers, and asks its lead. The request belongs to the station that made it: the sortie sits `blocked`, and the request's target is the lead it was sent to. *Redact by default* is named as the fallback if no answer comes — the safe direction, since an omission can be corrected later and a published serial cannot. The lead cannot answer a fleet-policy question either, so it asks the Commodore in turn and says why it could not settle the one it received — the catalog is going into a shared record, and half its contents are identifiers. The rule turns out to live with the Admiral, because a rule that binds every ship's surveys is the fleet's to make, and the Commodore is the one with standing to put the question; so it asks. The answer comes back a hop at a time and lands as a ruling — model and serial in, network address out — and is promoted to the fleet's standing orders, so the next machine's survey inherits it rather than asking again. The lead files the catalog once the answer is in. **The vault.** The target is `Hardware Asset Catalog.md`, a reference note at the root beside `System Network Configuration.md` and `House Network Map.md`. The scribe links it from `System Network Configuration.md`; the note follows the vault's standing orders: frontmatter, wikilinks, single-line paragraphs, no hard wrapping. No further approval is needed for the write itself: the Admiral's command was to put the catalog in the vault, so the permission came with the order, and asking again would put the same question to the same person twice. The scribe performs it, and the lead records it in the ship's log. **The no-mind case.** If the work mind is unavailable, the probe still runs and the evidence is kept. SOR-002 and SOR-003 block with `mind_unavailable`; the Commodore may allocate, provision, or wait. The mission does not fail silently: the vault write waits for the review, and the identifier question waits for the Admiral. **The bridge.** It shows the task force, both ships, the survey ship's four stations, the watch bill, the mind bindings, the identifier question open with the Admiral, and health. The declared topology is the four-station survey ship; the observed topology is the evidence → catalog → proof chain. **The class.** The order of battle worked, so it is promoted: `survey` enters the definition library at version 1 with two lists attached — the settings it allows (mind capacity, turn budget, how many judges, the proof threshold) and what it guarantees (the catalog is judged by someone who did not write it, and every claim in it traces to the transcript). **The end.** The ship itself has a choice of fates. **Known Quantity** can stay in service as a standing survey ship; go into reserve, keeping its name, addresses, topology, and standing orders against the next machine that needs cataloguing; or be decommissioned, which folds its rough log and vault conventions into the fleet and leaves the catalog where it is. Either way the fleet keeps what the ship learned. **What it demonstrates.** Bootstrap from the flagship with nothing on the shelf but the two shipped classes, a first ship that follows the task, a terse instruction read plainly rather than queried, a deterministic sensor station, a human ruling on the one question the order left open, a memory-mind shortfall that queues rather than blocks, a class promoted with both of its lists, and a choice of fates for the ship afterwards. It is the smallest useful mission that is not a code change. ### Bringing the phone into the network The hardware assay is done. The catalog lists an attached **Pixel 10 Pro XL**, with the model and serial (`9F2A7C41E5D80`) read off the USB descriptor, because the phone happened to be plugged into the machine while it was being surveyed. Nothing about the phone's internals is in it: RAM, free storage, the Android version, and the GPU were never the target of that mission, so they were never measured. The Commodore now gets a second command: > "Bring the USB attached cell phone into the network." **First, the library.** `survey` documents a machine and `workshop` changes code; neither enrolls a device, so nothing in the library fits and the design starts from the work. **The ship test.** Any one of the three earns a ship: it will happen again; what it teaches has to be written down somewhere permanent; or it needs access the command ship should not hold. - **Memory.** Yes. The work produces things that have to be kept — how this kind of device is set up, what counts as staying up, which permissions it needs — and those belong in standing orders, not in a rough log that folds into somebody else's. - **Boundary.** Yes. Setting the phone up means USB debugging, installing over the cable, and a token that lets it answer. A ship is its own instance, and giving it its own node costs little, so that access sits outside the flagship's supervision tree and outside its log. - **Queue.** Not the Commodore's to answer. Whether the fleet will acquire more devices is a question about what the fleet intends, and only the Admiral can say. The Commodore could guess, but the guess decides whether the fleet pays for a ship. So it asks: > **Commodore → Admiral** > > Does the fleet intend to bring more devices onto the network after this phone? > > It decides whether this mission gets a ship of its own or a working party on the flagship. > > - **Only this one** — a working party, no ship. The procedure goes into the flagship's rough log. > - **More are coming** — a tender, with standing orders per kind of device, one device at a time until the procedure can be trusted. > - **No answer in two hours** — assume it is the only one, and say so in the log. The bridge shows the question as open with the Admiral named as the one to answer, so nothing sits still without anyone knowing why. The Admiral answers: > **Admiral → Commodore** > > The first of several. Assume one a month, more if I start buying tablets. The answer goes into the log as a human ruling rather than as something the Commodore worked out, because it is what the fleet intends and no amount of reading can establish that. It is worth more than all the rest of the design work: it turns a guess into evidence, and it is why the fleet gets a ship instead of a one-off party. Had the answer been "only this one", the example would end with a working party, a phone, and nothing else — right for the case, and not something the Commodore could have known. With that answer all three tests come out yes, and the work gets a tender rather than a party. Two questions are left, and both are about the phone rather than the ship: can it host a mind at all, and does it stay up once it does. The preflight below settles the first from the spec sheet; the second takes twelve hours of measurement, and either way the answer is a report. **What kind of task this is.** The deliverable is not an artifact. It is a **standing commitment**: a device on the LAN that still answers tomorrow, after Doze, after a thermal throttle, after the router reboots and somebody picks the thing up to read their mail. Three things follow, and each one moves the design somewhere the survey never went. - **It can be refused.** A survey always yields a catalog. Capacity procurement can come back no, and the cheapest moment to hear that is before anything is mustered. - **It cannot close on the day it opens.** Installation is minutes; the evidence that the install was worth anything takes hours. Nothing measurable at the moment of install speaks for the next twelve. - **It decays.** Every other artifact the fleet produces sits still until someone edits it. A mind host is a process on a device that updates itself, sleeps, throttles, and belongs to somebody. Its proof is recurring, not one-shot. **The preflight comes before the ship.** The first act is a turn of the Commodore's own mind while writing the order of battle: force design's budget check, applied to a device instead of a ship. No station is mustered for it and no sortie is opened, because it reads nothing off the device — the catalog handed it a model name and a serial and nothing else, so it reasons from what the vendor publishes for that model, nominal 16 GB of RAM, Tensor G5, arm64, a GPU with Vulkan, against the footprint of the model it intends to run. If it fails, no ship is mustered and the refusal costs one turn, which is the cheapest moment to decide not to do the work at all. **What the preflight is worth.** It is a prediction, not a measurement, and the gap between those two is why a judgment happens later. A used phone has less free memory than its spec sheet claims, and no spec sheet says whether the device throttles when it gets warm. So the preflight decides something narrow: whether this *model* is worth ingesting at all, judged from the spec sheet alone. If the nominal capacity cannot host a mind worth having, no amount of probing will change that, and the cheapest refusal is the one made before muster. Here it passes — and passing settles it, because the tender is mustered to ingest the device and not to deliberate about whether it should. A 3B Q4 at roughly 2.5 GB plus an 8K context clears nominal 16 GB with room to spare, and a 7B clears the arithmetic too — but only if the device really hands half its memory to the model. Seven therefore stays provisional rather than rejected, because the spec sheet cannot settle it and the device can. The numbers that reach the mind pool are the *measured* ones. **The muster.** The preflight passes, so the Commodore musters **Warranty Void** (`warranty-void`), a tender: a ship commissioned for a function rather than a mission, whose business is bringing mind hosts into the fleet and keeping them good. Its stations are permanent and jobs move through them, which is the difference between a tender and a survey. **The approval moves earlier.** In the survey the Admiral's part came at the end and was a ruling rather than a check that could refuse — the catalog's identifiers were a policy question that could be answered once and inherited. Here the risky state begins when the service binds: a device on the LAN, holding a model, answering anyone who presents the token. An approval at the end would decide nothing. So the Admiral approves **exposure**, and it precedes the first bind. The authority is the fleet's rather than a ship's, because a mind host is fleet capacity — any ship's station may bind to it — so it is the Commodore's allocation under the Admiral's rule, not a captain's equipment. **The decomposition.** | Phase | Sortie | Station | Output | |---|---|---|---| | Preflight | — | the Commodore's own turn, during force design | fits, or does not fit | | Install | SOR-001 | `enroll:provision` | Measured specs; app, config, permissions, service starting | | First light | SOR-002 | `enroll:firstlight` | Answers over Wi-Fi with the cable out | | The wait | — | none; the watch bill holds a timer | Uptime, reconnects, thermal reports, latency | | Judge | SOR-003 | `enroll:judge` | Proof over the record; registration | | Standing watch | — | none; `health` and `mind_pool` | Liveness, for as long as it matters | Mission `MIS-002 — Bring the phone into the network` → three sorties on one tender, one job at a time. No campaign sits above it, and the second device the Admiral promised does not earn one: another device is another instance of this same mission, run through the same stations, which is what the tender's queue was bought for. If devices arrive faster than one tender can take them, a second tender joins the task force — breadth, and nothing changes in the work tree. A campaign is what a second *mission* buys: a different piece of work with an intent of its own. **Why these stations.** Installation and judgment must not be the same crew: an installer that declares its own install good has already failed the independence rule. First light and the judgment look alike and are not — one judges **reachability**, the other **endurance**, over a different corpus at a different time. Nothing repeats, so nothing is ceremony. And first light never reaches into the device: when it wants something changed it asks the provisioning station, which owns the `adb` effector — the ownership rule doing its ordinary work, with no coordination needed beyond a message. The three are stations of the tender rather than a party mustered for the mission, and that is what the ship bought: a place for the procedure, a queue to hold the next device, and a boundary around the token. Because only one of them holds a job at a time, the tender needs a single turn of mind capacity rather than three concurrent ones, which is the honest size of the work. The tender is commanded by a model mind rather than a person, since nothing here wants a human's judgment until the exposure approval, which stays with the Admiral. Its stations bind the fleet's work mind rather than the phone's: a mind is not local to a station or a ship, and the tender has no reason to own cognition it can borrow. The phone never becomes a station, because Android is not an Erlang node, and it does not become a consort, because a consort uses a mind rather than serving one. The proof obligations: correct device identity; installed and configured as intended; `/health`, `/v1/models`, and `/v1/chat/completions` answering over Wi-Fi with the cable out; unauthenticated calls rejected; the response's `model` matching the alias; a heartbeat record with no gap past ninety seconds across those twelve hours; recovery from a forced Wi-Fi drop; a model, context, and latency registered honestly; no personal accounts on the device. ```mermaid flowchart TB Cmd["Command: bring the phone in"] --> Ship{"Memory, queue, boundary?"} Ship -->|"queue unknown"| Ask["Ask the Admiral"] Ask -->|"one-off"| Party["Working party"] Ask -->|"first of several"| Preflight{"Model fits?"} Preflight -->|"no"| Refused["No ship — not worth ingesting"] Preflight -->|"yes"| Muster["Tender Warranty Void"] Muster --> Approve["Admiral approves exposure"] Approve --> Prov["provision — SOR-001"] Prov --> Light["firstlight — SOR-002"] Light -->|"no answer"| Returned["Device handed back"] Light -->|"answers"| Timer["SOR-003 pending"] Timer --> Cert["judge — SOR-003"] Cert --> Pool["Pool: ready, unallocated"] Pool --> Watch["Standing watch"] ``` | Station | Sensors | Effectors | Mind | |---|---|---|---| | `enroll:provision` | `adb` device list, `getprop`, `dumpsys meminfo`, `df`, USB state, `logcat` | `adb install`, config push, permission grants, service start | work | | `enroll:firstlight` | `/health`, `/v1/models`, one short completion, an unauthenticated request | request changes; hold the go/no-go | work | | `enroll:judge` | heartbeat history, reconnect events, thermal and latency samples | proof judgment, registration request | work | The stations bind the fleet's work mind. The phone's own mind is the thing being enrolled, not a mind the tender consults. **The mission's terms.** Budget: a fixed number of turns per device, most of them spent on `logcat` when a probe fails. Stop condition: the mind registered and a standing watch open, or the device handed back with a reason. Cap: one device at a time until the procedure is worth trusting, because two half-known procedures racing each other is how a procedure becomes folklore. **Provisioning over USB.** The provisioner measures before it installs, because the survey could not: the model, serial, and ABI from `getprop`, the API level, available RAM from `dumpsys meminfo`, free storage from `df`, and the GPU from the Vulkan report. Here the measurements back the spec where it counts — 16 GB nominal, about 5.9 GB actually free with the system running, 158 GB free, API 37, `arm64-v8a`, Vulkan 1.3.1 — so the tender goes ahead on the 3B and drops the 7B, which is a call the spec sheet could not make. It installs `rig-mind-host.apk`, pushes the config with the ship URL, mind ID, token, model alias, and context size, grants the notification, foreground-service, and battery exemptions, starts the service, and reads `adb logcat -s LowPassageMindHost` until the model is loaded. Had the measurement come back tighter still — a device that could not host a mind at all — that is the report rather than a fault. The sortie closes with a reason, the device is handed back, and the fleet knows for the price of one sortie that this phone is not capacity. A ship can fail and still have answered. **First light.** This phase runs on a station that did not do the install. It curls `http://192.168.4.42:11434/health`, `/v1/models`, and a short `/v1/chat/completions`, checks that an unauthenticated request gets 401, and confirms the response's `model` field is the requested alias. Then the cable is pulled, and the device has to answer anyway — on Wi-Fi, screen off, no USB. That is the whole point of the phase: it costs one turn to learn that a phone will not serve while untethered, and nothing downstream is worth spending until it will. **The wait holds no watch.** The judgment is scheduled twelve hours out and sits `pending` in the watch bill with no station bound and no mind held. A station whose only job is to wait is a passenger, and a job whose content is waiting is not a job. While the timer runs, `mind_pool`'s heartbeat and `health` accumulate what the judgment will need: uptime, gaps, reconnects after a forced Wi-Fi drop, thermal reports, latency samples. All of it lands in the tender's ship's log, which is where the judging station will read it. **The judgment.** Twelve hours later the watch bill wakes and hands the job to a station that touched neither the install nor first light. It judges the record rather than measuring anything: heartbeats every thirty seconds with no gap past ninety; a Wi-Fi drop that recovered without help; a thermal report honest about throttling; p50 and p95 latency; the token still enforced; the `model` field still the alias. This is judgment on evidence, which is the only kind the fleet accepts, and it is why the judging station did not need to be present when the evidence was made. Where the record is thin it asks the provisioning station rather than inferring a cause, and the answer is logged beside the judgment. The quartermaster then registers the mind: ``` id: android-pixel-10 kind: model model: qwen3-3b-q4 context_window: 8192 capacity: 1 latency: p50 ~12s for 100 tokens availability: always while charging footprint: ~2.5 GB pricing: 0 ``` Capacity is **one**: a phone serves one turn at a time, because the model is resident in one process and the thermal budget is the real limit. A second caller waits for admission rather than queueing inside the device. That is the point of the pool — the chunky resource is the one that carries the limit. The mind is **ready and unallocated**. No station is bound to it yet; that is a later captain's or commodore's decision. The bridge shows the mind, its endpoint, its health, and the empty binding. **The close is a watch, not a closed sortie.** The mission cannot end with a finished artifact, because the artifact decays. It ends with the mind registered and a **standing watch** opened on its liveness, carrying a lease that renews for as long as the fleet means to rely on the phone. If the watch lapses, the pool marks the mind `offline` and the bridge shows it, which is what makes "we have a phone mind" a claim with a heartbeat behind it rather than a memory of an afternoon. **The class.** `tender` is promoted on the same terms as the survey, with its own two lists: the settings — how long the wait lasts, how big a heartbeat gap is tolerated, how many devices at once — and the guarantee, that every device is measured before it joins the fleet and judged on evidence it produced while nobody was watching it. **The records.** The tender's ship's log holds the mission, the exposure approval, each handover, the evidence as it arrived, the judgment, and the registration. Its rough log holds the device properties, the install log, the curl output, the token test, and the judge's doubts. What generalizes gets promoted: the per-class procedure and what counts as a pass into the tender's standing orders, and token hygiene and the LAN-only rule into the fleet's, because those bind every ship. That is the memory the ship was earned for. **The release.** The phone is **released** when the fleet stops relying on it, and the standing watch closes with a reason. The tender does not decommission with it; it stands waiting for the next device, with a procedure slightly better than the one it started with. A mind host goes back to being a phone, holding no memory of the fleet that borrowed it and leaving the fleet holding only what it wrote down. **What it demonstrates.** A library checked before designing and a class promoted after; a ship earned by memory, queue, and trust boundary rather than by size; a prediction made cheaply and then checked before it was believed; an approval that gates exposure rather than a finished artifact; work that cannot be judged on the day it is done; waiting carried by the watch bill instead of a held watch; a judgment made by a station that never touched the device; and a close that leaves a standing watch and a better procedure behind. ### Nothing To Report (picket class) The fleet has a NAS, and every night a job copies the vault onto it. Nobody watches the job. The Admiral issues the third command: > "Keep an eye on the nightly backup and tell me if it fails." **First, the library.** `survey` documents a machine, `tender` enrolls a device, `workshop` changes code, and `starter` does a bounded piece of the same. None of them watches a recurring job, so nothing fits and this is a new class. **A ship, all three.** **Memory**: the check rules, the thresholds, and the escalation path all have to be written down, and the next thing that gets watched would start from them. **Queue**: it is nightly, which is the plainest queue case in the fleet. **Boundary**: the ship reads backup logs and can page a human, and a watch on a machine that sleeps is not a watch — so it lives where it will stay awake, not on the desktop. **What kind of task this is.** The deliverable is neither an artifact nor more capacity. It is an **alarm that stays armed**, and three things follow from that. - **Mostly it has nothing to do.** Work arrives in bursts, and between them the whole job is to notice that nothing has happened. - **Its failure mode is silence.** A watch that has died looks exactly like a quiet night, so an absent heartbeat has to be the alarm, and the watcher has to be watched. - **It cannot be proved by a quiet run.** A watch proves itself by surviving the thing it exists to catch, so the proof obligation is a deliberate failure. **Two unknowns in one sentence.** "Tell me if it fails" leaves open how often to look and what time of night a person may be woken. Those land on opposite sides of the line. > **Commodore → Admiral** > > Does an alert at 03:00 page you, or wait for morning? > > Blocks: whether the ship carries a pager effector and an escalation path at all. > > - **Page** — an effector with reach into the night, and an escalation to a second human when the first does not answer. > - **Hold until 07:00** — alerts queue on the bridge, and a failed backup is found eight hours late. > - **No answer in six hours** — hold, and record the hold as a decision rather than a default. The Admiral rules: hold until morning, and page only if a backup fails twice running. That ruling adds a conditional escalation edge, which is precisely why it was asked — it changes the topology, not a number. **One assumption, flagged.** How often the check runs: every fifteen minutes rather than hourly. It changes probe load and detection latency and nothing else, and being wrong costs a reconfigure in either direction. So it is assumed, written into the flag log with its reopening condition — *if the backup starts taking longer than thirty minutes, or a failure turns up already an hour old, revisit* — and shown on the bridge as an open assumption until it is confirmed. Confirmation turns it into a setting with a source. Correction costs one setting. **The decomposition.** | Phase | Sortie | Station | Output | |---|---|---|---| | Arm | SOR-001 | `watch:arm` | Check installed, schedule written, thresholds set, alert rules and quiet hours declared | | Prove | SOR-002 | `watch:prove` | A deliberate failure caught, alerted, and recorded | | Stand | SOR-003 | `picket:watch` | The watch itself, running unbound | | Relay | SOR-004 | `picket:relay` | The alert, on whichever channel the ruling chose | **The muster.** The Commodore musters **Nothing To Report**, a picket: four stations, one job in flight at a time, and no mind held between events. The ship is named for the answer a quiet night gives: nothing to report. **Why these stations.** Arming is an act, and proving is a judgment on what was armed, so it sits in a station of its own and reports to the lead rather than to whoever armed the watch. Proving comes before standing for a second reason: the check is **equipment**, and equipment is a candidate until it has run against the thing it exists to catch — the mind that armed it may do that running, because a tool proves itself by working. What `watch:prove` supplies is the deliberate failure: the fake run, the confirmed delivery, and the go/no-go, which is the one test a quiet night cannot give. That is why SOR-002 sits between arming and standing rather than after both. Standing is a rule. Relaying is a channel, and it is separate from the watcher because noticing and deciding who to wake have different blast radii: one reads a log, the other reaches into somebody's night. ```mermaid flowchart TB Cmd["Command: watch the nightly backup"] --> Ask["Ask: does an alert at 03:00 page you?"] Ask -->|"page"| Page["Pager and escalation"] Ask -->|"hold"| Digest["Held until 07:00"] Page --> Muster["Muster picket Nothing To Report"] Digest --> Muster Muster --> Arm["watch:arm — install the check"] Arm --> Prove["watch:prove — fire it deliberately"] Prove --> Stand["picket:watch — stand by, unbound"] Stand -->|"rule fires"| Mind["Acquire a mind, draft, release"] Mind --> Relay["picket:relay — send"] Stand -.->|"lapse"| Watch["Standing watch on the watcher"] ``` | Station | Sensors | Effectors | Mind | |---|---|---|---| | `watch:arm` | backup job definition, schedule, destination | write the check, schedule it, set thresholds | work, while arming | | `watch:prove` | synthetic failure, `picket:relay`'s delivery record, the watcher's log | trigger a fake run, confirm the alert arrived, block | work | | `picket:watch` | exit code, destination log mtime, size against tolerance, the schedule | raise an event; acquire a mind when one fires | none by default | | `picket:relay` | the alert itself, delivery receipts | message, page, queue for morning | none | **The mind is not resident.** This is the most useful thing about a picket. The rule is deterministic — did the job exit zero, is the destination log newer than the last scheduled run, is the size within tolerance — so `picket:watch` runs **unbound**. When a rule fires it acquires a mind from the pool, asks for a two-line diagnosis and an alert draft, and releases it. Between events the fleet holds no capacity here at all, and the quartermaster may cull the mind entirely. Swapping the mind loses nothing, for the same reason the station is cheap: the facts live in the station and in the log, not in a model's context. A picket whose mind is culled at midnight and replaced by a different one at dawn has lost the recollection of a quiet night, and nothing else. **And the alarm fires without it.** If a rule fires while the pool has no capacity, the relay still sends — raw, without the diagnosis. Cognition makes an alert better; it must never make it possible. **Who watches the watcher.** The picket's own heartbeat is a **standing watch**: a lease renewed on every check, where a lapsed renewal *is* the failure. This is the mechanism the tender used for a phone's liveness, doing the job it was built for. Without it the ship's silence is ambiguous — quiet night, or dead process — and the second is the one that matters. **The records.** Checks do not each go into the ship's log: ninety-six entries a night would turn the log into a metronome and bury the things worth reading. The check history lives in a rotating record, and the log takes only transitions — armed, fired, alerted, held, answered — plus the assumption and the ruling that resolved the question. **The class.** `picket` enters the definition library at version 1 with its settings — cadence, thresholds, retention, quiet hours — and two guarantees: **the alarm fires with or without a mind**, and **the watch's own lapse is itself an alarm**. **What it demonstrates.** One sentence containing two unknowns, one asked and one assumed, and the line between them drawn by what a wrong guess costs; a ruling that changed the topology and an assumption that changed a number; a mind bound only when there is something to think about; an alarm that degrades to a raw page rather than to silence; a watch watching itself; a piece of equipment proved by a deliberate failure rather than by a quiet run; and a proof obligation satisfied by making the thing fail on purpose. ## Decisions - **2026-11-07** — Erlang/OTP 28, cross-platform code. Windows is the development host; Linux and VPS nodes are expected targets; no WSL. - **2026-11-08** — The development host in fact runs OTP 29; the 2026-11-07 entries were written against 28. The code targets whichever major is installed, and every node is pinned to the same major before distribution is trusted. - **2026-11-07** — Colons for internal addresses; slashes in HTTP routes; `@` reserved for node names. - **2026-11-07** — Content in Markdown files; coordination in the log; mailboxes are doorbells only. - **2026-11-07** — The bridge is a separate application, not part of Bionic. - **2026-11-07** — Local models only for v0; the subscription path stays open through the mind behaviour. - **2026-11-07** — Stateless minds preferred, so migration ships a message list rather than a vendor thread. - **2026-11-07** — Enrollment splits three ways: nodes join the Erlang cluster, minds join the mind pool, consorts federate over A2A/HTTP. Android is a mind host or a consort, not an Erlang node. - **2026-11-08** — The unit is a **station**. OpenRig's "seat" is retired from our vocabulary; "effector" is the action half of a station. - **2026-11-08** — The metaphor is naval: fleet, task force, ship, department, station. The project remains **Rig**; a running instance is a ship. - **2026-11-08** — Rank is scope, not identity. Commissions are Admiral, Commodore, Captain, Commander, Lieutenant; most stations hold none, and a human may hold any of them. - **2026-11-08** — Model minds are provisioned and retired by a quartermaster within fleet policy. Human minds are enrolled and released. Culling drains before unload, and a bound station must have a fallback. - **2026-11-08** — Stations may request working parties; authority cannot exceed the granter's commission. A binding is a lease: if no mind is available, the station is ready-unbound and the job blocks with a reason. - **2026-11-08** — Human minds are enrolled and released, not provisioned. A future *summons* flow may request attention explicitly; it is deferred. - **2026-11-08** — The minimum viable fleet is a flagship: Commodore, bosun, quartermaster, flag log, one command mind, one work mind, one host. The first ship follows the task; `starter` is a default, not a requirement. - **2026-11-08** — Setup names the flagship and the initial crew. The role and address are stable; the crew name belongs to the occupant. - **2026-11-08** — Decommissioning retains the ship's log, rough log, standing orders, and proofs; the crew is released, and the name may be reused. - **2026-11-08** — Department IDs are local and authored. OpenRig's pod names (`dev`, `orch`) are examples, not requirements; the ID is an address segment, the label is free-form. - **2026-11-08** — Stations follow work, not the org chart. Every station must justify itself with a sensor, effector, judgment, or command role; the design is recorded as an order of battle before muster. - **2026-11-08** — Ships get functional, Culture-inspired names; classes stay generic (`starter`, `workshop`). The ship ID is the address-safe slug; the name is the label. - **2026-11-08** — Task forces are named for their purpose on the same principle, and the name outlives its commodore. Staff work is a post and not a rank: a chief of staff or a flag captain holds whatever commission the work needs, so the ladder never grows a rung for staff. - **2026-11-08** — Station IDs are roles; labels are for humans and may be functional or merely memorable; crew names belong to the occupant. The function lives in the ID because the ID is what routes, and putting the joke in the address is a mistake. - **2026-11-08** — Station roles are authored at muster, not selected from a registry. The named roles are recurring examples; what the system enforces is address uniqueness, not a vocabulary of permitted roles. - **2026-11-08** — Reusable definitions accumulate in a fleet library at every level — station roles, department patterns, ship classes — and are promoted like standing orders. Reuse inherits capability and not merely a name, so a library station's effectors are checked against what the design says may touch that resource, and a topology assembled from familiar parts re-derives its proof obligations rather than inheriting them. - **2026-11-08** — Composition **inside a ship** has three levels and does not nest: equipment inside a station, stations inside a department, departments inside a ship. A group of groups is a ship, not a department, which is also what the address grammar enforces. Formations above a ship group upward instead, per the later entry on climbing. - **2026-11-08** — Android provisioning uses USB/ADB; runtime uses Wi-Fi. USB is not the production transport. - **2026-11-08** — **Ship is the only word for the instance**; "hull" is retired. The distinction it carried — an instance rather than a working party — lives in the definition of *ship*, so the ship test reads "ship or working party" and nothing has to be said twice. - **2026-11-08** — A ship is earned by memory, queue, or trust boundary, not by task size. Mind-host enrollment hits all three, so it gets a tender (`warranty-void`); a task with none of the three is a working party. - **2026-11-08** — A crew asks for what it does not have, in any direction, rather than inferring intent. Ambiguity blocks with reason `awaiting_clarification`, a target, and a deadline; a decision that is cheap to reverse may proceed on a recorded assumption. - **2026-11-08** — A ship has two ends: it goes into reserve, or it is decommissioned. Reserve keeps the name, addresses, topology, and standing orders and is reversible; it requires jobs closed, minds unbound, and standing watches transferred first. Decommissioning is terminal and takes the ship apart into the fleet. - **2026-11-08** — Ship classes are discovered, not selected. Named classes are starting points; a new kind of problem is expected to produce a new class rather than be forced into an old one. - **2026-11-08** — A task force is commanded from a ship inside it, not from a separate node of its own. The command ship carries the commodore, the flag log, and the task force's staff stations; the commodore resolves what is local to the task force, and only capacity, policy, and irreversible fleet actions go up. - **2026-11-08** — Capacity buys concurrency, not capability. One mind may serve many stations in turn, so a wide force can run on a narrow pool at the cost of time rather than at the cost of the work. - **2026-11-08** — A binding may be episodic: a station can run unbound and acquire a mind only when it has something to think about. An alarm must not depend on cognition being available — a rule that fires sends raw when no mind can be had — because cognition makes an alert better and must never make it possible. - **2026-11-08** — Orders change mid-mission. Only the issuing commission or one above it may amend or recall, while a stand-down belongs to the commission that owns the scope it names; work in flight is re-examined rather than re-interpreted; a sortie the amendment invalidates closes with reason `superseded`; proofs keep their truth and lose their relevance; intent is versioned and cohorts do not mix across versions. - **2026-11-08** — Composition climbs without limit: fleets group task forces, a grand fleet groups fleets, and each level is a new kind of unit with its own command ship and log rather than the same unit nested. A level is added when fan-out outgrows one commander's attention, because each rung costs escalation latency, and the ladder comes down the same way: by reassigning ships upward or mothballing a formation intact — a formation prefix is a route rather than part of a ship's address, so either route changes nothing about the ships. Only the top seat is fixed to a human; the admiral ranks below it may be held by either. - **2026-11-08** — A ship idle past a policy threshold goes into reserve rather than being decommissioned. The threshold is a setting owned by the ship's commission, measured from the watch bill and the log and set above the cost of reactivation; repeated reactivation and mothballing is the signal it is too low. Reserve applies at every level: a formation is mothballed with its ships beneath it and keeps its order of battle, and a campaign is mothballed with its work tree and intent intact. There is no separate compression step: resources are freed by mothballing, and ships are moved by reassignment. - **2026-11-08** — A station's questions are bounded by its orders. A fact outside the mission's scope is refused with a reason and recorded, and a genuine need for it is a request to amend the orders from the commission that issued them — not a wider question asked of the owner. - **2026-11-08** — A clarification whose answer does not yet exist is answered by work: the request climbs as a question and comes back as a mission's result, served by as many ships as the work needs. Asking for a fact and asking for capacity are the same request until somebody establishes that the fact is already known. - **2026-11-08** — The work tree contracts. A task that is one mission's worth of work is a **mission with sorties**, and it earns a campaign only when a second mission arrives to sit beside the first. Three levels are a default, not a requirement. - **2026-11-08** — Repetition is not a new level, which sharpens the entry above: a second device, machine or repository of the same kind is another **instance** of one mission, not a second mission, and a campaign is earned by a different piece of intent. When the repetitions outgrow one ship, they add ships of the same class to the task force and the work tree stays as it was. - **2026-11-08** — Campaigns are concurrent contexts rather than phases: several may be open at once, each with its own task force and its own intent. A ship belongs to one task force at a time, and the address grammar enforces it with a single formation segment. - **2026-11-08** — **XO means the executive officer**, a post at any level rather than a commission, and the fleet's instance of it is the Captain of the Fleet. The metric-reading, proposal-writing station is the **analyst**. The Commander commission is department scope alone and carries no XO. - **2026-11-08** — The admiral's executive is a **post** — the Captain of the Fleet — and is not the same office as commanding a task force. Each task force gets its own commodore, local to it; at bootstrap one station wears both hats only because there is one task force. - **2026-11-08** — A standing watch moves to a **station that can perform it**, not merely to a ship still in service: a watch is a job on a station, and a station is its equipment, so a ship with no equivalent station cannot inherit the claim. This refines the earlier entry today, which said watches were "transferred" without saying to what. - **2026-11-08** — Renaming is a command act within a scope, recorded as an event that keeps the old name. Labels are renameable; addresses are not, because changing an address is a migration rather than a change of name. - **2026-11-08** — A human is added as advice, never swapped into command: a human mind with a console, bound like any other mind at capacity one. When the advice is needed across ships, the console gets its own ship, and the smallest ship in the fleet is one station with one person aboard. - **2026-11-08** — A tool is equipment. A mind may author one, and what it produces is a candidate proven by an independent station; fitting it is a topology change checked against what the design says may touch that resource; and it runs with its station's authority and never more. - **2026-11-08** — Effectors are never shared. A resource that several stations must act on gets one owning station and the others ask it; sensors multiply freely. Two stations declaring the same effector is a topology error rather than a race to be managed. - **2026-11-08** — Work inside a ship runs in parallel by default; nothing schedules a ship's turn. Parallelism is bounded by mind capacity, by effector ownership — which turns contention into a queue in one station's inbox — and by ordering that must be an edge rather than an expectation. A stop is therefore scoped to an address rather than to the whole ship. - **2026-11-08** — The ship's log records transitions, not ticks. High-frequency samples live in a rotating record, which is a standard tool for any station that samples often rather than a one-off decision. - **2026-11-08** — Android's JDK 17 is pinned per project in `gradle.properties`, not in `JAVA_HOME` or the global Gradle properties; other builds keep the modern JDK. - **2026-11-09** — **Every ship is in a task force**, the flagship included, because a commodore is the lowest commission that may muster one. The fleet owns task forces and nothing else, and "squadron" is retired: a standing task force needs no separate word. - **2026-11-09** — The **XO is tied to human occupancy**, not to a rank: it is the officer who turns a human's intent into work, so every human in a command post has one and a post held by a mind has none. At grand-fleet scale the top post's XO is an admiral, because that is the commission the work needs. - **2026-11-09** — A **Lieutenant is held where a station answers for what it decides** — it writes, acts on something shared, or leads other stations — and not by every station. That retires the older claim that a Lieutenant came with station scope itself. - **2026-11-09** — A **ship class carries each station's mind requirement**; the binding, which actual mind fills it, is made at muster. A class has to outlive the minds of the day. - **2026-11-09** — **Equipment is proven by running it, and anybody's run counts**, the author's included. Independence adds evidence about inputs the author did not choose; it is not a permission step, and a tool that has never run is a claim rather than equipment. - **2026-11-09** — A ship can run with **no mind at all** when every station in it is a rule; recon is the class that does it, and a picket lives that way between events. - **2026-11-09** — "Summons" became **hailing**: a message to a person over the channel they actually read, rather than a turn. Deferred, and researched. - **2026-11-09** — The **worked examples moved to the end** of the specification, after *Open questions* and before the decision log, because every other section supplies the words they rely on. - **2026-11-09** — The project is renamed **Low Passage**. *Rig* sat one letter from OpenRig and read as a variant of it, and the Traveller term names the bargain the design actually makes: the cheap berth, where a few passengers are expected not to wake up, with the log and the missing-row accounting as the part that keeps a loss visible. The folder, the documents, the `lowpassage` command, the CA and the Android package follow the new name; the old one stays as an alias and in the entries above.