Comment by Mihai_LeanZero on "Marked Isn't Enforced"

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.

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.

That storage-level refusal is basically optimistic concurrency applied to decisions, and returning the standing entry to the second author before they commit is the right shape, it puts the fork in front of a person at the moment it happens instead of after two conflicting supersedes already exist. One thing I'm curious about on the split path: when the second write gets refused and shown the entry that already won, and that author decides to confirm a split rather than back off, does the confirmation only need their say-so, or does it also route back to whoever authored the original entry being split? If it's the second author alone, a stream that loses the race can still unilaterally decide the outcome was a fork rather than a straight replacement, and the person whose decision is actually being split never gets asked.

Fair point, and the way you've put it is exactly the risk. If the author who lost the race can confirm a split on their own, they've decided the outcome for someone who never got asked.

My direction is that a split isn't a special case at all. If the second author believes both decisions should stand, they don't override the original. They replace the decision that's currently standing with a new one that carries both, each scoped to its scope. That keeps the chain a straight line, it's recorded under the name of the person who did it, and the author of the decision that got replaced hears about it the same way they'd hear about any replacement. If they disagree, they replace it again and say why.

The product I maintain will notify the original author in the future. So nobody gets to quietly relabel a replacement as a fork. Every step is a replacement someone signed, and the last word belongs to whoever is willing to put their name on the next one.

Search Hashnode