Concept

Change Sets

A Change Set is how Aarmos governs changes to governance itself. Policies, decision definitions, and participant bindings are what keep agents inside the lines — so if those rules can be edited live, the safety story has a hole exactly where it matters most. Nobody could prove which rules were in force when a given action ran, or who loosened them.

A change is therefore its own governed object, moving through a fixed lifecycle.

The lifecycle

• Draft — edit a proposed version of the rules. Nothing in production is affected.
• Simulate — replay the draft against real recorded executions and see which past decisions would have flipped from allow to deny, or the reverse, before anything activates.
• Approve — a person signs off. The approval is recorded as evidence: who, when, and against which simulation.
• Activate — the new signed policy bundle takes effect. Every receipt from that point carries its fingerprint.
• Roll back — return to the previously activated set. Rollback is a forward-moving event, not an erasure.

Governance history is append-only

You cannot quietly rewrite what the rules used to be. Both a change and its reversal stay in the record, hash-chained, so an auditor asking "what was allowed in March, and who changed it in April?" gets an answer they can verify without trusting the operator — or us.

See the blast radius before you commit

Simulation runs on the same deterministic replay used for counterfactual analysis, so the result comes from recorded evidence rather than an estimate. It reports how many executions were examined and how many could be judged — the difference between "this change looks safe" and "this change would have denied 41 of the last 1,000 executions, here they are."

Change Sets are available under the Change section of Operations. Related: governance continuity and the policy gate.