Bring implementation evidence back

The problem this solves

Evidence of implementation lives in the tracker, evidence of verification lives in the model, and nobody joins them until the week before a review. The join is mechanical, so it gets deferred, and deferred long enough the gap between what closed and what was verified is invisible until somebody asks for it in a room.

How it works

Closed Linear issues become evidence on the requirements they reference, in four lists a review can act on. The product is not the attaching. It is the separation of requirements that have both an implementation and a passing test from the ones that only look like they do, including the evidence that ran before the work it was meant to verify.

You are collecting implementation evidence from Linear and attaching
it to the requirements in the Dalus model [model name]. The team
closes issues that reference requirement IDs; the model does not know
that happened. The product of this workflow is not the attaching, it
is the list a small team stares at before a review: which
requirements now have both an implementation and a passing test, and
which only look like they do.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Linear team and, if relevant, project; the period to cover, meaning
the last cycle, a named cycle, or a date range; how the team writes
requirement IDs on issues (in the title, the description, a label, a
custom field); and whether evidence should be written back to the
model or delivered as a report only. Ask anything else in the same
message. Then begin.

ESTABLISH THE ID CONVENTION BEFORE SCANNING. Infer the pattern from a
sample of issues and from the model's ID format, show the user the
pattern and five real examples you found, and have them confirm it. A
wrong pattern produces a wrong report in both directions, and a
report claiming coverage that does not exist is worse than no report.

READ LINEAR: completed issues in the period with their identifiers,
titles, descriptions, labels, the requirement IDs they reference,
completion dates, linked pull requests where the integration records
them, and the cycle they closed in. Also read issues referencing a
requirement ID that are NOT complete, since those tell you what is in
flight against the same requirement.

READ THE MODEL: the requirements those issues reference, plus the
full requirement set in scope, with their allocations, verification
items, test results and dates, and lifecycle status.

NEVER SET LIFECYCLE STATUS. Attaching evidence is a mechanical act;
deciding that a requirement is satisfied is a review decision the
team owns. Write evidence links only, and say in the report that
status changes were deliberately not made.

THEN PRODUCE THE FOUR LISTS. These are the workflow, not a byproduct:

1. IMPLEMENTED AND VERIFIED. Both an implementation issue completed
   and a passing verification. Name both, with dates. This is the
   list that goes into a review.

2. IMPLEMENTED, NOT VERIFIED. Work is done, no passing test.
   Ordinary mid-development, but it is the list that grows quietly
   and surprises people at a gate.

3. VERIFIED, NO IMPLEMENTATION EVIDENCE. A passing test with no
   completed work behind it. Say plainly what this usually means:
   either the work was done without referencing the requirement, or
   the test is not testing what it claims. Both are worth knowing,
   and this list is short enough that a human can resolve it in ten
   minutes.

4. EVIDENCE OUT OF ORDER. The issue completed after the verification
   last ran, so the test passed against code that has since changed.
   This is the one nobody catches by hand and the reason the
   workflow is worth running.

ALSO REPORT, briefly: requirements with issues in flight but nothing
complete; issues referencing a requirement ID the model does not
contain, which usually means a renamed or deleted requirement; and
completed issues referencing no requirement at all, as a count with
the largest ones named, since that is scope the model never asked
for.

RECONCILIATION: completed issues in the period = referencing a valid
requirement + referencing an unknown ID + referencing none.
Requirements in scope = each of the four lists + untouched.

WRITE THE EVIDENCE, gated: propose per requirement the issue link, the
issue identifier, the completion date and the person or team where
Linear records it. Show the full set and wait for approval. Never
write in bulk without showing what will be written.

FINAL REPORT: the four lists, the reconciliation, what was written,
and one plain paragraph on the state of the set. Offer, do not
execute: re-running the verifications that are now out of order,
opening issues for list 2, and running this at the end of each cycle
so it stays cheap.

THIS WORKFLOW IS READ-ONLY on Linear. It writes evidence to the model
only after approval, and never writes lifecycle status.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions