Skip to content

Spend that cannot be tied to anything accepted

Consumption is measured per account and outcomes are recorded per person, so the two can never be joined.

→ looked at the bill and could not say which of it produced anything

cost when it happens
medium
how often
common
area
cost
observability
recognised by
enterprise
engineering-lead
research-team
agency

The moment

The monthly figure is large and growing. The question is not whether it is worth it — it probably is — but which part of it was. There is no way to answer, because consumption is measured per account and outcomes live in people's heads.

Why it happens

The two halves of the ratio are recorded by different systems with no shared key. Consumption belongs to a provider account; acceptance belongs to a review conversation. The unit that would join them — a piece of work, with an identity, a cost and an outcome — does not exist anywhere.

Why a better model does not fix it

A cheaper or better model changes the numerator and leaves the join missing. The question "was this worth it" stays unanswerable however good the workers get.

What it costs

Budget decisions made on anecdote, in both directions: over-spending that nobody can challenge, and cuts that fall on the work that was actually paying for itself.

What Majordomus does

The accepted side of the ratio becomes real first. Work is a task with an identity computed from git; finishing it records a typed outcome, the verification command that ran, its exit code and its duration. An execution episode records when it opened and closed and what happened under it. history reads back what was started, handed over and accepted, so the denominator of any cost question is a count rather than an impression.

Attaching consumption itself to those units is on the roadmap and is not claimed today; the claims matrix carries it as planned, with no implementation and no test, rather than as a capability.

Before and after

before   invoice: one number.      accepted work: an anecdote.

after    $ majordomus history --since 30d --event task_finished --json | \
             jq -r '.outcome' | sort | uniq -c
           41 completed
           18 partial
            7 failed

What it does not do

It does not measure tokens, money or model consumption, and it does not integrate with a provider's billing. It makes the outcome side countable, which is the side that was missing in every environment this tool came from.

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. A number with no denominator enterprise

    before
    The invoice is a single figure; the value it bought is asserted in a slide.
    after
    Outcomes are typed events with verification attached, so the accepted side of the ratio is at least a real count.

  2. Eighty attempts, nine merges research-team

    before
    Cost is attributed to the attempts; nothing records that most of them were never integrated.
    after
    Started, handed over and finished-with-an-outcome are distinct events, so the gap is visible without an interview.

  3. Attributing to a client agency

    before
    Consumption cannot be split by engagement, so it is allocated by headcount and argued about.
    after
    Work is attached to tasks, and tasks to scopes and repositories; the allocation has a basis.

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.

  • Consumption is known per account or per month and not per piece of work. bill-by-account
  • Nobody can say what fraction of what was produced was actually accepted. no-accepted-denominator
  • Justifying the spend means telling a story rather than showing a ratio. justify-the-spend

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

  • majordomus.verify-outcomes
  • majordomus.ledger-integrity
  • majordomus.session-records
  • project.performance-evidence

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 →