Each run should record the model SETTINGS alongside the model id, because the id alone does not determine behaviour and so does not make a run interpretable or reproducible. Whatever the current model exposes belongs in the record: reasoning or thinking depth, temperature and other sampling parameters, a seed where one exists, the context-window variant, and any speed or quality mode the harness offers. Two runs stamped with the same model id can differ substantially on all of these, so a record that names only the id invites a false comparison between them: an audit verdict, a benchmark, or a regression blamed on a code change may in fact be a settings difference. This matters most where a verdict is treated as evidence. The intent-audit verdict already carries a verifier block of id and version, which is the natural place to widen; the per-run transcript store is the natural home for the settings of an ordinary session; and the Assisted-by trailer is NOT the place, since its accepted shape is a vendor and model pair and widening it would break the gate that reads it. The hard constraint is the same one iss-2608290810032799 records: a model cannot reliably introspect the settings it is running under, so the harness has to supply them. That makes this a capability of the dispatching layer rather than something an agent can be instructed to self-report, and any design that asks the agent to state its own settings inherits exactly the truthfulness problem that the attribution gate already has.

Frontmatter

.abcd/work/issues/resolved/iss-2608290811463906-each-run-should-record-the-model.md
open on GitHub ↗ · commit history ↗

References1

• itd-166A run records what it was actually run withrelated

mentions3

• iss-2608290810032799The attribution gate validates the Assisted-by trailer's SHAPE but cannot tell whether the model id names the model that actually did the work, so a wrong but well-formed id passes green. In the itd-150..162 run four implementation agents were briefed with an incorrect model id: two used it as instructed and their commits passed the gate, two recognised it as a false disclosure and stamped their real id instead. The convention exists precisely to prevent a false disclosure, and the gate is blind to the only failure that matters. A full mechanical fix may be impossible because the runner cannot attest which model produced a commit, but two partial rungs exist: refuse a vendor and model pair absent from a maintained known-models list, so a typo or a stale id is caught; and have the dispatching harness supply its own model id to the agent, so a hand-written briefing cannot introduce a wrong one. Distinct from iss-211 (making the attribution preference portable) and iss-220 (composing the trailer at creation time): this is about the truthfulness of a trailer that is present and well-formed.
• iss-2609291118049254capture resolve and capture wontfix have no way to set the typed duplicates link, so a record closed as a duplicate carries the relation only in wontfix_reason prose. A machine reader of the ledger sees a wontfix, not a duplicate (found by review-triageMinorC: four duplicate closures in lane triageMinorC, iss-2608290811463906, iss-2609170640135192, iss-277, iss-91). Add a --duplicates <id> flag (issue or intent id) to wontfix, or a duplicate sub-verb, writing the field the ledger already defines.
• iss-2610180052110870A record declined in wontfix/ as a duplicate of an intent cannot be moved to resolved/ when that intent ships: capture resolve refuses it as already in wontfix, yet the issue-drift gate refuses a shipped intent whose related_issues name a wontfix record, so the only way through is a hand move of the record (done for iss-2608290811463906 when itd-166 shipped).