Originally published on hexisteme notes.
I run a publishing gate that won't let a page go live unless every number on it traces back to a declared piece of evidence.
A draft carries an file listing evidence entries, each tagged , and one of five machine gates, , strips a page's HTML down to plain text, pulls every number out of that text, and blocks the draft if even one number has no matching entry.
All five gates have to pass before a human ever sees the draft to sign off on it, and the verdict is permanent per draft — edit the body, and you start over from a clean dossier.
A calculator that needs numbers the gate can't see I hit the edge of that design building a payment-fee calculator page with a separate site-builder tool I run: type in a revenue figure, get back the fee and the amount you actually take home.
A calculator like that needs JavaScript, and the JavaScript needs to know the fee rates.
The gate, though, cannot read inside a tag.
Whatever turns a page's HTML into checkable text either drags the script body along as text — a false positive, flagging numbers that were never really claims — or drops it entirely, a false negative on exactly the thing the gate exists to catch.
Two ways to lose Two fixes come to mind immediately, and both are bad.
The first is to teach the gate to parse JavaScript.
That means putting a JS parser inside the gate, which means the gate now owns a second language runtime — every bundler, minifier, and syntax change downstream becomes its maintenance debt from then on.
Worse, it's a fight where the losing condition belongs to whoever edits the code next: twist the JavaScript slightly and the parser loses.
The second is to exempt tags from the check entirely.
That one is more dangerous than it looks, and I know because I'd closed a version of exactly this mistake earlier the same morning. carries an exemption for alphanumeric identifiers — CSS values like , say — so they don't get flagged as unsourced numbers.
British pence notation, , was matching that same exemption and riding straight through the check, untouched.
A convenience exemption had quietly become a laundering channel.
Exempting wholesale would have reopened that same defect as a much bigger hole.
Making the JavaScript have nothing to read So I took a third path: instead of teaching the gate to read the JavaScript, I made sure there was nothing in the JavaScript worth reading.
The fee rate travels like this: The rate rides into the page as a attribute on a table row.
That row is HTML, which the gate can read, and its cell value is already rendered from a cited evidence entry.
The JavaScript itself never sees a fee rate — it reads a value that's already sitting on screen, already proven, and does arithmetic on it.
The gate ends up able to verify where this calculator's rates come from without interpreting a single line of JavaScript.
Five invariants, five enforcement points A direction like that isn't a guarantee by itself.
It only becomes a rule once every part of it has an enforcement point attached, and this one has five.
Rates enter only through an evidence reference. checks that every rate in a calculator row points at a declared entry; write a literal number directly into the row and the build fails.
Every numeric literal inside any has to belong to the set .
This is a new gate, , and it's the one actually carrying the weight of the design.
It isn't a parser — it's a whitelist. 0, 1, and 2 cover indices and sign; 100 covers percentage division.
A domain number structurally cannot fit inside that set.
Adding it meant bumping the gate's schema from v4 to v5.
Calculator output has to equal the declared derived value.
A small test harness runs eight scenarios and checks for an exact string match against what the gate computed as the derived value — rounding, currency symbol, and digit count all have to agree.
Script and style content never becomes body text in the first place. , the function that pulls a page's body text for ch