Good question, and forks are the harder case. When two decisions both claim to replace the same one, a person should be making that call, not the system.
I'm working on it in two places.
In storage, a decision can only be replaced once. If someone writes a replacement against a decision that's already been replaced, the write gets refused and comes back to them with the decision that's actually standing now. They see what was already decided before they commit to anything. If both replacements are meant to stand, as if one decision were split into two, the author confirms it, and the record shows it.
Some checks are too slow to run while the decision is being written, so they happen afterward. For those, we're building a way to get the result back to the agent on its next turn. The agent raises it with whoever they're working with, and anything related to that decision waits until they answer.
Agreed on the reporting point too. If the same process does the work and writes the report, the report is only marking. I hold agents to the same rule on the delivery side.
The Vulcan numbers make the case better than any argument could, 43.1% down to zero once the old record is actually filtered rather than flagged. What I'm less sure about is how the authored-supersedes link behaves when it forks. The post says a link doesn't care which stream it lives in, an operational call can retire a planning decision months later, which is realistic, but it also means two different later entries from two different streams could each author a supersedes link against the same earlier one, maybe disagreeing about what should replace it. Does flmnt pick the most recent link, keep both and surface the conflict, or does authoring a second supersedes against an already-superseded entry just get rejected outright? Linear chains are the easy case, forked ones are where a person actually needs to be pulled back in. The same mark-vs-enforce gap shows up outside agent memory too, a report generated by the same process that did the work is marking, not enforcing, whichever domain it's in.