Rebound Accounting v0.1 — induced volume and total cost per accepted governed outcome

[hummbl-dev]

Parent research ledger

• https://github.com/hummbl-dev/hummbl-research/issues/70

Related routing work

• Runtime versus model boundary: Scope decision: agent-runtime selection versus model routing #7
• Whole-codebase and corpus routing policy: Whole-codebase and corpus model routing policy v0.1 #8
• Reasoning Budget Policy v0.1: Reasoning Budget Policy v0.1 — governed inference-time compute, verification, and stopping conditions #19
• Model Market & Routing Control Plane umbrella: HUMMBL Model Market & Routing Control Plane v0.1 — cross-repo implementation plan hummbl-dev#156

Status

SPEC_ONLY_IMPLEMENTATION_REQUIRED — RECEIPT EXTENSION — NO DEFAULT ROUTE CHANGE AUTHORIZED

Objective

Define rebound_accounting.v0.1 as a vendor-neutral extension to route-decision, benchmark, and execution receipts so that a lower unit cost is not mistaken for lower total system cost or higher delivered value.

The policy should measure whether efficiency induces additional volume, coordination, verification, maintenance, risk, or resource consumption and should preserve the distinction between:

• unit efficiency;
• ordinary rebound below 100%;
• strict rebound above 100% for a declared resource;
• resource substitution;
• hidden downstream burden;
• inconclusive or non-comparable evidence.

Governing doctrine

An efficiency gain remains provisional until induced volume, downstream load, total resource consumption, quality, and delivered value are measured.

Cheapest correct model wins means lowest total cost per accepted governed outcome after correctness, safety, privacy, authority, latency, reliability, reproducibility, and governance gates pass. It does not mean lowest listed price, lowest token count, or lowest cost per invocation.

Candidate contract

rebound_accounting:
  version: v0.1
  subject_ref: ""
  baseline_period: ""
  observation_period: ""
  unit_of_work: ""
  accepted_outcome_definition: ""

  demand:
    baseline_volume: 0
    observed_volume: 0
    induced_volume_estimate: 0
    demand_change_explanation: ""

  resources:
    dollars:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null
    tokens:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null
    compute_seconds:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null
    energy_kwh:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null
    wall_clock_seconds:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null
    human_review_minutes:
      baseline_per_unit: null
      observed_per_unit: null
      baseline_total: null
      observed_total: null

  downstream:
    coordination_minutes_delta: null
    queue_depth_delta: null
    retry_delta: null
    maintenance_liability_delta: null
    defect_or_incident_exposure_delta: null
    unresolved_output_delta: null

  quality_and_value:
    acceptance_rate_baseline: null
    acceptance_rate_observed: null
    rework_rate_baseline: null
    rework_rate_observed: null
    delivered_value_metric: ""
    delivered_value_baseline: null
    delivered_value_observed: null

  stratification:
    task_class: []
    complexity: []
    risk_tier: []
    route: []
    repository: []
    tool_surface: []
    retry_count: []

  disposition_by_resource:
    dollars: unit_gain_total_gain|rebound_below_100|strict_rebound|resource_substitution|inconclusive
    tokens: unit_gain_total_gain|rebound_below_100|strict_rebound|resource_substitution|inconclusive
    compute_seconds: unit_gain_total_gain|rebound_below_100|strict_rebound|resource_substitution|inconclusive
    human_review_minutes: unit_gain_total_gain|rebound_below_100|strict_rebound|resource_substitution|inconclusive

  overall_disposition: promoted|promoted_with_scope|hold|reject|needs_evidence
  stop_or_circuit_breaker: ""
  reviewer_independence: ""
  evidence_refs: []
  receipt_ref: ""

The exact schema may change after repository inspection. The accounting distinctions and claim-honesty boundaries must survive.

Required calculations

For each declared resource s, calculate or preserve enough evidence to derive:

baseline_total_s = baseline_volume × baseline_per_unit_s
observed_total_s = observed_volume × observed_per_unit_s
unit_efficiency_ratio_s = baseline_per_unit_s / observed_per_unit_s
volume_ratio = observed_volume / baseline_volume

Candidate classification:

observed_per_unit_s >= baseline_per_unit_s
  => no demonstrated unit efficiency gain

observed_per_unit_s < baseline_per_unit_s
and observed_total_s < baseline_total_s
  => unit gain with total-resource gain

observed_per_unit_s < baseline_per_unit_s
and observed_total_s < baseline_total_s
and savings are partially consumed by added volume
  => rebound below 100%

observed_per_unit_s < baseline_per_unit_s
and observed_total_s > baseline_total_s
  => strict rebound for resource s

The validator must not classify causal Jevons behavior from arithmetic alone. Arithmetic can identify a rebound-shaped observation; causal attribution requires evidence about induced demand and confounders.

Required design questions

• What constitutes a comparable unit of work across models, runtimes, and scaffolds?
• How is an accepted governed outcome defined so that cheap rejected output does not look efficient?
• Which resource fields are required versus optional for each route class?
• How are shared infrastructure and fixed costs allocated?
• How are cached tokens, speculative decoding, batch inference, local hardware amortization, and free promotional usage represented?
• How is human review measured when work occurs concurrently or asynchronously?
• How are downstream coordination, maintenance, and incident exposure estimated without fabricating precision?
• How does the receipt distinguish observed correlation from demand induced by the efficiency gain?
• How does the Reasoning Budget Policy feed into rebound accounting without duplicating its source of truth?
• How are Simpson reversals detected when aggregate cost improves but every material task class regresses?
• How does risk compensation alter route scope after new controls are introduced?

Required fixtures

Valid

1. Unit cost falls and total consumption falls despite moderate volume growth.
2. Unit cost falls, volume rises, and total token or compute use rises: strict rebound for that resource.
3. Token cost falls while human-review time rises: resource substitution.
4. Higher reasoning spend increases acceptance enough to lower total cost per accepted governed outcome.
5. Local/free route lowers dollar cost but increases latency and maintenance liability; promotion remains scoped.
6. Aggregate cost improves while disaggregated high-risk tasks regress; Simpson flag prevents universal promotion.

Invalid or adversarial

1. Missing baseline volume.
2. Changed unit-of-work definition between periods.
3. Total cost calculated only on successful runs while retries are excluded.
4. Human review omitted despite a required human gate.
5. Free-tier price recorded as durable zero cost without expiry or capacity limits.
6. Quality metric improved by weakening tests or acceptance criteria.
7. Strict rebound claimed without specifying the resource.
8. Jevons causality claimed from arithmetic without induced-demand evidence.
9. Route promoted on aggregate savings with no meaningful stratification.
10. Safety controls used to justify wider authority without a separate promotion decision.

Required artifacts

1. Versioned schema or compatible extension contract.
2. Human-readable accounting specification.
3. Deterministic calculator or validator for arithmetic and structural invariants.
4. Valid, invalid, adversarial, and Simpson-reversal fixtures.
5. Crosswalk to route-decision, benchmark, execution, reasoning-budget, and accepted-outcome receipts.
6. Example reports for hosted frontier, local/open-weight, hybrid escalation, and scheduled-task lanes.
7. Benchmark protocol comparing per-invocation cost with total cost per accepted governed outcome.
8. Migration plan that avoids duplicating existing economics or observability fields.
9. Independent review and execution receipt.

Promotion and stop conditions

A route should not receive broad promotion when any of the following remains material and unresolved:

• unit savings are offset by increased rejected output or retry volume;
• review queues grow beyond declared service levels;
• coordination or maintenance burden becomes the dominant cost;
• quality or safety declines in a material stratum;
• total cost per accepted governed outcome rises;
• the accounting window is too short to observe maintenance or incident effects;
• the baseline, unit of work, or demand counterfactual is not comparable;
• a control change triggers unreviewed scope or authority expansion.

Non-goals

• No claim that all efficiency improvements produce rebound.
• No requirement to fabricate energy or carbon estimates when provider data is unavailable.
• No universal weighting that collapses dollars, time, energy, quality, and risk into one invented score.
• No production route, paid fallback, budget, or authority mutation.
• No canonical adoption of Agentic Rebound Effect or Generation–Coordination Rebound.

Acceptance criteria

• Contract distinguishes unit efficiency, induced volume, total consumption, downstream burden, and delivered value.
• Disposition is resource-specific and cannot label an unspecified aggregate as strict rebound.
• Total cost per accepted governed outcome includes retries, review, and required verification.
• Structural and arithmetic validation is deterministic.
• Fixtures cover total savings, partial rebound, strict rebound, resource substitution, Goodhart gaming, Simpson reversal, and risk compensation.
• Causal claims require evidence beyond arithmetic.
• Existing route, benchmark, reasoning-budget, observability, and receipt authorities are crosswalked rather than duplicated.
• Independent review and an execution receipt are attached.
• Findings and implementation links are returned to hummbl-research#70.
• No fleet default or production route changes without separate Reuben approval and a transition receipt.

[hummbl-dev]

Operator approval receipt — 2026-07-11

Reuben approved the recommendations and this bounded implementation lane.

Approved scope: repository inspection, receipt-authority crosswalk, candidate schema/specification, deterministic arithmetic and structural validation, valid/invalid/adversarial fixtures, representative benchmark protocol, independent review, and receipts.

Still separately gated: production/default route changes, paid fallback or budget expansion, authority changes, universal cost weighting, causal Jevons claims without evidence, and canonical terminology adoption.

Implementation must preserve cheapest correct model wins as lowest total cost per accepted governed outcome after all hard gates pass, not lowest sticker price or cost per invocation. Return all evidence, PRs, and dispositions to https://github.com/hummbl-dev/hummbl-research/issues/70.