How to calculate it

The mechanics: scoring against captured state, the mint rule, the all-in cost model, and unit metrics, with worked arithmetic.

Snapshot before, snapshot after, score against weighted checks, mint against the budget, meter everything. Every number an operator needs falls out of one ledger.

Scoring: how completion is computed

A unit of work is a triple:

u = (S₀, G, B)

S₀  the snapshot of world state when the unit is created
G   the definition of done: weighted checks {(g₁,w₁), …, (gₙ,wₙ)}
B   the budget: what reaching the end state is worth, set by the owner

When the agent reports done, the environment captures the after-snapshot S₁ and computes:

         Σᵢ wᵢ · gᵢ(S₁)
V(u) = ─────────────────  ∈ [0, 1]      completion score
            Σᵢ wᵢ

done(u) = V(u) ≥ τ                      acceptance, typically τ = 1

Every check runs against S₁, the state the environment captured, never the agent's account of what it did. The score is a property of the world, not of a report.

Snapshot S₀

Agent executes

Snapshot S₁

Score V = Σwᵢ·gᵢ(S₁)

status = closedw = 0.5

reply sentw = 0.3

KB article linkedw = 0.2

V = 0.5 + 0.3 + 0 = 0.8 → below τ = 1.0, one check left to fixsettle when V ≥ τ : compare budget B against metered cost C

Worked (above): three checks, the after-snapshot passes the first two: V = 0.8. Under atomic settlement nothing mints until the third flips; under divisible settlement the unit mints 0.8 · B now.

The mint

Q(u) = V(u) · B(u)              divisible settlement (pay per delivered share)
Q(u) = B(u) · [V(u) ≥ τ]        atomic settlement (all or nothing)

The owner declares the regime at creation: atomic when partial completion is worthless (a half-merged change), divisible when it is not (four of five report sections). quirqs inherit the budget's currency, so quirq totals compare directly to payroll, vendor spend, and revenue.

The all-in cost of an outcome

The token bill is one line of the true cost. The environment meters all of them:

C_total(u) =  Σ tokensₘ · priceₘ           inference, per model
           +  t_cpu·r_cpu + t_gpu·r_gpu    metered compute
           +  Σ calls_j · price_j          external API calls
           +  storage · r_store            storage
           +  F / N_units                  environment amortization
           +  h · r_human                  human intervention time

The last term matters most and is most often omitted: a program whose outputs each require twenty minutes of senior review pays its largest cost in a currency the token bill never sees. Under quirq accounting it cannot hide, because interventions are exactly the V < τ events the scoring rule already counts.

Worked: the ticket above, resolved with 38k tokens at $2/M plus 4k at $0.25/M (inference $0.077), 90 CPU-seconds ($0.001), two CRM calls ($0.02), amortization ($0.03), no intervention: C_total = $0.128.

Unit metrics

cost per quirq   c_q = C_total / Q         price of a dollar of verified work
quirq margin     μ   = Q − C_total         surplus on the unit
multiple         x   = Q / C_total         the reciprocal view

Worked: at B = $4.00 and V = 1.0: Q = 4.00, c_q = 0.032, margin $3.87, multiple 31x. Had it settled divisibly at V = 0.8: Q = 3.2 and c_q = 0.040. Incomplete work is automatically more expensive per quirq: the incentive points the right way.

Collecting it in an organization

The same ledger supports two collection cadences, and they are not exclusive: most organizations will start with one and grow into both.

Quarterly, as a planning KPI

Each team declares its unit types and budgets at quarter start
Minted quirqs, QER, and intervention rate roll up per team
quirq targets sit beside OKRs in quarterly planning
The trend, not the level, is what leadership reads

Per work item, on smaller teams

Every ticket or work item is linked to a unit of work
The tracker field carries the budget and the checks
Minting happens at ticket close, settlement is continuous
The ledger is just the tracker, instrumented

The quarterly mode needs almost no tooling: a team that already writes OKRs declares what its recurring outcomes are worth, meters its AI spend against them, and reviews the ratio at planning time. The per-item mode is where the numbers get sharp: when every ticket carries its budget and checks, the intervention rate decomposes to the exact check that fails, and cost per quirq becomes a live number rather than a quarterly reconstruction. Small teams can run per-item from day one; large organizations typically pilot per-item on one team and report quarterly everywhere else.

A relative instrument, not an absolute one

One property of the unit must be understood before any number is quoted: quirqs are only meaningful against relative history.

A single reading, one unit, one worker, one moment, tells you almost nothing: budgets are owner-relative, task mixes differ, and a hard quarter is not a bad quarter. The instrument is built for collective performance over time: the same team, the same environment, the same unit types, read as a trajectory. Without a time window, a quirq total is not very relevant; with one, the trend of QER and the intervention rate is the most honest signal an AI program has.

Three consequences follow. Do not rank individuals by quirqs: the unit prices outcomes, not people, and an individual's mix of hard and easy units makes absolute comparison meaningless. Do not compare raw totals across companies: budgets encode each owner's economics; only dimensionless ratios (QER, IR) and their trends travel. And always quote the window: "12,400 quirqs" is noise; "QER 3.1 to 5.6 over the quarter, intervention down a third" is a measurement.

The mechanics in hand, see them at work on real unit types: real world use cases.