DR-123: A task directive is evidence of intent at that time, never of correctness

DR-123 — A task directive is evidence of intent at that time, never of correctness

Context

DR-104 ruled that ratified docs outrank the codebase as evidence of correctness, and named the readings that look like diligence but are not (many callers, populated rows, absent grep hits). DR-106 then named the doc families that are NOT ratified authority.

Neither covered task files — and the task ledger is precisely where the premises under investigation get written down. Owner, S528:

“Many tasks that have been minted, pre and post id-130, will have done so on exactly the premise this session set out to resolve — just because a task says include it, doesn’t mean it’s correct.”

The gap was found live. During the id-417 census, a verdict that domain/subtopic search filtering should be retired was overturned by citing id-144’s owner-directive OD-3 (“Wire kind/domain/subtopic/date filters server-side”), on the reasoning that id-144 post-dated the client feedback and was therefore “the ratified response”. The Coordinator accepted it. But id-144 was minted inside the frame the census was investigating: its directive records that someone decided, not that they re-derived.

Decision

A task’s goal text, acceptance criteria, owner-directive or invariant is evidence of INTENT AT THAT TIME — never evidence that the decision was correct. It is treated exactly as DR-104 treats code and DR-106 treats stale docs.

Consequences for use:

• Applies to pre-130 and post-130 ids alike. DR-106’s “below ~130 is presumed stale” heuristic is an id heuristic and does not catch a task minted recently on an old premise. It also does not catch the 400-series, which are renumbered backlog items carrying their original framing — check created_at and the body’s vocabulary, not the id.
• What carries weight instead, in order: (1) the requirement as the client or owner actually stated it; (2) measured current behaviour; (3) a Decision Register entry, and only for what it explicitly ruled.
• An owner decision recorded in a requirements document is NOT a task directive and is top-tier evidence. The distinction is the point of this ruling.
• When a task directive and the requirement point different ways, that is a finding to surface, not a conflict to resolve by deferring to the task.

Alternatives considered

• Extend DR-106’s stale-id heuristic to cover task files. Rejected: the failure is not about age. id-144 was recent, ratified, done, and cited the client feedback by name — and was still not evidence that its mechanism choice was re-derived.
• Treat ratified+done tasks as authority, unratified ones as intent. Rejected for the same reason, and because it would reinstate exactly the move that failed.
• Write no rule and rely on judgement. Rejected as the status quo that produced the error — but see Consequences: the evidence says a rule alone will not fix it either.

Consequences

• Retirement, rename and wiring verdicts must be re-derived from requirement and measured behaviour. A task file may be cited for history and for cost basis, never as a warrant.
• This ruling is expected, on the evidence, to be insufficient on its own. The S528 recurrence analysis over 135 retros found 161 instances of this error class and no era in which the rate fell, including after DR-104 and DR-106. Four natural experiments (DR-030 breached three times the next session; DR-071 with three consecutive sessions of zero compliance; DR-104 breached by sessions quoting it) show that naming the trap does not reduce it. The two things that transferred across 135 retros were a line in a dispatch-brief template and naming a specific tool’s specific misleading output. Findings about a reasoning posture transferred zero times.
• Therefore this DR is a definition, not the control. The control belongs at the action site (DR-099-era reasoning, and S499’s ratified “hazard guards live at the action site, not only the register”): a required dispatch-brief field, a template line, or a gate. The analysis lives at reports/s528-error-class-recurrence-analysis.md; building the control is open work.
• Recorded in tasks/id-417.md as GROUNDING §0.5b, which is where sub-agent briefs cite it.