Skip to content

A change whose provenance cannot be reconstructed

Attribution stops at the commit, so what authorised a change, what verified it and what governed it are unrecoverable.

→ was asked who made a change and under what policy, and had only a commit

cost when it happens
high
how often
common
area
observability
governance
recognised by
enterprise
agency
engineering-lead
platform-team

The moment

"Who made this change, what authorised it, and what verified it?" The available answer is a commit with a human author, a message written by a worker, and a merged pull request with one approval. None of those is the answer to any of the three questions.

Why it happens

Git records authorship of a patch, which was a good proxy while a person typed every line. It is no longer: the author field records who ran the worker, and everything else that matters — the objective, the boundary, the policy in force, the verification that ran — is either in a conversation or nowhere.

Why a better model does not fix it

There is no inference that recovers what was never recorded. Asking a model to reconstruct provenance from a diff produces a plausible story, which in an audit is worse than nothing.

What it costs

In a regulated setting, the ability to demonstrate a control at all. Everywhere else, the ability to answer the most common question in incident review: what did we think we were doing, and what checked it.

What Majordomus does

Identity fields are computed from git and never authored: a record that names a branch, a head, a working tree or a set of changed files had those values computed at the moment it was written, and a worker supplying them is an error rather than an override. A commit carries the task that produced it. The task carries its objective, its declared scope and the profile it ran under. The ledger carries the events — started, checkpointed, decided, handed over, finished with a typed outcome, and the verification command with its exit code and duration. The generated instruction files carry the hash of the policy that produced them, so which rules were in force is a tracked fact.

Before and after

before   commit 8c31f0e  "fix auth"  author: a person

after    $ majordomus history --task t-20260903193012-a4f1
         task_started   objective="split the callback validation" profile=implementation
                        scope=lib/auth,test/auth  head=1f0a3c2
         decision       "normalise before comparing"  why=...  rejected=...
         task_finished  outcome=completed  verify="make test" exit=0 1m12s  head=8c31f0e

What it does not do

It does not identify which model or vendor produced a change, and it does not sign anything. It records what this repository decided, bounded, ran and accepted, with the identity fields computed rather than asserted.

What this looks like

Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.

  1. Six months later enterprise

    before
    An auditor asks what authorised a change and what verified it; the artefacts are a commit and a merged pull request.
    after
    The commit carries its task; the task carries the objective, the scope, the profile and the outcome; the ledger carries the verification that ran.

  2. The client asks what was done and why agency

    before
    Reconstructing an engagement means reading diffs and remembering conversations.
    after
    The events are structured and readable back per task, with the decisions and questions that governed them.

  3. Which rules were in force platform-team

    before
    The rules changed twice during the project and nothing records which version any change was made under.
    after
    The projections carry the policy hash they were generated from, and the policy is a tracked file with a history.

How you would know

The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.

  • The whole record of a change is its commit message. only-a-commit
  • Nobody can say which version of the rules was in force when a change was made. which-policy-applied
  • Work produced by a worker is attributed to whoever pressed the button. human-author-machine-work

Where this lives in the tool

Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.

the commands that answer it

the capabilities of the executable that answer it

what it supervises — derived from the claims below

the claims that back this page, and the evidence behind each

the rules that govern it

  • project.never-author-identity
  • majordomus.ledger-integrity
  • majordomus.session-records
  • majordomus.projection-integrity

the use cases that show the way out

If this one is familiar, so is the next

What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.

All 38, and how they connect to the tool →