The Default Ledger

Watch the two-minute walkthrough 2:19

A two-minute walkthrough: why nobody can say who set the AI defaults everyone lives inside, the ledger's columns, the verdict, and how to run the prompt in any model.

Play video

The decision it forces

Who set the defaults everyone else has to live inside? Somewhere in every 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.

if_never_touched and fires_when don't change the verdict; they say which blank to chase first. There's no worked example on this page: a filled ledger names real systems and real people inside one organisation.

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.

A default with a clock on it

Some defaults don't only sit there; they act. Sam built one on purpose, on Episode 11: a decision system in which pre-made choices fired unless he stepped in, like lit fuses. It worked until a family emergency took him away for a week and the defaults kept firing on decisions made for circumstances that no longer held. There was no safety mechanism, because he hadn't built one.

That's the row to chase first: fires_when filled and set_by empty. A fuse was set for the day it was lit, and it fires on whatever day the trigger arrives. When nobody can name who lit it, nobody is placed to notice the day has changed.

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, fires_when, 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 fires_when: does it
act on its own after a time or a trigger unless someone stops it, and if so,
what is the trigger? Record null if it only sits there. 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.3 as published at
https://sigsub.show/takeaways/default-ledger/#the-answer-format. If you can't
read that page, use these keys, in this order: schema, organisation_scope;
defaults, a list, each with surface, default, set_on, origin, set_by,
can_change, tolerance_assumed, if_never_touched and fires_when; totals, with
rows, unnamed_setter, unnamed_changer, accepted_by_silence and unnamed_fuses.
Then the ledger as a table with the empty cells visibly empty rather than filled
with dashes or placeholders, then five counts: rows in total, rows with no named
setter, rows with no named changer, rows accepted by silence (origin
vendor_default with no named setter), and unnamed fuses (fires_when filled with
no named setter). Then list the unnamed fuses by name, first. 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.

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, on his own site.

{
  "schema": "default-ledger/v0.3",
  "organisation_scope": "",
  "defaults": [
    {
      "surface": "",
      "default": "",
      "set_on": null,
      "origin": "unknown",
      "set_by": null,
      "can_change": null,
      "tolerance_assumed": null,
      "if_never_touched": "",
      "fires_when": null
    }
  ],
  "totals": {
    "rows": 0,
    "unnamed_setter": 0,
    "unnamed_changer": 0,
    "accepted_by_silence": 0,
    "unnamed_fuses": 0
  }
}