A constitution, a routing table, a question register, a decisions log, and a changelog that records its own corrections.
IN PRODUCTION
This runs in client systems today. The sample below was regenerated for a fictional company.
Every company system needs an answer to five questions: which source wins, where does a request go, what do we still not know, what has been decided, and what changed. These files are that answer. The changelog is the most trustworthy of them, because it records the corrections as well as the changes.
TRY IT / RUNS IN YOUR BROWSER
Use it here.
The mechanism is the production one. The company, the catalogue, and every figure are fictional.
Reading the spine files.
THE OUTPUT / GENERATED FOR APEX INSTRUMENTS
What comes out.
JSON
14 ranked articlesData · Each article carries the rule, the reason it exists, and what happens when it is broken. Covers the order of authority between sources, what may never be invented, what has to be escalated, confidentiality, the rule that a documented human decision outranks the data, and the tiebreak when two articles conflict.Open the file ↗
JSON
20 request kinds and the load orderData · Each route names its handler, the files it reads in order, the files it may write, and what it does when the request does not quite fit. Four routes stop for a person. Plus the fallback for a request that matches nothing, and the seven step load order that separates what is read on every request from what is opened only on a match.Open the file ↗
JSON
30 numbered open questionsData · Owner role, the person in it, who filed it, when it was filed and when it is due, the answer where one exists, and who it is blocked on where it is blocked. The status is derivable rather than declared, which is why the widget can recompute it and disagree.Open the file ↗
JSON
18 decisions across three statesData · 3 LOCKED, 11 ACTIVE, 4 SUPERSEDED. Each carries the decision, the date, who made it and their role, and the reasoning. Superseded ones point at what replaced them, including one chain that runs three hops. Two LOCKED decisions carry the request that later tried to change them, the outcome, and the article number that refused it.Open the file ↗
JSON
127 dated entries, 8 of them correctionsData · What changed, who or what changed it, and the kind. Eight entries correct an earlier entry by id and say what was wrong with it, and one of those corrects another correction. The corrections are the reason the rest of the file can be checked.Open the file ↗
JSON
The seven step sync ritualData · Runs after any change to any source. Each step says what it does, what it checks, and what stops it. A stopped run is a normal outcome, and the run reports where it stopped and what it had already done.Open the file ↗
MJS
The fixture generatorData · Deterministic. Question status is derived from the answer, the blocked field and the due date. Changelog corrections point at their target by a tag rather than by id, so the links cannot drift when an entry is inserted, and the generator refuses to write a correction that names a missing or future entry.Open the file ↗
The constitution says which source outranks which, and what may never be invented.
02Route the request
A routing table decides who handles it and what gets read first, so a large system does not read everything every time.
03Number the unknowns
Every open question has a number, an owner, and a due date.
04Track the decisions
Locked, active, or superseded, with a chain back to what replaced what.
05Record the corrections
The changelog carries the mistakes too, or it is a marketing document.
WHAT IT READS
A written constitution with numbered articles
A routing table and a load order
Open questions with owners and dates
Decisions with their states and supersessions
WHAT IT CHECKS BEFORE IT SHIPS
Every article names its penalty, not just its rule
A locked decision cannot be quietly changed
Every superseded decision links to its replacement
Corrections in the changelog name the entry they correct
In production: a constitution, routing table, question register, decisions log with supersession tracking, and changelogs of 126 and roughly 100 entries across the two company systems.
The mechanism runs inside client systems. Everything on this page was regenerated for Apex Instruments, a company that does not exist. Client names, source files, and internal wording stay private.
