System · Build & Ship
The change that breaksyour build isthe good outcome.
A breaking change stops. Somebody sees an error, files a ticket, and the wrong thing does not ship. The dangerous one is where everything still validates, every consumer still runs, and the answer quietly means something else — nothing fails, reports just start being wrong. This asks four questions per change and tells you which kind you have.
Deterministic and offline. Reads no schema, diffs no files.
Grades the changes you describe — never people.
Instant download. Python engine, workbook, two playbooks, worked release.
01
Three outcomes, ranked by what missing them costs
Two of these you will find out about. One you will not.
ADDITIVE
Nothing downstream reads differently. New capability, same answers to the same questions. Ship it.
BREAKING
Something fails and you will know. A record stops validating, a consumer stops running. Expensive, loud, and safe — loud is a feature.
SILENT BREAK
Nothing fails and the meaning moved. Everything still validates, every consumer still runs, and the answers are quietly different from now on.
02
The fourth question, and why it is a gate
Three questions describe the change. The fourth asks whether you are in a position to answer them.
C-02
A new value added to project.status, with a default branch added everywhere it is read. Data validates, consumers run, meaning unchanged — and the team can name all four consumers. ADDITIVE.
C-03
A new value added to account.tier. Identical answers to all three questions — and nobody can list who reads that field. SILENT BREAK.
Additive is a claim about everybody, not about the change
“Nothing downstream reads differently” is only true if you know what downstream is. If you cannot list the consumers by name you are asserting something you have not checked, and an unnoticed meaning change is precisely what a silent break is — so the verdict says so. The gate only ever touches a change that would otherwise read ADDITIVE: it cannot make a loud break louder, and the verifier proves it across the whole truth table.
03
Answer the four questions and watch the verdict move
Start on C-03. Tick the last box and it becomes additive; untick it and it does not.
C-03 · account.tier · add_enum_value
Add 'trial_expired' to account.tier
SILENT BREAK
nothing downstream reads differently. It reads ADDITIVE on the answers — but additive is a claim about every consumer, and the consumers were not listed.
Release verdict
SILENT BREAKS PRESENT
2 additive · 2 breaking · 3 silent, of 7. 29% additive — context only. 32 named consumers sit behind the changes that are not additive. Fix first: C-05.
A breaking change is work. A silent break is wrong answers. Same arithmetic as the shipped engine and workbook; it grades changes, never people.
04
What the engine prints
This is the shipped engine’s complete output on the shipped release.
ONTOLOGY CHANGE-IMPACT TRIPWIRE
==========================================================================
C-01 Add 'partially_paid' to invoice.state
invoice.state (add_enum_value) SILENT BREAK
data validates: yes consumers run: yes meaning moved: yes
consumers listed: yes (6 named)
everything still runs and the meaning moved
C-02 Add 'archived' to project.status with a default branch added everywhere
project.status (add_enum_value) ADDITIVE
data validates: yes consumers run: yes meaning moved: no
consumers listed: yes (4 named)
nothing downstream reads differently
C-03 Add 'trial_expired' to account.tier
account.tier (add_enum_value) SILENT BREAK
data validates: yes consumers run: yes meaning moved: no
consumers listed: no (0 named)
nothing downstream reads differently
[GATE] reads ADDITIVE on the answers - additive is a claim about every consumer, and the consumers were not listed
C-04 Require tax_id on supplier records
supplier.tax_id (add_required_field) BREAKING
data validates: no consumers run: yes meaning moved: no
consumers listed: yes (9 named)
existing records no longer validate
C-05 An employee may now have more than one manager
employee.manager (widen_cardinality) SILENT BREAK
data validates: yes consumers run: yes meaning moved: yes
consumers listed: yes (12 named)
everything still runs and the meaning moved
C-06 Add Contractor as a new entity type
Contractor (add_type) ADDITIVE
data validates: yes consumers run: yes meaning moved: no
consumers listed: yes (3 named)
nothing downstream reads differently
C-07 Withdraw legacy_code from order records
order.legacy_code (remove_property) BREAKING
data validates: yes consumers run: no meaning moved: no
consumers listed: yes (5 named)
a downstream consumer stops running
--------------------------------------------------------------------------
RELEASE VERDICT: SILENT BREAKS PRESENT
2 additive / 2 breaking / 3 silent (of 7 changes)
29% additive -- context only, it decides nothing
1 change(s) have no listed consumers; 32 named consumers sit behind the changes that are not additive
fix first: C-05
A breaking change is work. A silent break is wrong answers.
Grades the changes you describe. Not legal or compliance advice.C-02 and C-03 are the pair worth reading twice. Both add a value to an enum, both validate, both leave consumers running — and one reads ADDITIVE while the other reads SILENT BREAK, because C-03’s consumers were never named. Note also C-05, the fix-first pick: the same silent-break shape as C-01, but with twelve named consumers behind it instead of six, which is what breaks the tie.
05
What is inside
Six files, all editable, none requiring an account.
Tripwire engine
Zero-dependency Python. Applies the truth table in the order it short-circuits, prints why each change landed where it did, and rolls up to a release verdict. No network access.
Workbook that reproduces it
Three tabs and 59 live formulas, with the pre-gate verdict in its own column so you can see what the answers said before the evidence question was asked. No macros.
Change-Review Playbook
How to run this in the twenty minutes before a schema change merges, and the six change types that come back SILENT BREAK most often.
Silent-Break Runbook
What each verdict means, how to turn a silent break into a loud one on purpose, and why that is usually the cheapest fix available.
Worked 7-change release
Including the evidence twin and both classic silent breaks: a new enum value and a widened cardinality.
Editable change types
Eleven named change types in a JSON file you own, with the one self-contradictory combination the engine refuses to accept.
06
Who it is for, and what it will not do
It is for whoever will be asked, in three months, why the numbers changed.
Built for
- Anyone about to add a value to a status field that a dozen things branch on.
- Teams whose migrations pass every test and still produce different numbers afterwards.
- Reviewers who need twenty minutes and a defensible reason to send a schema change back.
It will not
- Read your schema or diff your files. You describe the change in four answers; it applies the same rule every time.
- Find your consumers for you. If the fourth question is hard, that difficulty is the finding.
- Tell you a change is wrong. SILENT BREAK means it will not announce itself — shipping it anyway is a decision you can make deliberately.
- Replace a migration plan. It tells you which changes need one, in an order that makes sense.
This System grades the changes you describe. It is a working aid, not legal or compliance advice, and it is not an audit or a certification. It never scores, ranks, or assesses people. It reads no schema and diffs no files — ADDITIVE means your four answers said so, not that nothing downstream will notice.
07
What sits either side of it
Three neighbours that deal with the loud failures this one is not about.
CSV / Data-Export Schema & Quality Gate
$69
Whether an export still parses and lines up after a change. Loud failures show up there; this is about the quiet ones.
Multi-Source Data Reconciliation Engine
$89
When systems disagree about the same record. A silent break shipped last quarter is a common reason they started to.
Document Field Validator
$79
Enforces field rules on records as they arrive. Useful once a change has landed and you need the new rule applied.
08
Questions people actually ask
Short answers first, with the caveat after it rather than in front of it.
Because a breaking change stops. Somebody sees an error, files a ticket, and the wrong thing does not ship — it is expensive and it is loud, and loud is a feature. A silent break is the one where everything still validates, every consumer still runs, and the answer quietly means something else. Nothing fails; reports just start being wrong. Ranked by what it costs you to have missed it, that is the right order.
Add a value to a closed set and the old else-branch swallows it — no error, and a category of records silently reclassified. Widen a cardinality from one to many and the code reading the first element keeps working while dropping the rest — no error, and a report that undercounts. Both are in the shipped sample, and neither would show up in a test suite that only checks nothing crashed.
Because calling a change additive is a claim about everyone who reads the thing you are changing. If you cannot list them by name, you are asserting something you have not checked — and an unnoticed meaning change is precisely what a silent break is. The shipped sample has two changes with identical answers to the first three questions and different verdicts for this reason alone. It only applies to changes that would otherwise read ADDITIVE; it cannot make a loud break louder.
Never. The release takes the worst change. Nine additive changes and one silent break is 90% additive and still reads SILENT BREAKS PRESENT, because the question is not what proportion is fine. The share is printed for context and labelled as such in the engine, the workbook and the demo.
No. It reads no schema, diffs nothing, and calls no consumer. You answer four questions per proposed change and it applies the same rule every time — which is what makes two runs a quarter apart directly comparable, and is also the boundary of what it can tell you. There is no evaluation date anywhere in the product.
That survey asks whether your domain is written down at all. This asks what happens the next time you change it. A closed value set graded there is exactly the kind of thing whose next new value shows up here as a silent break — and if the survey said you have no declared consumers or identity rules, the fourth question here will usually answer itself. It grades changes, never people, and is a working aid rather than legal or compliance advice.
Find the change that will not announce itself.
Four questions, one truth table, and a ranking that puts the loud failure where it belongs. Deterministic, offline, and clear that additive is a claim about everyone who reads the thing you changed.
This System grades the changes you describe. A working aid, not legal or compliance advice. It reads no schema, and it never scores or ranks people.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai