The Default Ledger

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. 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.

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 ledger

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.

The 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.

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.

The schema

{
  "schema": "default-ledger/v0.1",
  "organisation_scope": "",
  "defaults": [
    {
      "surface": "",
      "default": "",
      "set_on": null,
      "set_by": null,
      "can_change": null,
      "tolerance_assumed": null,
      "if_never_touched": ""
    }
  ],
  "totals": {
    "rows": 0,
    "unnamed_setter": 0,
    "unnamed_changer": 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.

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 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 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 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. 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. Then if_never_touched.

OUTPUT
Valid JSON matching the schema default-ledger/v0.1 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 three
counts: rows in total, rows with no named setter, rows with no named changer. End with that second count as a plain
sentence and nothing after it.

What a machine may never do

It can enumerate surfaces, read configuration, date a change from a log 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.

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.