Supersede a decision
Replace a call that stopped being right. Decisions are immutable, so correcting one means recording a new decision that points at the old one.
Goal
A new decision in the ledger carrying supersedes_decision_id, with the original still readable and the new effect applied to live state.
Steps
Find the decision you are replacing
Read the decision log and identify the call that no longer holds. You need its id, which the new decision will point at.
Write the replacement as its own decision
The new decision carries its own type, statement, rationale, and effective date, exactly like any other. Say in the rationale what changed, because that is what makes the pair readable later.
Link it to the original
Set supersedes_decision_id to the id of the decision being replaced. That link is what records the succession; nothing about the original changes.
Record it through your agent
Supersession is written over MCP with supersede_decision. There is no HTTP write route; the REST surface is read-only. The call requires an idempotencyKey, so a retry cannot record the replacement twice.
Confirm both are readable
Check the decision log. The original is still there with its original reasoning, the new decision sits alongside it, and the new effect is applied to live company state.
Worth knowing
Nothing is edited or deleted
There is no update path and no delete path for a decision. Superseding is the only way to change a call, which is why the reasoning behind past calls survives.
There is no approval state to reverse
A decision has no status, draft, or pending field. It was recorded and applied, and superseding it records that you replaced it. Disagreement is expressed forward, not by rewinding.
Supersede rather than re-record
Recording a fresh decision without the link leaves two live-looking calls with no relationship between them. The link is what tells you, and your agents, which one is current.