napkin-math: threshold-pairing rule for extract-parameters-from-digest

[neoneye]

Scope

Single-file change: adds a "Threshold pairing rule" to system-prompt.txt for the extract-parameters-from-digest skill, slotted between "Coverage and capacity gate rule" and "Combined viability gate preservation". No code changes; no compress changes.

Split out of PR #737 because the threshold-pairing rule lives in the extract stage, not the compress stage, so it does not fit that PR's "Phase 1 compress-prompt cleanup" scope.

What the rule says

When the extract emits a key_value whose role is a numeric threshold — a floor, cap, ceiling, minimum, maximum, target volume, target share, or target deadline — it must also emit a paired margin/surplus calculation comparing the realised quantity against the threshold. The pairing has three parts:

1. The threshold goes in key_values.
2. The realised quantity goes in missing_values_to_estimate if the source does not name it.
3. The margin calculation goes in recommended_first_calculations or derived_questions, with realised - threshold (floor: positive = pass) or threshold - realised (cap: positive = pass), using the _margin / _surplus suffix.

Under cap pressure, the rule says to drop a less-load-bearing key_value or move a less-critical calc to derived_questions — never skip the pairing.

Why

Existing rules in the same file (No orphan formula rule, Coverage and capacity gate rule, Dead-end variable prevention) cover the principle abstractly, but extractor runs were leaving threshold key_values unpaired in practice. The new rule operationalises the pairing as a concrete three-part check.

Corpus-agnostic by construction

The rule names only structural categories (floor, cap, ceiling, target volume, target share, target deadline) and the existing _margin / _surplus naming convention. No corpus literals, no plan names, no domain-specific acronyms, no expected output ids.

Regression probes (not acceptance criteria)

Baseline plans are used to detect that the rule moves the right behaviour, not to define what the rule should target. Probes run against the gitignored output/v50/ digests:

• A reverse-logistics campaign plan in the baseline previously had two unpaired threshold key_values (a volume target and a charitable-donation floor). The new rule produces paired *_margin calculations for both.
• A disaster-response plan in the baseline previously had a generator-fuel priority floor unpaired and a geological-observation trigger mis-classified as a simulatable key_value. The new rule produces the missing pairing for the fuel floor and re-routes the geological trigger to unmodelled_gates.

The probes also surface that the existing 5-cap on missing_values_to_estimate interacts with the threshold-pairing rule in ways that can force tradeoffs (a less-critical existing pairing dropped to make room). This is a known limitation, not a fault of the new rule, and is left for a structural followup.

What this PR does NOT do

• It does not add prompt content that targets any specific baseline plan.
• It does not raise the 5-cap on missing_values_to_estimate or modify any other hard limit.
• It does not address the unrelated compress-LLM run-to-run variance that drops other tripwires from the digest before the extract sees them (that issue is independent of this rule and remains open).

Test plan

• CI green (no code changes; just a prompt-text edit)
• Hand-spot the new rule paragraph reads corpus-agnostically (no plan names, no literals)
• Re-run extract-parameters-from-digest against the napkin_math baseline; the rule should move only structural patterns, not target any single plan

[neoneye]

Consolidating into PR #737 per request — single PR makes it easier to verify the combined compress + extract prompt changes.