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.

Shipped with Episode 13

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.

The Default Ledger's filled panel: three surfaces a machine listed, support inbox, doc assistant and review bot, with the set-by and can-change boxes left empty for a human, and the stamp reads unnamed, 6 of 6.

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.

Copy-paste prompt
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
{
  "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.

Email your report

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.