The Default Ledger
Who set the defaults everyone else has to live inside?
One row per default in force. The machine can describe what each one does. It can't tell you whose name is on it.
The decision it forces
Somewhere in your organisation there's a setting that decides what an AI system is allowed to do without asking. A permission level, a retention window, an auto-send threshold, a model choice, a context that gets attached to every request.
Somebody chose it. Probably early, probably quickly, probably someone who was comfortable with the tool before anyone else was. Or nobody here chose it at all: the vendor shipped it that way and nobody changed it. Everyone since has inherited it.
The question this page asks is not whether that setting is right. It's whether anyone can name who made it, and whether anyone downstream knows they're allowed to change it.
To run it, copy the prompt below into any model you already use.
Why a default is different here
In ordinary software a default is a setting. It has a value, the value is right or wrong, and if it's wrong you notice because the thing does the wrong thing every time, predictably, for everyone.
A default in front of a non-deterministic system isn't a setting. It's a posture toward variable output: a standing decision about how much strangeness the organisation will absorb without a person in the loop. The person who set it was calibrating against their own tolerance, and theirs was unusually high, because they were the one who went first.
That's the transfer that doesn't survive. The instinct that made the setting safe stayed with the person who had it. The setting went everywhere.
The fields
One row per default currently in force. The left half is what a machine can tell you. The right half is what it can't.
| Column | What goes in it | Who fills it |
|---|---|---|
surface |
The system, tool or integration the default sits on | machine, or you |
default |
What it does when nobody intervenes, in plain words | machine, or you |
set_on |
When it was set, as precisely as the record allows | machine, or you |
origin |
vendor_default if it still has the value it shipped with, changed_here if someone here changed it, unknown if the record can't say |
machine, or you |
set_by |
The name of the person who chose it, or who deliberately kept the vendor's value. A team name is a blank, and so is a vendor | you, and only you |
can_change |
The name of someone who can change it today, and whether they know they can | you, and only you |
tolerance_assumed |
What the person who set it could absorb that the people living with it cannot. Empty on a vendor default nobody here chose to keep, because nobody here calibrated it | you, and only you |
if_never_touched |
What happens if nobody ever revisits it | you |
The verdict rule
A row with an empty set_by is the finding, not an incomplete row.
Don't fill it with a team, a function, a job title or "IT". If the honest answer is that nobody knows who chose it, write nothing and leave the box empty, because an empty box is a true statement about your organisation and "Platform team" is not.
A vendor is a blank for the same reason a team is: no person here answers for the choice. That's what origin is for. A row reading vendor_default with an empty set_by isn't a lost name. It's a default nobody in the organisation ever decided on, accepted by silence, and it's a different finding from a colleague whose name has been forgotten. Leave tolerance_assumed empty on those rows too. The vendor calibrated for a generic customer, not for anyone who works here.
The same goes for can_change. A name belongs there only if that person would recognise the claim. If they'd be surprised to learn it was theirs to change, the box is empty and the surprise is the point.
Expect most ledgers to come back with more blanks than names in those two columns. That's what this looks like when it's working.
Run it with any model
This interviews and enumerates. It may never put a name in a box.
Help me build a Default Ledger: one row per AI default currently in force in my organisation, so I can see which ones nobody can account for. WHAT YOU DO Help me enumerate the surfaces and describe what each default does. If I give you configuration exports, admin screenshots, policy documents or a tool inventory, read them and draft the surface, default, set_on, origin and if_never_touched columns from what is actually in them, showing me where each one came from. WHAT YOU NEVER DO 1. Never fill set_by, can_change or tolerance_assumed. Not from a document, not from an org chart, not from an inference, not from a plausible guess. Those three columns are the whole point of the ledger and a name you supply is worse than a blank, because a blank is honest. 2. Never substitute a team, a function, a job title, a role, a department, a vendor or a system for a person's name in those columns. If I answer set_by with "the platform team", tell me that is a blank and ask me once for a person. If I do not have one, record null. 3. Never tell me a default is safe, risky, sensible or wrong. This ledger records who decided, not whether they decided well. 4. Never suggest what a default should be changed to. Changing them is not this page. 5. Do not ask for credentials, API keys, customer data or the contents of any system. Names of surfaces and descriptions of behaviour are enough. INTERVIEW ME, one surface at a time, three questions at a time at most. For each row ask: surface, then default in plain words, then set_on. Then origin: vendor_default if it still has the value it shipped with, changed_here if someone here changed it, unknown if neither of us can tell. Then ask set_by, and ask it as "whose name is on this one?" rather than "who owns this?", because ownership gets answered with a team and a name does not. On a vendor_default row, a name belongs in set_by only if that person deliberately chose to keep the vendor's value. Then can_change, and ask whether that person knows they can. Then tolerance_assumed: what could the person who set this absorb that the people living with it cannot. If the row is vendor_default and set_by is null, do not ask: record null and tell me nobody here calibrated it. Then if_never_touched. OUTPUT Valid JSON matching the schema default-ledger/v0.2 as published at https://sigsub.show/takeaways/default-ledger/, then the ledger as a table with the empty cells visibly empty rather than filled with dashes or placeholders, then four counts: rows in total, rows with no named setter, rows with no named changer, and rows accepted by silence (origin vendor_default with no named setter). End with two plain sentences, the count of rows with no named setter and then the count accepted by silence, and nothing after them.
What to check in the answer
It can enumerate surfaces, read configuration, date a change from a log, tell whether a setting still has the value it shipped with, and describe what a setting does when left alone. That work is tedious, mechanical, and better done by something that doesn't get bored.
It may never name the person. Not set_by, not can_change, not tolerance_assumed. A model asked for those will produce a team, a role or a confident guess, and every one of those turns a real gap into a filled cell that nobody has to answer for. The ledger exists to surface the gap. A machine that closes it has undone the page.
The part that's not optional
Start with the defaults that are furthest from the person who set them. Not the newest, and not the ones you're proudest of: the ones running in a part of the business that has never met the person who chose the setting.
Then take the finished ledger to whoever's name appears most often in set_by, and ask them whether they meant to be making decisions for that many people. They almost certainly didn't. Nobody voted on it, and that's the ordinary way this happens rather than anyone's fault.
If the most common entry in set_by is nothing at all, and most of those rows read vendor_default, you've found something else. Nobody here set those defaults and nobody here chose to keep them. The vendor decided how much the system does without asking, and the organisation agreed by saying nothing.
That's where this page stops. The ledger finds the blanks; it doesn't say what should sit behind them. For that, Markus Bernhardt's The Decisions Your AI Is Making Without You is the deeper dive: who holds authority over which kinds of decision, what an approval actually sanctions, who can stop a system in the middle of what it's doing, and why a court or regulator deciding whether you're the deployer will ask for exactly the record an empty column says you don't have. It's his own writing, published on his own site at Endeavor Intelligence in May 2026, and it goes where this page deliberately doesn't.
There's no worked example on this page. A filled ledger names real systems and real people inside one organisation, and it belongs to them.
For builders
The answer format
{
"schema": "default-ledger/v0.2",
"organisation_scope": "",
"defaults": [
{
"surface": "",
"default": "",
"set_on": null,
"origin": "unknown",
"set_by": null,
"can_change": null,
"tolerance_assumed": null,
"if_never_touched": ""
}
],
"totals": {
"rows": 0,
"unnamed_setter": 0,
"unnamed_changer": 0,
"accepted_by_silence": 0
}
}
set_by, can_change and tolerance_assumed are null rather than empty strings when nobody can fill them, so a count of nulls is a real number rather than a formatting accident. origin is one of vendor_default, changed_here or unknown, and accepted_by_silence counts the rows that read vendor_default with set_by still null. v0.2 added both; v0.1 had no way to tell a vendor's default from a forgotten colleague's.
Report back
Ran this? Tell us what happened. What broke and what you changed are the useful parts, because that's how the next version gets better.
Or write to hey@sigsub.show with Takeaway: default-ledger as the subject. It's a plain email: no form, no account, nothing tracked. Nothing you send appears here unless you say yes, and you choose how you're named.
Rather talk it through in public? Comment on the Sunday issue on Substack, the same issue on LinkedIn or the episode on YouTube. Those threads live on their platforms, under their rules; nothing from them runs on this page.