The slow way, made survivable Chapter 16 of 23 Svenska

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

The rules file

A written framework, amended only by dated, numbered rulings. A rule question and a bug go to different files. Writing the rule before the situation arises is what stops you bending it once you have a stake in the answer. About 8 minutes · on the 10-minute route.

The method exists as a document before it exists as code. That is not a figure of speech. There is a file, the framework, with numbered sections from 0 to 11, and there is a second, much longer file of rulings that amend it, each with a letter or a number, a date, and the statement that the owner ruled it. The code implements the rulings. It does not make them.

Three files, three jobs

  • The framework. The method itself: the gates, the hard kills, the valuation, the entry and exit discipline, the position sizing. It holds no dated holdings and no market data, so it never goes stale. It is at version 2.3.
  • The rulings. Every ambiguity, deviation and amendment, in lettered series. A for structural fixes. B for real ambiguities in the gates, each raised with a date and either decided or left open, and an open one is a question the owner owes an answer to. C for money-relevant ambiguities. D for consistency fixes. E for rulings on the tooling and, later, the substantive rules, E1 to E114 at the time of writing. F, the newest series, for the overview page. The file is appended to and never rewritten.11reference/FRAMEWORK.md and reference/FRAMEWORK-EDITS.md. The rulings file opens: 'Each item is a place where a human reading it knows what you mean and a machine does not. I have not applied any of these — every one changes a rule, and they are your rules.'
  • The backlog. Things wrong in the code. Its first lines draw the line: "A rule question goes to the rulings file and gets a letter; a defect goes here and gets fixed. Nothing in this file is a decision the owner owes an answer to."22reference/BACKLOG.md, opening.

The separation between the second and third files is the important one. A threshold that is wrong because the rule was wrong is a ruling. A threshold that is wrong because the code misread the rule is a bug. Mixing them lets a bug fix quietly change a rule, or a rule change hide inside a bug fix. Every threshold in the code cites the ruling that set it, and the screener's thresholds live in a configuration file where each one names its framework section, not in the code at all.33config/screener_filter2.yaml, each limb citing its section or ruling; module docstrings throughout vss/ citing E-numbers as the authority for a threshold or a field.

Why the rule is written first

What happens without a written rule

NAME A is at 91, the buy line is 85, and the owner has just re-read the reports and feels more confident than the tier allows. The sensible thing is to move it to tier 1, which puts the line at 89. Then wait for 89.

The rule, E100

A change to a cushion is a dated ruling, and it takes effect at each company's next scheduled reassessment, never immediately. A buy line that crosses because the cushion moved arms nothing.

The whole point of writing a rule before the situation arises is that at that moment you have no stake in the answer. When the situation arrives, you do, and the rule you wrote earlier is the only version of you that was thinking clearly. The rulings say "written before the code" on their face, and the version-control history is treated as evidence of the order.44Ruling E100 on cushion changes. The project brief §1.2: 'A ruling is written BEFORE the code that implements it, and many say so on their face.' A session that changes what the code does without a ruling behind it is, in the project's own words, doing the wrong thing.55The project brief, §0.

Every ruling states its price

The rulings are written in an unusual register: declarative, absolute where a rule is absolute, and explicit about what a decision costs. A deletion names what was lost by deleting. A new requirement names what it will make slower. This site's decision boxes copy that shape from the rulings.

Rules that were withdrawn

A rules file that only ever grows is suspicious. This one records its own reversals, and they are the best evidence that the process works, because each one shows a rule being corrected by a dated decision rather than quietly bent.

  • A gate with two limbs that measured nothing. Two tests of stability in reported figures were found to be measuring currency and season, not the business, and to have changed no verdict across five companies. Deleted, with the sentence "not widened, not softened, removed".66Ruling E30, 2026-08-25.
  • A debt cap loosened for the wrong reason. The first screener cap was set loose, on the principle that a coarse filter must not lose a name the careful reading would keep. Four days later a test run showed 72 names passing the loose cap and failing the method's own stricter test. Tightened, with the count in the ruling.77Ruling E2 replaced by E44, 2026-08-26.
  • A buy-price formula superseded, with the old figures kept. When the cushion was moved from the low-case value to the base-case value, three buy prices already struck under the old formula were not silently recomputed. They were kept, marked as superseded wherever they print, and the old multipliers stay in the code with a comment saying why.88Rulings E28, E32 and E90. The code keeps both multiplier tables: 'MBP_TIER_MULTIPLIER above is KEPT for the superseded paths' history.'
  • A citation that did not exist. The commit that built the phone tunnel cited a framework section as prohibiting a server. The section does not exist. The ruling that followed says: "The citation was asserted without reading the file and is withdrawn here." The commit message is immutable; the ruling is the correction of record.99Ruling F1, 2026-09-13.
  • A requirement withdrawn the day it was ruled. Ruling F1 required the phone page to mark itself stale after 26 hours. Ruling F2, the same day, withdrew that requirement as unbuildable: a static file cannot compare its own age to the time it is read without a script, and the same ruling forbids scripts. The two limbs contradicted each other; one fell. What remained, the page stating its own age twice, was implemented that day.1010Ruling F2, 2026-09-13.

None of these is an embarrassment. Each is a rule meeting reality and being corrected on the record, with the cost named, by the person entitled to change it. A method that cannot show a withdrawal has either never been tested or is hiding something.

Decided
The framework is amended only by dated, numbered rulings the owner makes. Code cites the ruling it implements. A rule question and a defect go to different files.
Why
A rule written before the situation arises is written by someone with no stake in the answer. A rule that lives only in the code can be changed by a bug fix.
Cost
Change is slow. A threshold the owner knows is wrong stays wrong until a ruling is written, and some open questions have stayed open for weeks. The rulings file is over eleven thousand lines.

Sources for this chapter

  1. The framework, the rulings and the backlog — read from this repository: reference/FRAMEWORK.md; reference/FRAMEWORK-EDITS.md (A1–A3, B1–B48, C1–C4, D1–D2, E1–E114, F1–F2); reference/BACKLOG.md; config/screener_filter2.yaml

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.