Reasoning Budget Policy v0.1 — governed inference-time compute, verification, and stopping conditions

[hummbl-dev]

Context

Implementation issue routed from:

• Research packet: https://github.com/hummbl-dev/hummbl-research/issues/60
• Source intake: https://youtu.be/Y7p4rUCdqi0?is=D6bLqRQkpD_ZzqKU

The durable signal is that model choice alone is insufficient. Agent routes increasingly need to govern how much inference-time reasoning is allocated, how it is verified, when it may expand, and when it must stop.

This issue does not adopt “unlimited tokens equals unlimited reasoning.” Recursive reasoning can amplify repeated error, drift, verifier capture, latency, and cost.

Objective

Define reasoning_budget_policy.v0.1 as a model-routing contract for bounded, observable, and auditable test-time compute.

Candidate contract surface

reasoning_policy:
  initial_budget:
    unit: tokens|seconds|rollouts|cost
    value: bounded
  extension_triggers:
    - verifier_detected_uncertainty
    - failed_acceptance_check
    - evidence_conflict
  parallel_rollouts:
    max: 3
    diversity_policy: declared
  revision_limit: 2
  verifier:
    required: true
    independence_posture: declared
  stop_conditions:
    - acceptance_criteria_satisfied
    - marginal_information_gain_below_threshold
    - repeated_state_detected
    - budget_exhausted
    - safety_or_authority_gate
  escalation_route: declared
  receipt_policy: required

The final schema may differ; this is a bounded starting hypothesis.

Required design questions

• What budget units are portable across providers and local runtimes?
• Which extension triggers are deterministic versus model-judged?
• How is verifier independence represented and tested?
• How are repeated-state, loop, and context-drift conditions detected?
• When should parallel rollouts be preferred to a longer single trajectory?
• How does the policy interact with privacy, latency, cost ceilings, and model sovereignty?
• How are human approval gates represented for high-stakes or externally consequential work?
• How does the route degrade when the preferred verifier or frontier escalation lane is unavailable?

Acceptance criteria

• Define a versioned reasoning_budget_policy.v0.1 schema or equivalent typed contract.
• Require bounded initial budget and at least one explicit stop condition.
• Represent extension triggers, rollout/revision ceilings, verifier posture, escalation route, and receipt requirements.
• Reject unbounded recursion and missing stop conditions by default.
• Add valid, invalid, and adversarial fixtures.
• Add deterministic validation for schema-level invariants.
• Add route examples covering local/open-weight, managed frontier, and hybrid local-to-frontier escalation.
• Add a benchmark plan comparing fixed-budget, adaptive-budget, parallel-rollout, and verifier-gated routes.
• Measure correctness, cost, latency, loop incidence, verifier disagreement, and unresolved-output rate.
• Produce reasoning_budget_receipt.v0.1 or an explicitly compatible execution receipt extension.
• Document failure modes and circuit-breaker behavior.
• Cross-link findings and evidence from hummbl-research#60.

Governance constraints

• “More reasoning” is not presumed to be “better reasoning.”
• No silent budget expansion or silent paid/frontier fallback.
• Model-generated confidence alone cannot authorize extension or completion.
• High-stakes routes require declared verification and human authority posture.
• Provider-specific features must map into a vendor-neutral contract rather than becoming architectural dependencies.
• New BaseN/HUMMBL terminology remains candidate language until audited.

Definition of done

The issue may close after the contract, validator, fixtures, examples, benchmark protocol, and receipt design are preserved and a local or reproducible evaluation demonstrates both successful adaptive extension and deterministic termination under failure conditions.

[hummbl-dev]

Execution posture — Wave 1 parallel lane

Reuben approved beginning this issue in parallel with hummbl-research#60.

May proceed immediately

• contract shape and versioning;
• schema invariants;
• valid, invalid, and adversarial fixtures;
• deterministic rejection of unbounded recursion and missing stop conditions;
• receipt compatibility analysis;
• benchmark protocol design.

Remains provisional pending research evidence

• default budget values;
• claims about the superiority of any test-time scaling strategy;
• benchmark thresholds and promotion criteria;
• representative provider/model mappings;
• terminology inherited from interview claims.

Required research dependency

Use source-backed findings from https://github.com/hummbl-dev/hummbl-research/issues/60. Each externally grounded design choice should link the relevant evidence or explicitly state that it is an engineering hypothesis.

Status: APPROVED_FOR_WAVE_1_DESIGN

[hummbl-dev]

Linked accounting dependency — 2026-07-11

Rebound Accounting v0.1 is now tracked in #21: #21

Reasoning-budget evaluations should emit enough compatible evidence to determine whether additional inference-time compute improves acceptance and lowers total cost per accepted governed outcome, or instead increases retries, review, latency, and total resource use. Keep the reasoning-budget contract authoritative for budget and stop semantics; #21 should consume or crosswalk those fields rather than duplicate them.