MP-21 · Context Budgeter

MP-21 turns Context manifests and budget allocation into a production-shaped Forge milestone. You will build a selection stage that can answer not only “what did the model see?” but also “what could it have seen, what was dropped, why, and under which policy?”

This is not a prompt-concatenation exercise. The artifact is a strict manifest with policy, candidate-set, stable-prefix, and selection identities. Required overflow stops before inference. Optional pressure produces typed decisions.

Acceptance contract

Given the pinned policy and seven candidates, your implementation must:

• derive 640 input tokens from a 1,024 window and three independent reserves;
• bind every count to exact content and a counter release;
• preserve the required instruction and latest user turn or fail;
• enforce all six lane maxima;
• select optional items using deterministic priority/density ties;
• preserve stable-prefix/variable-body order;
• select exactly instruction, demo, latest-user, crash-log, and memory;
• use 630 tokens, leave 10, and record a 260-token stable prefix;
• drop screenshot for evidence-lane pressure;
• drop old-turn for total pressure;
• reproduce the manifest from exact inputs;
• detect all nine supplied mutations.

Run it

cd rust/rust-ai-engineering
cargo test -p mosaic-harness context_budget
cargo run -q -p mosaic-harness --example context_budgeter_lab

The example writes:

target/labs/mp-21/95079edc3cc835f5496e4b386ce02f3f7a319cae2914004931fa70752a0a88c5.json

Pinned evidence:

policy SHA-256         95079edc3cc835f5496e4b386ce02f3f7a319cae2914004931fa70752a0a88c5
candidate-set SHA-256  f8a9903857d9402e9cb756c30e7eae247319c904414fd5c648f1eec00d7184f1
manifest SHA-256       0cb9127ebd297b75d93ee2da217cf6f9b014d4708389d4919fb3e3bff6c300b8
artifact bytes         4,821
artifact SHA-256       7a00e2210a1803c753ea7e552b51d4b6acf6aa0f85152ed83d368a7f57c4a4d2

Predict

Do not run the allocator yet. Read:

labs/harness/mp-21-context-budgeter/fixtures/context-policy.json
labs/harness/mp-21-context-budgeter/fixtures/candidates.json

On paper:

1. calculate input capacity;
2. admit required candidates;
3. order optional candidates by policy;
4. track total and lane usage after each decision;
5. predict render order and stable prefix;
6. classify every dropped item.

Your written trace is part of the learner evidence. A correct final list without intermediate budget state is insufficient.

Trace

Run the example, then follow crash-log through:

candidate content SHA
→ counted-content SHA
→ token counter release
→ optional priority ordering
→ evidence lane usage
→ selected decision
→ render position
→ candidate-set and manifest identity

Repeat for screenshot. Identify the exact inequality that fails. Repeat for old-turn and explain why it reaches a different branch.

Implement

Start from the strict types. Implement in this order:

1. policy validation and checked reserve arithmetic;
2. exact six-lane validation;
3. candidate identity and token-receipt validation;
4. duplicate ID/position and placement checks;
5. required-first admission;
6. deterministic optional comparator;
7. total/lane/item drop reasons;
8. stable render order;
9. usage, prefix, and manifest identities;
10. reproduction verifier.

Run the focused suite after each stage. Do not add provider calls to make the lab “more real”; the selection boundary should remain deterministic.

Break

The mutation fixture covers:

• required total overflow;
• required lane overflow;
• weak count for a required candidate;
• token-count/content drift;
• duplicate candidate identity;
• illegal stable-prefix hoisting;
• ordinary lane pressure;
• stored manifest mutation.

For three cases, temporarily remove the responsible check. Demonstrate that the mutation test fails for the expected reason, then restore the implementation.

Add one mutation of your own. Strong choices include:

• duplicate lane limit;
• arithmetic boundary;
• optional item limit;
• output reserve reduced to zero;
• stable-prefix content changed without re-counting.

Measure

Create deterministic candidate sets of 8, 32, 64, and 128 items. Record:

• allocation median and p95;
• allocations and peak memory;
• selected/drop counts by reason;
• deterministic manifest equality across 100 runs.

Then implement an exact knapsack oracle for at most 20 optional candidates. Compare:

regret = exact selected utility - greedy selected utility

Do not replace the production allocator yet. First measure whether regret changes downstream held-out behavior enough to justify a more complex bounded solver.

Diagnose the deliberate failure

Scenario: the manifest reports 630/640 input tokens, but the provider rejects the compiled request as too large.

Investigate:

1. Was each count produced for exact candidate content?
2. Did the tokenizer release match the selected model route?
3. Were special tokens and message framing counted?
4. Were tool schemas and output schema included?
5. Did multimodal blocks use provider-native accounting?
6. Was the fully compiled provider request counted?
7. What was predicted-versus-observed delta for this route?

The repair is a new counter/adapter/reserve policy and a new manifest. Provider auto-truncation is not an acceptable hidden repair.

Improve

Choose one extension:

• final-wire count with a monotonic removal-only repair pass;
• per-item maximum plus total/lane maxima;
• soft lane targets and bounded shared pool;
• duplicate/overlap-aware evidence selection;
• exact small-state solver with time/state ceiling;
• output reserve chosen by task/output contract;
• provider cache receipt correlated with stable-prefix identity.

Version the allocator or policy when behavior changes. Add before/after fixtures and explain which manifest fields change.

Defend

Your design note must answer:

1. Why can required context never become an ordinary drop?
2. Who is authorized to assign lane, trust, priority, and required status?
3. Why is provider file size not a universal token cost?
4. Why does stable-prefix intent not prove a provider cache hit?
5. When is a greedy allocator preferable to an exact optimizer?
6. How will you detect lane starvation in production without logging content?
7. What is strict replay if token-count service results change later?

Submission evidence

Submit:

• focused and full gate receipts;
• the exact lab artifact and digest;
• your prediction trace;
• one new mutation;
• the 8/32/64/128 benchmark table;
• greedy-versus-exact regret cases;
• the deliberate-failure diagnosis;
• the design defense.

Completion rubric

A strong solution:

• preserves all required candidates or returns a typed error;
• never silently truncates;
• binds count to content and counter release;
• enforces total and lane constraints independently;
• keeps selection and render order deterministic;
• records every candidate decision;
• reproduces stored manifests;
• measures both runtime cost and selection quality;
• treats trust and authorization separately from retrieval score.

A weak solution returns only selected strings, uses character count as tokens without versioning, drops required items, hides rejected candidates, or claims greedy selection is optimal.

Next dependency

MP-21 feeds retrieval, memory, tools, and replay. Next, the retrieval chapters will produce better evidence candidates; MP-22 will verify memory writes before those records can compete for this manifest’s memory lane.