Provider Context Recipe Budget

Six fixed context-budget recipes

provider_context_recipe_budget_policy measures the byte cost of an agent's assembled context across six fixed recipes, filling each in order until the budget runs out and naming what did not fit, without calling any model. provider_context_recipe_budget_policy checks the size accounting of the context an agent would assemble before it calls an outside model. It does not call one. It takes six fixed recipe shapes, measures how many bytes each section costs, fills each recipe in declared order until the budget runs out, and names any section that did not fit.

Context windows as allocated budgets

The defended idea is that a context window is a budget to spend rather than a dump, so an over-budget recipe must name the sections it dropped instead of silently truncating. The idea it defends is short: a context window is a budget to spend, not a place to dump everything retrieved. The board records this as context_is_budget_not_dump. A recipe that goes over budget must say which sections it dropped, not silently truncate them.

The output is context-shape metadata per recipe: the byte ceiling, admitted and omitted section ids, the allowed deliverable route, and authority claims that stay false, with no model call and no answer. The output is metadata about context shape. For each recipe it reports the byte ceiling, which section ids were admitted, which were omitted, the deliverable route the recipe is allowed to produce, and a set of authority claims that stay false. No model is called and no answer is produced.

Purpose

Two failure modes of a loose context builder

A loose context builder can overflow a byte limit into arbitrary truncation or quietly carry answer-side material into a prompt, and this component makes both visible as plain accounting. A loose context builder has two failure modes. It can overflow a real byte limit and get truncated at an arbitrary point, and it can quietly carry answer-side material into a prompt: a proof body, an oracle-only premise list, an ideal answer, a provider output body. This component makes both failures visible as plain accounting before any model call is in scope.

Six recipes pinned to fixed budgets and routes

The six recipes are a closed set in EXPECTED_RECIPE_BUDGETS, each pinned to one deliverable route in EXPECTED_DELIVERABLES so it cannot change the kind of output it claims. The six recipes are a closed set, listed in EXPECTED_RECIPE_BUDGETS: minimal_4kb at 4096 bytes, premise_16kb at 16384, skill_32kb and repair_32kb at 32768, fewshot_64kb at 65536, and strategy_classification_4kb at 4096. Each recipe is pinned to one deliverable route in EXPECTED_DELIVERABLES, so a recipe cannot change what kind of output it claims to produce.

Byte sizes measured, not asserted

Byte sizes are measured by running the copied benchmark harness's real _provider_context_pack when present, falling back to declared sizes and recording that in real_section_body_status rather than guessing. The byte sizes are measured, not asserted. When the copied benchmark harness is present the validator imports it and runs its real _provider_context_pack over each recipe, then measures the packed section bodies. If the harness cannot load, the component falls back to the declared byte sizes and says so in real_section_body_status rather than guessing.

How it works

Two entrypoints share _build_result

run loads the fixture with seven negative cases and run_budget_bundle the exported shape without them, both calling _build_result to load recipes, sections, copied bodies, and the scan first. run and run_budget_bundle are the two entrypoints. run loads the fixture inputs with the seven negative cases enabled. run_budget_bundle loads the exported bundle shape without them. Both call _build_result, which loads the recipe rows, section rows, copied source-module bodies, and the non-public-state scan before it builds anything.

Deterministic ordered fill in _recipe_projection

_recipe_projection walks a recipe's ordered sections, admitting each only while the running total stays within byte_budget and omitting the first over-budget section and every one after it. Recipe projection is deterministic. _recipe_projection walks a recipe's ordered section ids, measures each section with _byte_size and _section_accounting, and admits a section only while the running total stays at or under the recipe's byte_budget. The first section that would push the total over budget goes to the omitted list instead, and so does every section after it. The projection returns the included and omitted section ids, the included byte count, an approximate token count of ceil(bytes / 4), the graph role, and the deliverable type.

The validator then runs three independent checks and turns each failure into a structured finding rather than a silent pass. The validator then runs three independent checks and turns each failure into a structured finding rather than a silent pass.

flowchart TD Inputs["recipe rows + section rows + copied source bodies"] --> Project["_recipe_projection ordered byte-budget fill"] Project --> RecipeCheck["_recipe_findings budget, route, manifest"] Inputs --> SectionCheck["_section_findings source ref + anchor backing"] Inputs --> SourceCheck["_source_module_findings digest + anchor of copied bodies"] RecipeCheck --> Result["_build_result status + context packets"] SectionCheck --> Result SourceCheck --> Result Result --> Result records["_write_receipts metadata-only result records"]

What _recipe_findings rejects

_recipe_findings rejects a mismatched or oversized budget, a forbidden truth-side section, a proof-body or provider-call authorization, a drifted deliverable route, and an over-budget projection with no omitted-sections manifest. _recipe_findings rejects a recipe whose budget does not match the pinned value or exceeds 65536, a recipe that lists a forbidden truth-side section id, a recipe that sets proof_bodies_allowed or carries a forbidden body field, a recipe that sets provider_calls_authorized, a recipe whose deliverable_type drifts from its route, and an over-budget projection with no omitted-sections manifest.

Section refs and anchors in _section_findings

_section_findings requires each public section to cite an allowed source ref and anchor that truly appears in a copied body, rejecting forbidden ids, forbidden body keys, outside refs, and synthetic material. _section_findings requires each public section to cite a source ref from the allowed set and at least one source anchor, then confirms the anchor text actually appears in one of the cited copied bodies. It rejects a section id in the forbidden set, a section carrying a forbidden body key, a section citing a ref outside the imported bodies, and a section marked synthetic, placeholder, fabricated, or fixture-only by _synthetic_section_material_marker.

Digest and anchor checks over eight copied bodies

_source_module_findings covers eight copied bodies, checking for each that the file exists, the manifest and source digests match the target, and every required anchor string is present. _source_module_findings covers the eight copied bodies: the graph benchmark harness, the formal-ladder eval, the result record reducer, the set calibration report, and the compute-provider, provider-adapter, transform-job, and navigation-transform-result record standards. For each it checks that the row declares a copied body kept out of result records, that the target file exists, that the manifest digest matches the target and the source digest matches the target, and that every required anchor string is present.

metadata-only result records and the compact card

_write_receipts writes metadata-only records in both modes and result_card emits a compact card, keeping counts, ids, digests, routes, and verdicts but never proof bodies or model answers. _write_receipts keeps the output metadata-only. Fixture mode writes a result, a board, a validation record, and an sign-off record. Bundle mode writes one exported-bundle validation record. result_card emits a compact card and drops the context packets, source refs, result record paths, private-scan hits, and the scope boundary payload. The records keep counts, ids, digests, routes, and verdicts. They never keep proof bodies or model answers.

The recipe and its route:

Negative cases

Seven cases the validator must reject

Seven fixture cases must each be rejected, every one keyed to an expected error code in EXPECTED_NEGATIVE_CASES. The fixture carries seven cases the validator must reject, each keyed to an expected error code in EXPECTED_NEGATIVE_CASES.

• budget_overflow_recipe rejects a recipe above its public byte ceiling.
• truth_side_section rejects an oracle-only section id.
• proof_body_leakage rejects proof or model body fields.
• provider_call_authorized rejects a fixture that authorizes a model call.
• deliverable_type_route_mismatch rejects a recipe whose route changed.
• omitted_sections_suppressed rejects over-budget context with no omitted-sections manifest.
• synthetic_section_materials rejects section material with no allowed source ref or anchor, or marked synthetic.

A missing case blocks the result

A pass requires all seven cases observed and no floor check fired, and a missing case blocks the result. A pass means all seven were observed and no floor check fired. A missing case blocks the result.

Prior Art Grounding

Retrieval-augmented generation and CLI restraint

The recipe budget sits in the retrieval-augmented-generation lineage, narrowed to metadata that budgets, orders, and drops sections, and borrows the CLI principle of saying enough but not too much. The recipe budget sits in the lineage of retrieval-augmented generation and context packing. Lewis et al.'s Retrieval-Augmented Generation is the research anchor for conditioning generation on retrieved supporting material rather than model parameters alone. This component narrows that idea to metadata: retrieved sections are budgeted, ordered, and dropped explicitly before any model call is in scope. The command-facing style borrows the Command Line Interface Guidelines principle of saying enough but not too much, expressed here as fixed byte ceilings and explicit omitted-section manifests.

Validation Result record Path

Run from microcosm-substrate:

PYTHONPATH=src ../repo-python -m microcosm_core.organs.provider_context_recipe_budget_policy run \
  --input fixtures/first_wave/provider_context_recipe_budget_policy/input \
  --out /tmp/microcosm-provider-context-recipe-budget-policy/fixture \
  --card
PYTHONPATH=src ../repo-python -m microcosm_core.organs.provider_context_recipe_budget_policy run-budget-bundle \
  --input examples/provider_context_recipe_budget_policy/exported_provider_context_budget_bundle \
  --out /tmp/microcosm-provider-context-recipe-budget-policy/bundle \
  --card
PYTHONPATH=src ../repo-python -m pytest -p no:cacheprovider tests/test_provider_context_recipe_budget_policy.py -q
PYTHONPATH=src ../repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

What a green result proves

A green result proves only public context-recipe metadata, with fixture mode observing every negative case and writing four records and bundle mode validating the exported shape into one metadata-only record. A green result proves only public context-recipe metadata: byte ceilings, ordered admission, omitted sections, deliverable routes, the digest and anchor checks over the copied bodies, and the seven negative cases. Fixture mode must observe every negative case and write the four records. Bundle mode must validate the exported shape and write one metadata-only record.