A threagile run emits 240 risks whose tracking status lives in the repo — who may mark one accepted?

## What the mechanism is When a source-defined model is evaluated, the tool generates a risk list. Rerun it after any edit and the list regenerates — which raises an obvious problem: how does a decision made about a risk last week survive a rerun today? threagile solves it by giving each generated risk a **deterministic synthetic id** derived from the rule and the assets it fired on, and letting the model repository hold a **risk-tracking entry** per id. Each entry carries a status — values such as unchecked, in-discussion, accepted, in-progress, mitigated or false-positive — plus fields for who decided and when. On the next run the tool reconciles the generated list against those entries, so triaged risks stay triaged and genuinely new ones stand out as unchecked. That reconciliation is the feature. Without it, a first run of 240 risks would arrive again, undifferentiated, on every commit, and the report would be ignored within a week. ## Why acceptance is the interesting field The statuses are not equivalent. *Mitigated* is a claim that work was done, and it is falsifiable — someone can go look. *False-positive* is an argument about the rule, and it is contestable on technical grounds. **Accepted** is different: it says the exposure is real, nothing will be done, and the organisation will carry the consequence. That is not an engineering statement. It is a decision about money, customers, regulatory exposure or reputation, made on behalf of people who are not in the pull request. And in this format it costs one line. An engineer under delivery pressure, looking at a red report blocking nothing in particular but making everyone uncomfortable, can change a field and the discomfort disappears. Nothing about the file resists that. ## Who may set it The principle: **acceptance belongs to whoever owns the consequence.** For a risk to applicant financial data it is the person accountable for that data, not the service team; for a risk to a fleet's availability it is whoever answers for the outage. That person is usually not the one who can merge to the model repo, and merge rights must not be allowed to imply the authority. Making that real in the repository: - **Separate the tracking section from the model.** Different reviewers for the file or section that carries statuses than for the architecture itself. Changing the design and accepting the risk it created should not be the same approval. - **Author is not approver.** The person whose change produced the risk cannot be the person who accepts it. - **Require a justification field.** Free text that says why the exposure is tolerable, in terms of the affected asset and the compensating conditions — not just "low impact". - **Require an expiry or review date.** An acceptance with no end date is a permanent decision made by someone who has probably left the team. Expired acceptances should return to unchecked. - **Name the accountable owner in the entry.** Not the team, a person. - **Treat false-positive as needing a rule-level argument.** If the rule is wrong for this shape of system, that is a statement about the rule, and it should be argued once and centrally rather than silenced per risk. ## The insider angle worth naming Once statuses live in the repo, the file **is** the audit trail for risk decisions. That makes it an asset in its own right, with the property this tree cares about: non-repudiation. Anyone with commit access can quietly reclassify a risk, and if that goes unreviewed the record of what the organisation knowingly accepted becomes untrustworthy. Protecting the tracking section — required review, protected path, meaningful history — is protecting the evidence, not the report. ## Handling the first 240 A first run producing hundreds of entries is normal, and the honest response is not to accept your way to a clean report. It is to treat the list as a backlog: 1. Sort by the criticality of the data assets and the exposure of the technical assets involved, using the ratings already in the model. 2. Accept nothing on the top-value assets in the first pass — those deserve a real decision. 3. Expect a long tail of rule-driven baseline findings; batch those into a small number of explicit, argued positions rather than 180 individual justifications. 4. Track the ratio over time. A programme where nearly everything ends up accepted and almost nothing mitigated is not managing risk; it is documenting resignation. ## The failure mode to watch for Normalised deviance. Not one bad acceptance, but the slow slide where accepting becomes the default first move, justifications become copy-paste, dates stop being set, and the report becomes a formality everyone knows is green because it was made green. The tell is visible in the history: bulk status flips, identical reasons, and no risk that ever moved from accepted back to open.