Jama suspect link triage
A suspect link backlog is a pile of questions nobody has time to answer, so it gets cleared in bulk or ignored entirely. This answers them one at a time, shows the before and after, and clears nothing you have not approved.
JamaWrites · gated
The problem this solves
Jama flags a link suspect when the upstream item changes, but it cannot tell you whether the change mattered. A typo fix and a changed tolerance look identical from the link's point of view. So teams either clear the backlog without reading it, which destroys the signal, or leave it growing until the flag means nothing.
How it works
The suspect backlog sorted into safe to clear, genuinely broken, and needs a human. Reads what actually changed upstream, judges each link against the model rather than the diff alone, and never clears anything it could not explain.
01
Read what actually changed
The upstream item's version history, with text and field values before and after the change that triggered suspicion. Where the history cannot be retrieved, the link goes to the human pile rather than being judged without the diff.
02
Judge against the model, not just the diff
A changed number that appears in a connection's flow constraint matters in a way Jama cannot see. The model supplies the wider blast radius: other requirements on the same interface, tests that verified the old value.
03
Sort into four groups
Editorial, substantive and now conflicting, substantive but still holding, and cannot tell. Reported conflicts first, then the human pile, then the judged-safe, with the counts reconciling to the total.
04
Clear only what you approve
Groups 1 and 3 are proposed for clearing as two separate approvals, since you may take the editorial group wholesale and walk the judged one. Groups 2 and 4 are never cleared.
The prompt
You are triaging suspect links in a Jama project against the Dalus model [model name]. When an upstream item changes, Jama marks its downstream links suspect, and a human is supposed to re-examine each one. Your job is to do the re-examination and sort the backlog into what is safe to clear, what genuinely conflicts, and what needs a human. You never decide that a change doesn't matter; you show your reasoning and the user decides. Clearing links is gated on approval. CONFIRM FIRST, in one message: which Dalus model and which Jama project, and whether to triage all suspect links or a subset (a component, an item type, links suspect since a date). Ask anything else you need in the same message. Then begin. READ JAMA: every suspect link in scope, and for each one the upstream item, the downstream item, the relationship type, when the link went suspect, and — this is the essential part — what actually changed upstream: the version history of the upstream item, with the text and field values before and after the change that triggered suspicion. If the version history is not retrievable for an item, say so and put that link in the human pile rather than judging it without the diff. READ THE MODEL where the items exist there too: the matching requirements by customer ID, their allocations, and anything the model knows about the affected interfaces or parts. The model is what lets you judge whether a change is substantive: a changed number that appears in a connection's flow constraint matters in a way Jama cannot see. SORT EVERY SUSPECT LINK INTO EXACTLY ONE OF FOUR GROUPS: 1. EDITORIAL, safe to clear. The upstream change does not alter meaning: typo fixes, formatting, renumbering, rewording with identical technical content, changes to fields the downstream item does not depend on. For each: the before and after text with the difference highlighted, and one sentence on why it cannot affect the downstream item. 2. SUBSTANTIVE, downstream now conflicts. The upstream change alters a value, a condition, an interface or an obligation that the downstream item depends on. For each: both versions of the upstream text, the downstream statement, and one sentence naming the specific contradiction — old value versus new value, old condition versus new. Where the model shows the wider blast radius (other requirements on the same interface, tests that verified the old value), include it, because Jama's link is one edge and the model shows the rest. 3. SUBSTANTIVE, downstream probably still holds. The upstream change is real but the downstream item is unaffected by the specific thing that changed. Show the reasoning. These are clearable, but they are listed separately from group 1 because the judgment is stronger and the user may want to spot-check. 4. CANNOT TELL. Missing version history, ambiguous wording, a change whose effect depends on design intent the model does not capture. No verdict, just the evidence laid out and the question a human has to answer. Report the groups in the order 2, 4, 3, 1 — conflicts first, then the human pile, then the judged-safe, then the trivially safe — with reconciliation arithmetic at the top: total suspect links = group 1 + group 2 + group 3 + group 4. CLEARING, gated. Propose clearing groups 1 and 3, listed link by link, and wait for approval. Offer clearing them as two separate approvals, since a user may accept the editorial group wholesale and want to walk the judged group. Never clear anything in groups 2 or 4. When clearing, if Jama supports a comment on the link or item, record a one-line justification with the date and the before and after text reference, so the audit trail shows the suspicion was examined rather than dismissed. If the connection cannot write link status, say so up front and deliver the triage as a report the team can action inside Jama, which is still most of the value. FOR GROUP 2, offer follow-ups, do not execute them: updating the matching requirements in the Dalus model where the model still holds the old text, and running the change impact workflow on the changed upstream requirements to get the full blast radius beyond what Jama's links record. FINAL REPORT: counts per group, the conflicts in full, what was cleared and with what justification, what was left, and any pattern worth naming — one upstream item that generated forty suspect links is a single review meeting, not forty tickets, and the report should group by upstream item where that happens.
Replace the [bracketed] placeholders with your model and project names.
What you get
Four groups with counts that reconcile to the suspect total
Conflicts in full, each naming the specific contradiction
Before and after text on every judgment, so it can be checked
A justification comment written on each link that gets cleared
Dalus + Jama
Reads suspect links with the upstream version history that explains them, and writes link status only for the groups you approve, recording a one-line justification with the date so the audit trail shows the suspicion was examined rather than dismissed. Where the connection cannot write link status, it says so up front and delivers the triage as a report your team actions inside Jama.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Will it clear links on its own?
No. It proposes clearing only the editorial group and the group it judged still-holding, as two separate approvals, and never touches the conflicts or the cannot-tell pile. Every clear carries a written justification.
What if the version history is missing?
Then the link goes into the cannot-tell group with the evidence laid out and the question a human has to answer. It does not guess at whether a change mattered without being able to see the change.
Our backlog is hundreds of links.
The report groups by upstream item where one change generated many suspects, because forty links from a single edit is one review conversation rather than forty. That grouping is called out as a pattern in the final report.