Effective policy

Concept

Effective policy

There is rarely one policy. An organisation sets a floor, a team narrows it, a decision type adds its own constraints, an operator tightens things further on one machine. All of them apply at once.

Aarmos resolves that set into a single artifact — the effective policy — with a single digest. That artifact, not any file on disk, is what a decision is judged against and what the receipt cites.

Source vs. effective

A source is authored, editable, and reviewable. An effective policy is derived, immutable, and evidential. Keeping them distinct is the point: "the policy says X" means nothing until you say which of the two you mean, and only one of them is what a decision was actually measured against.

Precedence

Sources are ordered by where they came from, then by identifier — never by the order a runtime happened to load them. Two runtimes handed the same sources always produce the same result.

  1. Organisation — The floor nobody below can lower — the rules that hold everywhere.
  2. Team — A team narrowing the organisation's floor for the agents it owns.
  3. Workspace — A project narrowing team and organisation rules for its own work.
  4. Decision — Rules attached to a specific kind of business action.
  5. Actor — Rules bound to one agent or process.
  6. Operator — The local runtime operator, who may restrict further but never loosen.

Where sources live

On a machine running the Aarmos runtime, the top three layers are plain directories. Discovery is fixed — tier first, then filename — so it never depends on how a filesystem happened to list them.

  • .aarmos/policies/org/ — Organisation
  • .aarmos/policies/team/ — Team
  • .aarmos/policies/ — Workspace

A file may declare who it applies to — one agent, one decision, or one branch of your structure — so a team can govern the agents it owns without governing everyone else. A file whose applicability cannot be read is refused outright rather than treated as applying everywhere.

aarmos policy resolve prints the layers that were discovered, which of them applied to a given agent and why the rest did not, and the digest the result resolved to.

The merge only narrows

Combining sources can restrict what is possible. It can never expand it.

  • Denials accumulate. A denial from any source survives into the result.
  • Permissions intersect. Something is permitted only if every source that expresses permissions permits it.
  • Limits take the tightest value. Where sources disagree on how far authority may travel, the smallest number wins.

This is what makes the layering safe to hand out. A team can be given its own policy source without any possibility of that source quietly widening what the organisation allowed.

The one way to widen

A lower layer can relax something only when a strictly higher layer named that exact clause as delegable. Delegation is authored upward and consumed downward — it is never inferred from silence, and it is never expressed as a blanket wildcard, because a delegation over "anything" is indistinguishable from having no policy at all.

Every use of that path is recorded: which clause was overridden, by which source, under whose delegation.

Provenance

Every surviving clause names the source that contributed it. An effective policy nobody can attribute is not evidence — when a decision is questioned, the answer is not just "denied" but "denied by this clause, contributed by this source, which was in force because of this authority".

Provenance explains the artifact without being part of its identity. The digest is taken over the effective rules alone, so the same effective policy derived from a differently shaped set of sources produces the same digest.

Why a digest matters

The digest turns an assertion into a check. A receipt carries the digest of the policy that judged it, so anyone holding the receipt and the policy can confirm they match — or discover they do not. Without it, "we had a policy" is a claim; with it, it is evidence.

Keep reading