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.
@listenrightmeow
About
Technical founder with 15+ years across enterprise architecture, FDA-regulated medical devices, clinical trial platforms, and Fortune 500 consulting. Fractional CTO to 9 startups. Scaled teams from single digits to 50+ and products to $100M+ in revenue. Currently deep in domain-driven design and event-sourced systems as a solo practitioner — and writing about what that's revealing about the methodology, the tooling, and the assumptions we've been carrying.
Available for
Consultation, regulatory compliance, partnerships
Mike Dyer's blogs
Comments
MD
MD
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.