Conflict Detection
Two changes can each look just as related to an old decision. Being related isn't the same as agreeing with it, and telling those apart takes more than noticing the resemblance.
A team decided, months ago, to route a certain kind of request through one particular service. A new ticket comes in that mentions that same service, in almost the same words as the original decision. From a distance, the two look like close cousins: same system, same vocabulary, same area of the product. One of them is carrying that decision out. The other one is quietly reversing it. Nothing about how closely the new ticket resembles the old decision tells you which.
Resembling a decision and agreeing with it are different claims
Any system built to catch a change that runs against an old commitment starts the same way: find the new work that's actually related to that commitment. That part is comparatively easy, degrees of relatedness between two pieces of text are a well-understood thing to measure. The part that's actually hard comes right after: relatedness alone can't say whether the new work agrees with the old decision or reverses it, because agreement and reversal both produce something that reads as closely related to the source. A ticket that does exactly what a decision called for and a ticket that does the opposite can sit at nearly the same distance from that decision, because distance is measuring which topic something is about, not which side of an argument it's taking.
That gap matters more than it sounds like it should, because it's not a rare edge case. Most new work that's worth comparing against an old decision at all is, by construction, going to be closely related to it. The very thing that makes a candidate worth checking, close resemblance to an existing commitment, is exactly the property that can't distinguish implementing that commitment from contradicting it.
What it actually takes to tell the two apart
Proactive Brief is where Brief does this. New work gets compared against the team's live decisions, and the candidates that come back related enough to be worth a look go through a second, separate step: a dedicated judgment pass that asks the sharper question resemblance alone can't answer, does this actually agree with the decision or run against it, not just how closely does it resemble the decision. In real testing against actual data, dropping that second step produced nothing but false alarms, changes that were flagged as tension purely because they scored as closely related, when in fact every one of them was doing exactly what the original decision asked for. Relatedness had correctly found the candidates. It had nothing to say about which way they pointed.
Once that judgment step actually rules something in, it doesn't get treated as a foregone conclusion either. It lands in the review queue a person picks up on their own terms, the same review queue any other judgment call from Brief's agents already waits in, as something worth a second look rather than a fact to act on.
This isn't the same gap as a missing decision
It's worth being precise about which failure this actually is. A different, already-covered case on this blog covers several ways a decision itself can be deficient: never made, made but not captured, captured but not reachable, or captured but too ambiguous to act on. This is a different problem entirely. The decision here is sound, on record, and findable. The failure is that resemblance to it doesn't tell you agreement from reversal, and that gap exists even when the decision itself has nothing wrong with it.
That's also what separates this from a post about an agent matching stale surrounding code, which describes a related but different moment: an agent copying a pattern that was itself already overruled, before the work ever gets made. This is downstream of that. The work already exists, related enough to a decision to be worth checking, and the open question is which side of that decision it lands on.
The honest limit: a judgment call, not a solved measurement
None of this makes telling agreement from reversal a settled problem. A judgment step can be wrong in both directions, calling a real contradiction harmless or flagging an honest implementation as tension, and getting it right depends on real, specific signal about what the decision actually constrains, not just what it's topically about. That's exactly why the output is a candidate for a person to weigh, not a verdict the system enforces on its own. A relatedness score was never going to settle a question about agreement or opposition, and neither is a second automated pass that isn't itself checked by someone who can see the two side by side.
Think about the last piece of work your team shipped that clearly mentioned an old decision. Would anyone have caught it if that resemblance was hiding a reversal instead of a match?
Frequently asked questions
How does Brief tell a change that agrees with a decision apart from one that contradicts it? New work gets compared against a team's live decisions for relatedness first, then anything that comes back closely related goes through a separate judgment step asking specifically whether it agrees with the decision or runs against it. Relatedness finds what's worth checking. The judgment step decides which way it points.
Why isn't measuring how related two things are enough on its own? Because a change that carries out a decision and one that reverses it can both come back looking equally related to that decision, since relatedness is about shared topic, not about agreement. Testing this directly showed that skipping the judgment step and going on relatedness alone produced nothing but false alarms, changes flagged as tension that were actually doing exactly what the decision asked for.
Does this replace the decision that should have guided the work in the first place? No, it assumes the opposite problem. If the decision itself was never made, never captured, or too ambiguous to act on, checking new work against it won't help, that's a defect in the decision, not in how new work relates to it. This only applies once a sound, findable decision already exists.
Does a flagged conflict get blocked or fixed automatically? No. Finding a candidate and deciding what to do about it stay separate. A person reviews it and chooses to act, dismiss it, or leave it for later. Being related enough to a decision to raise the question is not the same as being confirmed as an actual conflict.
← Back to Blog