# Worked Example 02 — Ingesting Kraken One command taken by a fleet whose galaxy is barely an hour old, in the order the fleet takes it. It follows [[Worked Example 01 — Bringing Up a Galaxy]], whose galaxy is the one described there: one node, one flagship, four crewed stations, two minds, and a bridge somebody can type into. **Ingestion is not necessarily what a fresh fleet does first.** A fleet of one can survey, audit, watch or write, and every one of those is a reasonable opening. It is what *this* fleet is doing first, and it happens to exercise the parts that were hardest to get right. **The galaxy as inherited.** One node, one fleet, one task force, one ship, four crewed stations — the state the first walkthrough hands over: ```mermaid flowchart TB F["Fleet"] --> TF["Task force"] --> S["flagship"] S --> C["flagship:flag:commodore"] S --> CM["flagship:flag:comms"] S --> B["flagship:bosun"] S --> Q["flagship:quartermaster"] ``` The command is one sentence: > Ingest the machine named "kraken". Nothing else is given. What follows is what the fleet does with that, and the two places it has to stop. ## What the Commodore has to work with - **A mind** — the `command` mind, bound to `flagship:flag:commodore`. - **Standing orders** — its own, empty, and its copies of the fleet's and the task force's, also empty. Nothing has been decided yet. - **The definition library** — `starter` and `workshop`. - **The skills** that were deployed with the galaxy. That last item is the one this command turns on, and until now it had not been named. The command mind knows what a fleet is and what a machine is. What it does not know is what **ingest** is meant to mean here — and that is a word in the fleet's own vocabulary rather than the world's. ## The first stop: which ingestion A skill says what the fleet means by the word. Ingestion is the family name for putting the fleet on a device, and it has two modes: **scooping out its brain** empties the device down to the fleet's own work, and **giving it an implant** leaves the device doing its job with the fleet living alongside. They are not equal in trust, they need different stations, and they produce different objects. A skill can say all of that. A skill cannot say which one the Admiral meant, because that is a decision rather than a procedure — and the rule is to ask when the answer changes what gets built. So the mission goes `blocked` with reason `awaiting_clarification`, and the question names the decision it blocks. It goes out through Communications over the bridge channel, because that is the route the flag deck owns: > Ingesting `kraken`. Which mode? Scooped leaves a clean dedicated node. Implant leaves the machine its other work and puts the fleet alongside it, at lower trust and with the owner's apps sharing the boundary. The answer decides what gets mustered, so I have not started. That is not timidity and it is not a failure. Asking costs one round trip. Guessing costs a ship built for the wrong trust boundary, and then a second ship to build it again. ```mermaid sequenceDiagram participant Admiral participant Comms as Communications participant Commodore Admiral->>Comms: Ingest the machine named "kraken" Comms->>Commodore: message to flagship:flag:commodore Commodore->>Commodore: consult the ingest skill, find the ambiguity Commodore->>Comms: hail: which mode? Comms->>Admiral: the question, with its decision Admiral->>Comms: Implant it Comms->>Commodore: reply, routed by what it answers ``` ## The Admiral answers > Implant it. It is one of my machines and I want to keep using it. The reply comes back over the same channel and goes to the station that asked, because it names the question it answers. The block clears. The Commodore now knows which object it is building, and knows one thing more: this machine belongs to somebody who wants it back. ## The second stop: nobody knows what kraken is An implant is not something you can design blind. The Commodore does not know whether kraken is reachable, what it runs, how much it has, or whether anything on it would fight a node — and none of that was in the command, nor is it in the fleet. So the next move is not to muster the ingestion. It is to find out — and the only question worth asking is what *finding out* requires. - **Sensors, and almost no effectors.** It resolves a name, probes ports, reads a banner, and writes down what it saw. Nothing it does changes the machine. - **No judgment.** Every step is a check with a pass or a fail, so there is nothing to consult a mind about. - **No queue.** One machine, six checks. - **A lifetime and a stop condition**, because a probe that is still running tomorrow is a probe nobody is watching. Which is a **working party**: one station, one sortie, rules instead of a mind. Not a ship. A recon *ship* would be the right answer to a different question — how a fleet watches many machines, repeatedly, over time. Reaching for that name first is how a fleet ends up designing around a class that nearly fits, so the Commodore works from the work and lets the name come later if it comes at all. It does flag what it is assuming, though: > Assumed one-off: one probe of one machine, no queue of its own and no boundary to protect. If probing turns out to recur, a recon class earns its own ship and this question reopens. That flag matters, because the assumption is the thing most likely to be wrong — and the class it mentions is a prediction rather than a premise. The flag is written into the order of battle, the ship's log and the bridge; where those go, and what the flag is worth, are in [[Low Passage Research]]. ## The force design Before anything is mustered, the Commodore writes an **order of battle**. The specification gives the design nine steps, and the order matters: each one narrows what the next can be. What follows is those nine, against this command. **It restates the outcome.** *kraken is known, and the fleet knows whether it can be ingested.* The Admiral asked for an ingestion; what can be mustered today is the part of it that needs no login. **It lists the work** in the four verbs force design uses — observe, transform, judge, command — and finds that only one of them is possible. Nothing can be installed on a machine nobody has looked at. **Before it can draw anything, the work has to exist.** An order of battle with no sortie behind it is a station with nothing to do, so the Commodore writes the work down first: The mission carries intent and goes no further — one authored file, and the frontmatter is the whole of it: ```markdown # missions/MIS-001/SPEC.md --- id: MIS-001 intent: Ingest the machine named "kraken" with an implant, leaving the Admiral's own use of it untouched. task_force: TF-1 campaign: none --- ``` No campaign, because a campaign is earned: one mission with one sortie has not earned one. And nothing below the frontmatter, because a mission is intent and the leaf is where the work gets specified. The sortie is the leaf, so it carries the full specification: ```markdown # missions/MIS-001/sorties/SOR-001/SPEC.md --- id: SOR-001 mission: MIS-001 task_force: TF-1 intent: Find out what kraken is, and report it without concluding. --- ## Do Six checks, in order. 1. Resolve the name `kraken`. 2. Read the manufacturer prefix from the MAC behind that address. 3. Probe TCP ports. 4. Read the SSH banner. 5. Compare mDNS against the DHCP lease. 6. With an account, read memory, disk, processor, architecture, and what is installed. ## Capture The raw result of each check, whatever it turns out to be. A check that returns nothing is captured as having returned nothing, because a silence is an observation and a summary of one is not. ## Proof The captured results, plus the Commodore's judgment that they answer the question. A check that could not be run is recorded as unrun, with the reason it could not be run, and the sortie may close on that: incomplete and honest beats complete and invented. ``` It names no expected finding, because it is written by a Commodore that has not looked yet — the discipline behind that is argued in [[Low Passage Research]]. That file is what `SOR-001` in the capacity request will point at, which is what ties one station's work back to the intent that asked for it. **The work lives in the sortie; the station is told to fly it**, not told what the work is — which is why the checks are written here and not in the order of battle. **It groups the work into context domains.** A domain is a body of work that shares one context — the same facts, the same purpose — small enough to be held in one station's working memory. All of this is one domain: one machine, one question, one answer. Which is why the next step produces one station and not several. **It gives that domain one station with a reason to exist.** Not a ship: one bounded action, with a lifetime and a stop condition, no queue to own and no boundary to protect. **And it decides what the station is made of, in two parts** — because a station is not invented at the bosun. It is mustered *from a role*, and a role is a definition belonging to the Galaxy's library. Nothing in that library fits reconnaissance of one unnamed machine, so the Commodore authors a new role and marks it **a candidate**: it does not enter the library until the work proves it. | The role, authored here | | |---|---| | Role | reconnaissance of one named machine | | Sensors | name resolution; TCP connect probe; service banner read; neighbour-table lookup for the MAC | | Defaults | port probe: TCP connect, ports 1–1024, two-second timeout, one attempt. Banner read: to the first line or five seconds | | Effectors | append to the rotating record; append to the rough log | | Rules | run the checks in order; a check needing something absent is recorded and blocked | | Mind | none; the crew decides by rule | | The parameters, which are this muster's and die with it | | |---|---| | Address | `flagship:recon` | | Sortie | `SOR-001` — the checks are in its spec, not restated here | | Stop condition | all six returned, or the budget spent | | Lifetime | one sortie, four hours at most | | Budget | one sortie of probe traffic — no writes, no credentials used | | Proof obligation | the captured evidence, judged by the Commodore | The split matters. The role is reusable and belongs to the installation; the address, the checks, the lifetime and the budget belong to this mustering and are gone when it retires. What the message carries is a reference to a role plus the parameters that differ — not a station specification invented at the door. The Commodore wrote these checks during force design, because a crew with no mind cannot invent a scope. How the sortie's checks and the role's defaults divide, and what would move the checks permanently into the role, is in [[Low Passage Research]]. **What a role is, as an artifact.** A file in the Galaxy's definition library, like everything else here — Markdown with frontmatter, readable and editable by a person: ```markdown # galaxy/library/station-roles/recon-of-one-machine.md --- id: recon-of-one-machine kind: station role status: candidate version: 1 source: flagship:flag:commodore, for MIS-001 / SOR-001 missions: [MIS-001] proved: — --- ## Capability name resolution; TCP connect probe; service banner read; neighbour-table lookup ## Defaults port probe: TCP connect, 1–1024, two seconds, one attempt banner read: first line, or five seconds ## Rules run the checks in order; a check needing something absent is recorded and blocked ## Cannot change anything on the target; read anything it was not told to read ## Mind none ``` **It is created during force design** — not at the bosun, and not after the fact. That is the same moment the checks are written and for the same reason: the station is built from this file, so the file has to exist first. `status: candidate` is what it says while it is still an untested idea. **And it lives in one place throughout.** A candidate is not kept in the mission and moved later — it goes into the library at once, marked candidate, and the mark is what limits it: only the mission that authored it may muster from it. Promotion flips one field, fills in `proved`, and makes it selectable by any ship that needs it. Moving the file instead would break the reference the sortie holds, and two homes for one definition is precisely the problem the rest of these rules exist to prevent. **It puts the proof obligation on somebody who did not do the work.** The party captures; the Commodore judges. Those are different stations, and that separation is the whole of the independence requirement — a station judging its own captures is marking its own homework, and the design does not permit it. **It adds command and draws the handover.** No new commission is created for one probe: the Commodore already holds the task-force scope and the flagship's Captain commission, so the command side is already staffed. The handover is the design's single edge — `flagship:recon` → `flagship:flag:commodore`, on close, carrying the evidence. **It allocates minds, and here the answer is none.** The domain needs no cognition: every check has a pass or a fail, and nothing in the sortie asks for a judgment a rule cannot make. Recording *why* no mind is needed matters as much as recording a binding would, because the next person to read the order of battle will otherwise assume somebody forgot to assign one. **It checks the budget and the caps before it asks for anything.** One party, one sortie, one budget of probe traffic, no writes. The smallest topology that produces this proof is a party rather than a ship, and that is arithmetic here rather than taste. **And it records the order of battle in the flag log before anything is mustered.** This is the step easiest to skip and hardest to defend skipping: the design exists as a log entry before the station exists as a process, so if the muster fails, or the party is retired early, the record still says what was intended and why. Nine steps — outcome, work, domains, one station, proof, command, minds, budget, record — and nothing is mustered until the ninth is written. ## The mustering The order of battle exists and is recorded. Now something has to act on it, and that is not the Commodore — creating a station belongs to the bosun, the station with the effector for it. So the Commodore asks. ``` capacity request id MSG-0007 correlation SOR-0001 the sortie this serves from flagship:flag:commodore to flagship:bosun ask create one station scope flagship authority the flagship's Captain commission deadline before the sortie's lease expires payload role: recon-of-one-machine (candidate) + this muster's parameters ``` The payload is a role reference and a parameter set — the two tables above, and nothing else. Nothing about the design is renegotiated in the message: the message exists to carry it, and carrying it is all the Commodore can do. **The first thing the bosun checks is the authority**, because mustering a station needs the commission that owns the scope rather than the asker's word for it. Here that is the flagship's Captain, which at bootstrap is the same station as the Commodore — so the request is approved by the same crew that sent it, and the log records both halves rather than pretending they were two parties. That stops being a formality the day a task force has a second ship with a captain of its own. **Then the bosun acts, and it asks in turn.** It creates the crew from the payload, registers `flagship:recon`, and sends one more message before the station is complete: a binding request to `flagship:quartermaster`, naming the station and asking for a mind **or for a record that none is needed**. The quartermaster answers `none`, which is a fact the record holds rather than a question nobody asked. **The flagship gains a station.** The galaxy's state changes with it, but the change happens one level down: a station belongs to a ship, and the Galaxy holds it only through the Complement. Four crewed stations become five — the party is a station mustered for one sortie, with a lifetime and a stop condition rather than a place in the order of battle: ```mermaid flowchart TB F["Fleet"] --> TF["Task force"] --> S["flagship"] S --> C["flagship:flag:commodore"] S --> CM["flagship:flag:comms"] S --> B["flagship:bosun"] S --> Q["flagship:quartermaster"] S -.->|mustered for one sortie| P["flagship:recon"] ``` **And a watch is written.** This is the last thing mustering does, and it is where the whole of the party's working life lives: ``` watch W-0001 job recon of the machine "kraken" address flagship:recon lease until the sortie closes, or four hours attempt 1 checks 0 of 6 returned stop_condition all six returned, or the budget spent on_block record the reason and the target, keep the lease on_close hand over to flagship:flag:commodore ``` Three of those fields answer questions a mindless station cannot answer for itself. **`checks 0 of 6`** is how it knows what remains — it is not remembering, it is reading its own watch, and it reads the same field again after a block to find one check left rather than starting over. **`on_block`** is how it knows that being stuck is recorded rather than skipped. **`on_close`** is who it hands to when the checks run out. The crew decides none of those three; it looks them up. **Then it starts.** The equipment supervisor fits three tools from the store — a resolver, a port prober, a banner reader — each in its own child process, so a tool that hangs is buried rather than obeyed. A sampler begins ticking into the rotating record, a bounded local file that drops its oldest entries. ## What the probe finds Five of the six checks run, in the order `SOR-001` lists them. **Check one: does the name resolve?** `kraken` comes back with an address, so something on the LAN answers to that name. **Check two: whose hardware is it?** The MAC behind that address carries a manufacturer prefix belonging to the Raspberry Pi Foundation. A fact, not a conclusion: it says the hardware is a Pi and says nothing about which one. **Check three: what is listening?** Twenty-two is open and nothing else is — no web server, no broker, no share. The prober records the list rather than interpreting it. **Check four: what does the service say about itself?** SSH answers with a version string naming OpenSSH on Debian. Again a fact: a distribution and a service, not a capacity. **Check five: is the name the machine?** mDNS and the DHCP lease agree, so this is the box the Admiral meant rather than something else answering to a similar name. **What it wrote, and where.** None of those five reached the ship's log. Each went to the rotating record, because each is a tick — the resolver answered, the port list changed, the banner arrived. Only two transitions were worth the ship's history: the sortie started, and it is now blocked. A party that wrote every check into the log would bury the ship's history under a metronome. What it could not conclude went to its rough log, including the gap between what a datasheet claims a Pi carries and what five checks actually found. **Check six is where it stops.** That check needs a login. The order of battle says a check it cannot do is recorded and blocked rather than skipped, so memory, disk, processor, architecture and what is installed all remain unanswered — and the party knows that, because its watch still says one of six. The limit is worth stating rather than working around, because it is the difference between recon and guesswork. An operating system tells a stranger almost nothing about itself on purpose, and a fleet that infers capacity from a MAC prefix will be wrong on the first device that disagrees with its datasheet. **The party does not retire here.** Its watch goes `blocked` with a reason (`needs an account`) and a target (`flagship:flag:commodore`), and the attempt count does not move — a legitimate wait is not a failure being retried. The lease stays open and the mission stays unclosed, which is deliberate: a clock cannot tell patience from failure. ## The third stop: the account An implant needs somewhere to log in, and no station can make an account on a machine that belongs to somebody else. So the Commodore hails again — and this question is a different kind from the first. The first was about the fleet's own vocabulary; this one is about something only the owner holds. > To install the node I need to log in as somebody. A normal user is enough: the fleet wants a release in a home directory and a service unit, not root. Account name and password. > `passage` on that box, password where you keep such things. It is an ordinary account and I would rather it stayed one. ```mermaid sequenceDiagram participant Admiral participant Comms as Communications participant Commodore Commodore->>Comms: hail — I need to log in to install Comms->>Admiral: the request, and what it is for Admiral->>Comms: account "passage" and its password, in one message Comms->>Commodore: the reply, routed by what it answers Note over Commodore: the credentials go into the config of the<br/>station that uses them — never into the log ``` **The password arrives in the same message as the account**, over the same channel as everything else, because inventing a second route for one string multiplies the things that can go wrong without protecting anything. What protects it is handling rather than transport: it goes into the config of the station that uses it, never into the log and never into the standing orders, and the log records only that an account was granted, by whom and when. The same rule the mind host applies to a bearer token. One consequence follows and is worth saying plainly. **The bridge channel now carries the fleet's secrets**, so it is a channel that has to be trusted rather than merely convenient — which is an argument for TLS on the bridge in particular, and it settles that a console carrying passwords is not one to expose publicly. **User level is enough to install and run, and not quite enough to survive a reboot.** The release will go in a home directory, the node will run as an ordinary process with no special powers, and nothing will go into the system's own parts — so the owner keeps using the machine throughout, which is the point of an implant. What it will not do is bring the process back by itself. A user's service unit only runs while that user has a session, and a headless Pi nobody logs into would never start the node; a node that does not come back after a power cut is not a node. That is a gap this account cannot close, and it is the next thing the Commodore has to deal with. **The Commodore unblocks it.** Not a new party and not a new watch — the same watch, with the reason cleared and the missing thing supplied. The party reads `checks`, finds one of six outstanding, and does it: the account logs in, and the machine answers what only an owner can answer. That answer is the first judgment the sortie has been able to make. A Raspberry Pi running 64-bit Debian, with memory, disk and computation for a node **and a small mind** — nothing that would be a primary, but enough to be a grunt — and nothing running that would fight a node. So the account did two jobs at once. It proved the machine, and it is the thing the install will use. **Then it closes.** It hands over to the Commodore with the evidence, folds its rough log into the parent's, and is retired. Nothing is lost in the retirement, because the findings were never in the process: they were in the rotating record, the rough log, and the two entries that reached the ship's log. **The flagship loses it again.** Five become four — the same diagram this walkthrough opened with, which is the point — and what the party learned is in the log rather than in an inbox that no longer exists. ```mermaid flowchart TB F["Fleet"] --> TF["Task force"] --> S["flagship"] S --> C["flagship:flag:commodore"] S --> CM["flagship:flag:comms"] S --> B["flagship:bosun"] S --> Q["flagship:quartermaster"] ``` ## The fourth stop: the hand the fleet does not have The fourth stop begins with a document rather than a doubt. The **ingest skill** says what *installed* means, and one of its acceptance checks is that the node comes back by itself when the machine restarts. The Commodore reads that check and finds nothing in the fleet that can satisfy it — because **the fleet cannot escalate.** A station has no more rights than the account it runs under, and nothing in this design lets it acquire any. So a privileged act is not something the fleet does. It is something it asks for, and the ask is a hail carrying an action rather than a question. That is how every other reach in this design works. The fleet has no hands outside its own machines, so getting something done on a machine it does not control is a request to whoever can — what changes is only what the request contains. Three ways to make a process return at boot, and they trade privilege against robustness: | Route | Privilege needed | What it costs | |---|---|---| | A system unit | one privileged act | robust: starts at boot, restarts on failure, lives in the system's own tree | | A user unit with lingering | one privileged act — `loginctl enable-linger` | equally robust, and the unit stays in the user's own tree | | A user `@reboot` cron entry | **none at all** | starts at boot, but nothing restarts the node's VM if it dies | The Commodore puts all three to the Admiral, because it is the owner's machine and the trade is the owner's to make: > To make the node return after a reboot I need one privileged act. Three routes: a system unit or a lingering user unit cost the same one command, and a `@reboot` cron entry costs none and will not restart a dead VM. **Please write a rule rather than give me root.** A rule is one command and it can be read by somebody who was not here. Root's password is everything on that machine at once, and I would be holding it until the install finished and trusting myself to forget it. > Agreed on the rule. I would rather write it than have to run the command by hand every time that node needs rebuilding. ```mermaid sequenceDiagram participant Admiral participant Comms as Communications participant Commodore Commodore->>Comms: hail — one privileged act to make the node boot Comms->>Admiral: three routes, and what each costs Admiral->>Admiral: root, on their own box — write the sudoers drop-in Admiral->>Comms: done — the grant exists Comms->>Commodore: the grant, as a decision with a scope ``` **The rule has to exist before any of that can happen.** `passage` is a new account on a new machine: it is in no group, it holds no privilege, and `sudo` would refuse it without even prompting. So the Admiral's answer is not an assurance but an act — they are the one with root on that box, and what they do with it is write one file: ``` # /etc/sudoers.d/passage passage ALL=(root) /usr/bin/loginctl enable-linger passage ``` A drop-in rather than an edit to `/etc/sudoers`, because it is one line, it is named for the account it concerns, and it can be read, checked and removed without disturbing anything else. That is what makes the grant reviewable — not that it is small, but that it is legible. The grant stands and the use does not. What makes it one-shot is the password: the fleet already holds it, and discards it once the privileged act is done — so afterwards the permission exists and the fleet cannot exercise it. The grant enters the log with its scope — what was granted, to whom, by whose decision, for which command — so anyone asking later why a user on that box can run `loginctl` gets an answer. The Admiral could have taken a shorter route and handed over root's password, and an owner who trusts their own machine often would. Why the fleet asks for the rule instead, and what it does if the shorter route is offered anyway, are in [[Low Passage Research]]. ## What the Commodore designs next Six checks answered, an account in hand and a grant made. The same nine steps run again, with better inputs — which is what makes them steps rather than a checklist. **Restate the outcome.** *kraken carries a node enrolled in the fleet, running beside the Admiral's own work, returning by itself after a restart, and the Admiral's use of that machine is untouched.* **List the work.** transform: install the release, set boot-start, enroll, and verify each of those. judge: whether the node is registered, reachable, and still coming back after a restart. command: the Commodore. Observation is finished — that is what the six checks were. **Find the context domains.** One. Everything from here concerns a single machine and a single install, so nothing needs to be split. **Look for a class before designing one.** `survey` spends turns and produces a claim; `picket` watches something already reachable. Neither fits, so this is design-from-the-work — and because ingestion recurs, what gets written is a **class**, not a one-off ship. **Draw the stations.** Three, because the work has three shapes: - **install** — effectors: write files, run the installer, set the linger grant. The only station that touches the machine. - **verify** — sensors: the health probe, the registry lookup, and the restart test. It proves the install rather than trusting it. - **record** — the custodian: keeps the captured evidence and records each hash in the ship's log. So the install is proven by the verify station, never by the station that did the installing, and each station has a proof obligation rather than an assumption. **A tender**, not a party, because ingestion recurs: the fleet will add machines again, the work is the same each time, and enrollment being something done repeatedly is what changes the assumption. **It adds command, and this one is not free.** A ship needs a Captain, and the Captain is a station aboard it. So the tender gets a captain's station, a Captain commission, and a mind bound to it — and the mind is the **`work`** one, allocated and unbound since bootstrap and waiting for exactly this. Two minds existed at first light; the second has been idle for this entire walkthrough, and this is where it goes to work. **It draws the handovers.** Three edges: install hands to verify on completion, verify hands to record, and the captain closes the sortie. The Commodore still judges — a tender does not sign off its own install any more than the party judged its own captures. **It allocates minds down the ship.** 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 — does this install meet the acceptance checks — has a pass or a fail rather than a matter of degree. **It checks the budget and the caps.** One tender, three stations, one mind, and a budget of one install. Larger than a party because the work recurs, and still arithmetic rather than appetite. **And it records the order of battle in the flag log before anything is mustered** — the same step as last time and for the same reason: the design exists as an entry before the tender exists as a process. **What the node is for is a decision, and the machine does not make it.** It has headroom for a small mind, and an implant does not forbid one — a token kept on a machine somebody else uses is a weaker secret rather than an impossible one, and this machine is in the house and belongs to the person asking. So the Commodore spends the headroom on nothing today. The order of battle records it as a station host, notes that a small mind would fit, and leaves that to a later **fitting** rather than a second ingestion. The record then says what was measured and what was decided, which are different things, and the next person to look at the box does not have to guess which was which. The next change to the galaxy's objects is the tender that installs and enrolls the node — a second ship in that waiting task force — and it belongs to the walkthrough after this one. ## What this exposed The design questions this walk raised — skills in the bootstrap set, where an assumption goes, why a specification must not know its findings, who decides the checks, asking for less than you could get, and a standing rule with a transient key — are recorded with their arguments in [[Low Passage Research]]. ## Reference - [[Worked Example 01 — Bringing Up a Galaxy]] — the state this walkthrough starts from. - [[Low Passage]] — ingestion, modes, the ship test, and the rule about asking. - [[Low Passage Research]] — the Raspberry Pi as an SBC to ingest, and what a small mind needs that this one can only just meet.