The slow way, made survivable Chapter 13 of 23 Svenska

The map · Part Two · The machine · Chapter 13 of 23

Why the method needed a machine

A method on paper decays: you forget, you drift, you re-argue a settled question the day a price moves. The machine's job is to measure and to remember. It is built, deliberately, not to decide. About 7 minutes · on the 10-minute route.

Everything in Part One could be done with a notebook. For a while it was. Here is what happens to a method that lives in a notebook.

You forget. Six names on a watchlist, each with a buy price and a stop, and on a Tuesday evening in March you do not remember which report you last valued NAME B on. You drift. The cushion was 25 percent, but this one is nearly there and you understand it well, so 22 would be fine, just this once. You re-argue. A price falls 8 percent in a day, and a question you settled in writing three weeks ago is suddenly open again, because now there is a stake in the answer. None of this is stupidity. It is what a person does with a rule when the person is tired, or excited, or has money on the line. Part One is a set of habits designed to be hard to bend, and habits are exactly what a person under pressure bends first.

So the method was given a machine: a small program on a rented server that runs every night, fetches the day's prices, compares them with the lines the owner has already written down, and reports. It remembers what the owner decided and when. It does not get excited.

The governing principle

The tool measures. The owner decides. That is the whole design, and it is enforced, not merely intended.

The line the tool never crossesTwo columns separated by a thick vertical wall. Left, what the tool may do: fetch, compute, compare, write a report, point, say data missing. Right, in purple, what only the owner may do: enter a name, assign a tier, write a growth view, set a value or stop, move a name, decide. the tool mayonly the owner mayfetch prices and filingscompute a fixed set of figurescompare a price to a linewrite a report and a pagepoint at what needs a looksay DATA MISSINGenter a nameassign a tierwrite a growth viewset a value, a buy line, a stopmove a name between statusesdecidethe wall is code: a write across it fails the run
The governing rule as a wall. Everything on the left is measurement. Everything on the right is a decision, and the code that writes measurements is built so it cannot write a decision.

What the machine may do is a short list of verbs. It may fetch prices and filings. It may compute a fixed set of figures. It may compare a price to a line. It may write a report and a page. It may point at a name that needs the owner's attention. It may say that a figure is missing. What it may never do is longer, and every item is written into the code as a refusal: it never writes a verdict, never enters a company into the process, never assigns a tier, never sets a value or a buy price or a stop, never moves a name from one status to another. In the tool's own summary, it computes market data only, and "everything requiring judgment is a MANUAL field you fill in by hand; the tool never computes, guesses, defaults or back-fills any of it."11README. The scheduled screen 'may SNAPSHOT, RANK and REPORT; it never enters a name' (ruling E93). A refresh 'FETCHES, EXTRACTS and REPORTS; it never decides' (ruling E92). The price watch 'points once per crossing and writes nothing' (ruling E97). The page generator: 'this project's design is that the page measures and I decide.'

Why the non-autonomous design is the harder one

It would be easier to build a program that decides. Give it the rules and let it mark names as bought or refused; it would never get tired. It would also inherit every weakness of its author and add its own, and nobody would be able to tell which was which, because the decision and the measurement would be one thing.

Keeping them apart costs work at every layer. Each automated step is given its list of allowed verbs and a mechanical check that it did nothing else: the refresh command runs under an assertion that the owner's file was not touched; the scheduled screen is started without the one flag that would let it enter a name, and the unit that starts it cannot write to the folder the file lives in; the page generator runs under a test that takes a census of every file in the repository before and after and asserts not one byte moved.22The assertion assert_no_watchlist_write in the refresh module; the absent --write-pipeline flag and the read-only config directory in the scheduled screen's unit; the census test on the overview generator, described in the project brief §4.7. A program that cannot decide has to be prevented from deciding at every point where deciding would be convenient.

There is a body of research on what happens when people work alongside automation, and its recurring finding is that people stop checking things the machine seems to have checked. The term is automation misuse: over-reliance that leads to monitoring failures.33Parasuraman and Riley, 'Humans and Automation: Use, Misuse, Disuse, Abuse', Human Factors 39 (1997). A tool that renders a verdict invites exactly that. A tool that renders a distance and a list of what it could not check does the opposite: it hands the reader an unfinished job, every night, with the unfinished parts named.

The rest of Part Two is how that principle is built: how the pieces are separated, how the record is kept honest, how the rules stay above the code, what happens at half past ten every night, how the owner finds out when it does not happen, and how the result reaches a phone without opening a door into the machine.

Decided
The program measures and reports. Every decision is the owner's, made by hand, and the program is built so that it cannot make one even by accident.
Why
A method that decides inherits its author's biases and hides them inside the measurement. Separating the two keeps both checkable, and keeps the owner reading rather than trusting.
Cost
Every allowed verb has to be fenced with a check that nothing else happened, at every layer. The owner does all the deciding, on every name, every time, and nothing about the machine makes that faster.

Sources for this chapter

  1. Parasuraman and Riley (1997), Humans and Automation: Use, Misuse, Disuse, Abuse
    https://journals.sagepub.com/doi/10.1518/001872097778543886
  2. What each automated step may and may not do — read from this repository: README.md; reference/FRAMEWORK-EDITS.md E92, E93, E97; vss/refresh.py; vss/screenwatch.py; vss/overview.py

The slow way, made survivable. Built 2026-09-13 from the repository as it stood that day. NAME A and NAME B are fictional; no company, price or holding appears on this site. Not financial advice: one private investor's method, shared as it is.