Concept

Authority succession & forks

Organizations split. A business unit is sold, a region is carved out for residency reasons, a legal entity divides. People move too — an operator leaves and someone has to hold what they held. Both cases ask the same question: who carries the authority now, and what can still be claimed about the history?

A shared prefix is not shared history

When one workspace becomes two, the two chains share a long common beginning. The tempting move is to treat that overlap as shared history. Aarmos refuses to: an overlap is evidence of a common past only if the split itself was recorded.

A split therefore seals a fork point — a recovery point captured as part of the split event and referenced by both successors. With one, a verifier can state that common history is verified up to the fork and that everything after it is a distinct chain. Without one, the two chains are simply two chains and their relationship reports as unresolved. Nothing is silently truncated to make the story tidier.

Each fork has exactly two successors. A three-way split is two sequential forks, each with its own sealed point.

Custody is checked at the event

Before a split is allowed to complete, each successor must already hold a byte-complete copy of the fork point, have verified that copy with its own verifier with no vendor in the loop, and control a trust root distinct from its peer's. A split whose preconditions do not hold is refused rather than queued — there is no later in which missing custody can be recreated honestly.

The result is worth the friction: after a split, each side can verify its own chain offline, indefinitely, without the other side's cooperation.

Holds survive the split

A legal hold in force at the fork replicates to both successors. The authority to release it does not. Where release authority in a successor cannot be determined, the items stay retained. Unresolved release authority is retention, never release.

People: evidence first, assertion second

Human succession derives from governed events. A handover that can be ordered against the outgoing authority's last activity produces a successor outcome. Anything that cannot be ordered produces unresolved.

You can still record a human assertion — "Dana took this over on the 3rd" — and it is kept alongside the evidence. It never upgrades unresolved into successor. The evidence outcome and the continuity assertion are separate objects on purpose, so a reader can always see which one they are relying on.

Working with it

aarmos authority show
aarmos authority succeed --from <principal> --to <principal>
aarmos authority fork --seal

Fork points appear in the continuity history alongside ordinary recovery points, so a workspace already exporting audit data gets split events there with no extra configuration.

Honest limits

A fork point proves a split was observed and sealed. It does not prove the split was authorised by anyone outside the workspace that sealed it.
Succession outcomes are only as good as the ordering of the events they derive from. If a handover cannot be ordered, the answer stays unresolved — that is the design, not a gap to be worked around.
Splits are deliberately slow and loud. The alternative is a merged-looking history that no one can defend later.