# Worked Example 03 — Installing the Node *Created:* 2026-11-12 The order that [[Worked Example 02 — Ingesting Kraken]] left open, finished. The first walkthrough brought up a galaxy, the second reduced an order until something could be mustered, and this one builds what the order asked for and proves it. It is the first time in the series that the Admiral's intent is satisfied rather than recorded as outstanding. **The state it inherits.** One flagship, one working party retired, four subgoals achieved, and `G-1` still open: ```mermaid flowchart TB G1["G-1 · kraken carries an enrolled node,<br/>and the Admiral's use is unchanged — open"] G11["G-1.1 · which ingestion — achieved"] G12["G-1.2 · what kraken is — achieved"] G13["G-1.3 · an account — achieved"] G14["G-1.4 · the node can start at boot — achieved"] G15["G-1.5 · node installed and enrolled — open"] G1 --> G11 G1 --> G12 G1 --> G13 G1 --> G14 G1 --> G15 ``` What the fleet holds from the reconnaissance: a reachable Raspberry Pi on 64-bit Debian, `passage` as an ordinary account, lingering already enabled, and the evidence in the log. What it does not hold is a node. ## The deadline, and the goal that replaces it The Admiral's next message adds a constraint the earlier ones did not have: > I'm going out at seven. The box can be down for ten minutes, not the evening. So `G-1.5` is stated with a deadline and a fallback, and both are part of it: ``` goal MIS-001:G-1.5 parent MIS-001:G-1 statement kraken carries a node enrolled in the Galaxy, returning after a restart, with the Admiral's use of the machine unchanged shown_by the registry entry; /health from the flagship; a restart and the node back; nothing written outside passage's home due 2026-11-12 19:00 America/New_York fallback MIS-001:G-1.6 — the node runs while the machine is up, with boot-start recorded as missing owner borrowed-light:command:lead status open ``` **The fallback is a goal, not a failure state.** If seven o'clock arrives with the node not proven, `G-1.5` closes `expired` and `G-1.6` opens with `replaces` pointing at it — a weaker goal that still delivers something: a node that runs whenever the machine is up, with boot-start recorded as a gap rather than discovered later by a power cut. The order would be partly met and the record would say which part, which is a better ending than an open goal with no date on it. **The owner changes when the work is delegated.** `G-1` is the Commodore's; `G-1.5` is the install ship's, because the Commodore hands the work over and the captain answers for it. One station owns a goal at a time, and the handover is recorded rather than implied. ## Designing the install The Commodore runs the nine steps again, with better inputs and a clock. **1. State the goal and the evidence.** The record above. Its evidence is four things, and each is checkable by somebody who did not do the install. **2. List the work.** transform: place the release, write the user unit, join the cluster, start the node. judge: whether the node is registered, reachable, and still there after a restart. command: the Commodore, then the ship's captain. Observation is finished. **3. Find the context domains.** One. Everything from here concerns one machine and one install. **4. Give the domain a station set.** Three, because the work has three shapes: **install**, the only station that touches the machine; **verify**, which proves the install rather than trusting it; **record**, the custodian that keeps the evidence and writes each hash into the ship's log. **5. Assign the proof obligations to somebody who did not do the work.** Verify judges the install. The custodian keeps what verify judged. The Commodore judges the goal. Nothing in this chain signs its own work. **6. Add command and draw the handovers.** A ship needs a Captain, and the Captain is a station aboard it, so the design gets a captain's station and a Captain commission from the Commodore. Three edges: install hands to verify, verify hands to record, the captain closes the sortie. The Commodore still judges the goal. **7. Allocate minds.** The captain needs cognition, because deciding whether a failed install is worth retrying or is a finding takes judgment. The three work stations do not: each follows rules, and the one judgment in the sequence has a pass or a fail. The captain binds the **`work`** mind — added after first light, unbound through the whole reconnaissance, and finally employed. **8. Check the budget and the caps.** One ship, three stations, one mind, one install, four hours. Larger than the party because the work produces a procedure worth keeping, and still arithmetic rather than appetite. **9. Record the order of battle in the flag log before anything is mustered.** Same rule, same reason: the design exists as an entry before the ship exists as a process. **Ship or working party, this time.** **Memory**: yes — how this board is installed, what counts as a good install on it, and what broke — has to live somewhere that outlasts the sortie. **Boundary**: yes — it holds an account's password and writes to a machine that belongs to somebody else, and neither belongs in the command ship's tree. **Queue**: unknown, and recorded as a prediction rather than a reason. Two of the three are enough. The ship is named **Borrowed Light** (`borrowed-light`), for a node that lives on a machine somebody else is using. No class is written: nothing in the library installs a node, and one install is not evidence of a standing function. If a second machine arrives, the order of battle is promoted to a `tender` — the same class the phone mission later earns — and the prediction is recorded as having held. **Rejected alternatives, recorded.** A working party on the flagship, because it would put the machine's password and the writes inside the command ship's boundary. One station doing install and verify, because an installer that certifies its own install has already failed the independence rule. A `starter` class, because a starter changes code and this changes a machine's boot. ## The order of battle | Station | Sensors | Effectors | Mind | |---|---|---|---| | `borrowed-light:install` | the account's shell, the release's checksum, the unit's status | write files, start the user unit, join the cluster | none | | `borrowed-light:verify` | `/health`, the registry, the restart evidence, the owner's own service | request a restart; block | none | | `borrowed-light:record` | the artifacts and their hashes | write the proof store; record each hash | none | | `borrowed-light:command:lead` | watch bill, station status, the goal | assign sorties, judge, release | work | **Why the install crew can work without a mind.** Its steps have dependencies but no choices: the release must be in place before the unit, the unit before the service starts, the join before health. A plan graph says which steps are eligible, and the crew takes them in the spec's order: ``` needs(unit, release). needs(join, release). needs(start, join). needs(health, start). needs(owner_check, start). requires_chit(join). ``` **The rendering**, versioned beside the clauses so a person can review the plan without reading Prolog: - the release must be in place before the unit is written or the join is attempted; - the unit must be enabled before the service starts; - the join must be spent before the node starts; - health and the owner's check come after the start; - the join waits for the chit. That is not a flourish. The chit that admits the node has not arrived when the install starts, so `join` is blocked — a missing chit blocks a step the same way a missing login blocks a probe. The graph lets the crew place the release and write the unit while it waits, instead of sitting on a blocked first step. A mindless crew cannot invent the install, and it does not have to: it can route through the steps the spec already declared. ## The work Three sorties, one per station: ```markdown # missions/MIS-001/sorties/SOR-002/SPEC.md --- id: SOR-002 mission: MIS-001 task_force: TF-1 campaign: none goal: MIS-001:G-1.5 intent: Place the node on kraken, enroll it, and start it. --- ## Do 1. Copy the release into passage's home and verify its checksum. 2. Write the user unit, and enable it under the user manager. 3. Join the cluster with the chit, writing the keypair, certificate and identity. 4. Start the unit and read its health line. ## Capture The checksum, the unit file, the join output, and the first health line. A step that could not run is recorded as unrun, with the reason. ## Proof The captured results, plus the verify station's judgment that the node is installed and enrolled. An install that cannot be proven is not an install. ``` `SOR-003` is the verify spec, and its content is the goal's evidence stated as things to check: `/health` from the flagship, the registry entry, a restart with the node back, and nothing written outside `passage`'s home. `SOR-004` is the custodian's: take what the two produced, hash it, index it, and write each hash into the ship's log. ## The admission A node joins by admission, and admission is a command act. At bootstrap the only chit was minted by the forge; every chit after it comes from the highest command scope the Galaxy has. Here that is the Admiral, and the Admiral is a principal with a console and no effector, so the Commodore puts the question and executes the answer: > **Commodore → Admiral:** May I admit one node? It is kraken, the machine you gave an account for. The chit is single-use, it expires tonight, and the certificate is signed by the Galaxy's own CA. > **Admiral → Commodore:** Admitted. ``` chit CH-0001 uses 1 expires 2026-11-12 19:00 America/New_York authority the Admiral's ruling issued_by flagship:flag:commodore admits kraken ``` The log records the ruling and the chit, because a node admitted without a decision is a node nobody agreed to. The chit travels to the install station, which is the only station that uses it, and it is spent at the join. ## The mustering ``` capacity request id MSG-0011 correlation MIS-001:G-1.5 from flagship:flag:commodore to flagship:bosun ask muster one ship scope task force authority the Commodore's commission deadline before the goal's due time payload ship: borrowed-light, captain's station, three work stations, one work mind ``` The bosun checks the authority — here it is the Commodore's own, because only a commodore may muster a ship — and creates the ship, its registry entries, and its captain's station. The quartermaster binds the `work` mind to the captain, and the log records the muster. The flagship now has two ships in its task force, and for the first time both minds are busy: `command` on the Commodore, `work` on a captain. ```mermaid flowchart TB F["Fleet"] --> TF["Task force"] --> F1["flagship"] TF --> B["Borrowed Light"] F1 --> C["commodore"] B --> L["command:lead"] B --> I["install"] B --> V["verify"] B --> R["record"] I -->|"installed"| V V -->|"evidence"| R L -.->|"closes on the proof"| C ``` ## The install The install crew works from `SOR-002` and the plan graph. The place is a Raspberry Pi on the house network, reached over SSH as `passage`, with the account's password taken from the station's config. **The release goes into a home directory, and nothing goes outside it.** The tarball is unpacked under `passage`'s home and the checksum is read; the only other file written is the user unit under `~/.config/systemd/user/`, which is still inside that home. No package is installed, no system directory is touched, and no service is started by root. That is what an implant is: the machine keeps doing its own work, and the fleet lives beside it. **The unit is a user unit, and lingering is what makes it survive a logout.** `systemctl --user enable` works inside `passage`'s own session; the part that makes it start at boot is the lingering set in the previous walkthrough, which gives the user manager a runtime with nobody logged in. The crew checks that the unit is enabled rather than assuming it: `systemctl --user is-enabled lowpassage-node` answers `enabled`. **The join spends the chit.** The node generates a keypair, presents `CH-0001`, receives a certificate signed by the Galaxy's CA, writes its distribution config and its identity, and registers. The chit is single-use, so a second join with it is refused; the node's identity is now its certificate, and the chit has done its only job. **The ordering is the graph's, not the clock's.** The chit arrives at 18:20, with the release already placed and the unit already written. Had the crew waited on `join` first, the sortie would have sat idle with the deadline running, which is the cost the graph exists to avoid. **The install closes on evidence, not on optimism.** The crew reports the checksum, the unit file, the join output and the first health line, and hands to verify. G-1.5 is not achieved yet: the node is installed, and nothing has shown that it comes back. ## The verify The verify station touched neither the install nor the reconnaissance. It checks four things, in the order the goal names them. **The node answers another machine.** `/health` from the flagship, over the network, not from kraken's own shell. This is the difference between a process that is running and a node that is reachable. **The registry holds it.** `kraken@kraken` is in the roster, the certificate verifies against the Galaxy's CA, and the log has the join event. A node that answers but is not registered is a stranger on the network. **It comes back by itself.** This is the one the fleet cannot cause. A restart needs a privileged command on a machine the fleet does not own, and the account is ordinary: the crew can run a process, not `reboot`. So the verify station hails: > **Verify → Commodore → Admiral:** I need kraken rebooted, and I cannot do that from here. Power-cycle it, or tell me when you have. I will watch for it to leave and come back, and the gap is part of the proof. > **Admiral:** Doing it now. The verify watch records the node going away at 18:42 and answering again at 18:44, with the registry entry intact and the process back under the user manager. The gap is the evidence: a node that never left has not proven it returns, and a restart that nobody watched is a story about a reboot. **The owner's use is unchanged.** The crew checks what the install actually wrote — `passage`'s home and the user unit, nothing else — and that the machine's own SSH still answers. The Admiral confirms the rest, because only he can say whether his use of the box is what it was. That confirmation is a ruling in the log, not a courtesy. **Then the goal closes.** Four pieces of evidence, judged by the Commodore: the registry entry, `/health` from the flagship, the restart gap and the return, and the owner's use unchanged. `G-1.5` is `achieved` at 18:50, ten minutes inside its deadline. **The fallback is recorded and not used.** `G-1.6` was declared at 17:55, never opened, and the record says so — a fallback that fired would have changed the order's outcome, and a fallback that did not is part of what the order meant. ## The order is finished `G-1` is achieved, so the mission is finished: `MIS-001` closes `achieved`, and with it the Admiral's order that began *"Ingest the machine named kraken."* Everything the fleet established is in the log; everything it did not is named; the record can be read by somebody who was not there. ```mermaid flowchart TB G1["G-1 · kraken carries an enrolled node,<br/>and the Admiral's use is unchanged — achieved"] G11["G-1.1 · which ingestion — achieved"] G12["G-1.2 · what kraken is — achieved"] G13["G-1.3 · an account — achieved"] G14["G-1.4 · the node can start at boot — achieved"] G15["G-1.5 · node installed and enrolled — achieved"] G16["G-1.6 · the fallback — declared, not opened"] G1 --> G11 G1 --> G12 G1 --> G13 G1 --> G14 G1 --> G15 G15 -.->|"if 19:00 passed"| G16 ``` **What the node is for is still a decision nobody has made.** It has headroom for a small mind, and the order did not ask for one. The record holds it as a station host with a measured ceiling, and a mind would be a later **fitting** rather than a second ingestion — a different order, a different goal. ## What happens to the ship **The close-out review.** With the order closed, the captain reviews the plan against what happened and proposes one change: the reconnaissance role should declare that the probe reading memory, disk and installed packages needs a login, so the next machine's party asks for the account when that probe becomes relevant instead of discovering it at the end of its list. The evidence is `SOR-001` blocking on exactly that probe. The Commodore accepts it, and the role goes to version 2 with the finding recorded against it — and the next reconnaissance starts with the question this one took two subgoals to ask. **Borrowed Light** has no jobs left and no standing watch. Every job is closed, the `work` mind is unbound and its allocation returned, and the procedure is written down: how this board is installed, what counts as a good install, and what the chit did. So the ship goes into **reserve**, not into decommissioning — the procedure is the thing worth keeping, and the queue prediction is still open. If a second machine arrives within the threshold, the ship is reactivated and its order of battle is promoted to a `tender`, with the prediction recorded as having held. If none does, the ship is decommissioned, its rough log and procedure fold into the fleet, and the prediction is recorded as unscored with reason `no next run` — which is the answer to the queue question rather than a failure to answer it. ## The first analyst The fleet has now closed a goal, left one prediction open and made a plan change, and it has no station whose job is to look across them. So the Commodore musters one. The **analyst** at `flagship:analyst` is a ship-level station with read access to the log and the metrics, `topology.diff` and `proposal.write` — and no `topology.apply`, because it proposes and never decides. It takes the `work` mind as Borrowed Light releases it: one mind, two stations, in sequence rather than at once. That is the mind-pool rule doing its ordinary job — capacity buys concurrency, and a mind idle on a ship in reserve is capacity the fleet can spend. It is the first station in the fleet whose whole work is looking backwards. Its first act is to check the captain's close-out review against the record — a proposal built on a review nobody checked is one mind agreeing with itself — and its first proposal is the role the reconnaissance authored: ``` proposal: promote recon-of-one-machine from candidate to proven expected: the next reconnaissance needs no design pass, and asks for the account at the probe that requires it rather than at the end of its list evidence: SOR-001, five probes returned and one added, judged by the Commodore; the captain's close-out review of the install risk: one machine is one run; the role may fit this board and not the next scored_by: the next reconnaissance of any machine, same role version requires: the Commodore's approval; expires 2027-02-01 ``` The Commodore approves it. The role's status flips to `proven`, `proved` is filled with the evidence, and it becomes selectable by any ship that needs it. The prediction is recorded, and the next reconnaissance is what scores it. **Not in the bootstrap crew, and not machinery.** The analyst appears when there is a cohort to read, which is why the two walks before this one had none. It does not command, and it does not apply its own proposals: a station that proposed and approved its own change would be the same self-marking the proof rules forbid. ## What this exposed **A deadline changes the design, even when it does not fire.** The fallback forced the Commodore to say what a partial success would be before the work started, and the clock made the chit's delay visible as a cost rather than as weather. The install still finished with ten minutes to spare; the value was in knowing what would happen at seven o'clock. **The second privileged act is a hand, not a secret.** Enabling lingering needed a password; rebooting needed somebody with a hand on the machine. The fleet asked for the smaller thing both times — a command, then a switch — and got what it needed without holding root for the evening. The distinction matters for the design: some dependencies are secrets and some are presence, and they are handled differently. **The chit did its job once.** The first node after the forge was admitted by a command, exactly as the bootstrap predicted, and the chit was spent at the join. The record shows the ruling, the issuer and the expiry, which is what makes an admission a decision rather than an event. **A ship can be earned on two tests.** Memory and boundary carried it; the queue answer is a prediction, and the ship's fate is where the prediction gets settled. That is the pattern the specification asks for, and it is more honest than claiming recurrence from one install. **A crew with no mind can still route.** The install crew could not invent a step and did not need to: the plan graph let it work around the missing chit, in the spec's order, without a judgment. The graph is what a mindless station gets instead of a plan. ## Reference - [[Worked Example 02 — Ingesting Kraken]] — the state this walkthrough starts from, and the subgoals it achieved. - [[Worked Example 01 — Bringing Up a Galaxy]] — the installation and the first crew. - [[Low Passage]] — goals, deadlines and fallbacks, the chit, the ship test, and the plan graph. - [[Low Passage Research]] — the measured Erlog result behind the graph, and the device's numbers.