Concept
Policy lifecycle
Writing a policy from a blank page is how teams end up with rules that are either so loose they permit everything or so tight they break production on the first run. Aarmos treats authoring as a pipeline that starts from evidence and ends at a gate.
The pipeline
- 01
Observe
Record what your agents actually do. Nothing is proposed from imagination — only from traffic that was genuinely seen.
- 02
Propose
Turn observations into a candidate policy. Proposals cover observed behaviour only: a host that was never seen never becomes a rule, and absence is never read as intent.
- 03
Draft
The candidate exists as a draft. A draft governs nothing, and there is no path by which it can grant itself standing.
- 04
Check
The draft is checked for the mistakes that quietly defeat governance — unrestricted egress, blanket wildcards, permissions shadowed by an earlier rule. Some findings block; some are advice.
- 05
Simulate
The draft is re-judged against real recorded history: what would newly have been denied, what would newly have been permitted, and what could not be judged at all.
- 06
Review
A human approves the exact candidate they reviewed — identified by digest, so an approval cannot silently carry over to different bytes.
- 07
Sign
The approved bytes are signed, which is what makes authorship provable afterwards rather than merely recorded.
- 08
Activate
Only now can the policy govern anything, and only if every preceding gate is satisfied.
Simulation is the payoff
The expensive question about a policy change is not "is it valid?" but "what breaks?". Simulation answers it by replaying recorded history against the candidate, so the blast radius of a change is visible before the change governs anything.
Observations that cannot be judged are reported rather than dropped. A simulation that quietly discarded what it did not understand would understate risk exactly where risk is highest.
The activation gate
Activation is refused unless every requirement is met — a missing requirement is a refusal, never a default yes.
- The candidate has been simulated.
- No blocking findings remain outstanding.
- A human approved this exact candidate, matched by digest.
- The approver is not the author. Self-approval is not review.
- Signatures verify.
Three questions, three answers
A policy artifact is described along three axes that are kept separate because they genuinely disagree in practice. An active, signed policy can still be expired. A draft can be signed. A valid signature can sit under a key that has since been revoked.
- Where is it in the change process? Draft, in review, active, retired.
- What can be proved about its authorship? Unsigned, signed, verified, or signed under a revoked key.
- Is it the one in force right now? Not yet, yes, or no longer.
Collapsing those into a single status field is precisely the bug this model exists to prevent — it is how a system ends up reporting a policy as good when only one of the three answers was actually good.
Lineage and bindings
Policies descend from other policies, and the library keeps that ancestry so "where did this rule come from?" has an answer beyond institutional memory. Separately, bindings record which policy was in force for which scope over which period — which is what lets you ask what was governing at the moment an incident occurred, rather than what is governing now.
Assisted authoring
A model can help someone write policy. It can never govern anything, and that is enforced structurally rather than by convention.
- The only output is a draft. There is no path from assistance to activation that does not pass through a human.
- Assistance can only narrow. It may add restrictions. It may not introduce a permission the baseline did not already contain, or extend how far authority travels. A model cannot hand itself authority nobody granted.
- Refusals are kept. "The assistant suggested this and we refused it" is part of the record; silently dropping it would not be.
- The requester cannot approve their own draft. The activation gate knows who asked.
Keep reading
- Effective policy — what an activated policy composes into.
- Change Sets — governing changes to governance itself.
- The execution chain — where policy sits in a live decision.