Prompt T0.5 (spike) — Baseline-example anchoring: measure compliance gain vs parroting

Part of prompt-building Tier 0. This one is a spike with a decision gate, not a straight feature — it has a real failure mode that must be measured before adoption.

Hypothesis

7B models comply far better when shown one full, valid worked example of the expected output. We already have a generator of exactly such an example: templateFallback(req, ctx) (packages/arbitration-sdk/src/fallback.ts) produces a deterministic, valid, request-specific recommendation. Rendering it into the prompt as a baseline —

BASELINE — a valid, conservative answer for THIS request. Improve on it per the
user's intent (band, fee, split, template choice). If you cannot improve on it,
returning it unchanged is acceptable.
<the fallback JSON>

— should cut malformed-output and violation rates, because the model edits a known-good object instead of composing one from a schema description.

The risk being measured

Parroting. If the model returns the baseline (near-)verbatim most of the time, we are paying enclave latency + ledger cost for fallback-quality output labelled ENCLAVE. The source label stays honest either way (it is a model output), but the "the model adds value" story dies, and Tier 0.3's tiering would collapse to whatever the baseline contains.

Also note: the example must be built from the request's live values (the fallback already is) — never a static example, which would hand the model stale constants to echo (the exact chainId/deadline fabrication failure compose.ts documents).

Method

1. Branch-local prompt variant behind a flag/env (SLUICE_PROMPT_BASELINE=1) in the compose path — no permanent wiring.
2. Fixed set of ≥ 20 compose requests (mix: single-token and two-token budgets, varied prompts incl. conservative/aggressive wording, maxStrategies 1 and 3), run against the live Galileo provider with and without the baseline block. Reuse the harness style of spike/inference-spike.ts / the compose CLI.
3. Record per run: malformed rate (parse failures), violation rate + which invariants, attempts-to-accept, fallback rate, parrot rate (accepted output identical to baseline, or differing only in deadline/whitespace — define the comparator in the spike), latency, prompt+completion token counts.

Decision gate

Adopt (as a follow-up PR) only if BOTH hold, otherwise close with the numbers in the write-up:

• malformed + violation rate drops materially (suggested bar: ≥ 30% relative reduction), AND
• parrot rate stays below ~1 in 3 accepted runs.

Either way, the outcome and numbers go to Notion F2 §9 (prompt contract) — this is a prompt-contract decision, and promptVersion must bump if adopted.

Acceptance criteria

• Spike script + fixed request set committed under spike/ (throwaway quality is fine; reproducibility is not optional).
• The comparison table (both arms, all metrics above) in the issue/PR write-up.
• Go/no-go recorded here and on Notion F2 §9.

Coordination

Run AFTER the in-flight prompt-refactor PR lands (the variant must be built on the surviving prompt builder, or the numbers measure a dead prompt).

References

• packages/arbitration-sdk/src/fallback.ts — the baseline generator
• packages/arbitration-sdk/src/compose.ts — fabrication history, attempt cap
• Notion F2 §9: https://app.notion.com/p/3a8caae5863181609acbcfd69a5db06b