Govern
Field Guide · Tier 1 · Act I

Govern

  1. Actor
    who proposes the action
  2. Proposed consequence
    the consequential action
  3. Resource
    what would be affected
  4. Policy evaluation
    declared policy and authority
  5. Decision
    allow · deny · step_up · defer
  6. Applicable Authority
    kept distinct from the Decision
How a consequential action reaches a Decision

01The Problem

Most teams already have governance — on paper. There is a refund cap, an approval matrix, a data-handling policy, a list of who can touch production. Those rules do not govern a consequential action merely because they exist in a wiki.

Enterprise intent has to become versioned, reviewable policy and authority that can be applied when an Actor proposes a specific consequence.

02Why existing approaches fall short

Prompt instructions can drift, and wiki pages can fall behind operational policy. Human reviewers also cannot manually resolve every consequential action a system may propose.

The answer is not policy that an agent merely consults. Enterprise policy and authority must be represented so Aarmos can evaluate a proposed consequence at a supported governance boundary.

03The concept

Govern turns enterprise intent into consequence authorization. The agent is the Actor. The consequence is what gets authorized. Aarmos evaluates the Actor, proposed consequence, affected Resource, and applicable policy and authority to produce a Decision. That Decision is not the Authority itself.

04How Aarmos applies it

Customers declare governance intent. Aarmos represents the applicable policy as a versioned, reviewable object and evaluates each supported proposed consequence against that policy and its authority requirements.

  • Policy can be versioned and reviewed as enterprise intent changes.
  • In qualified enterprise operation, effective policy follows the controlled activation path.
  • Historical decisions identify the policy version in force when they were made.

05Example

A team declares that sending customer data to a third-party service requires designated human authority. An agent is the Actor and proposes the consequential action; the proposed consequence is the transfer, and the customer record is the Resource. Aarmos evaluates that bounded question against the policy then in force. If the required authority has not been established, the Decision is step_up — a request for additional authority, not a denial.

06Mini-FAQ

Isn't this just a rules engine?
A rules engine can evaluate rules. Govern applies declared enterprise policy and authority to a specific proposed consequence and returns a Decision. Prove owns verification of the evidence recorded about that lifecycle.
Do I have to rewrite everything as code?
No. Start with a small set of consequential actions and the policy and authority that should apply to each. Customers define that governance intent; Aarmos evaluates it faithfully.
What about approvals that need a human?
A step_up Decision asks for additional authority. The human may supply that authority, but the Authority remains distinct from the Decision. A defer returns an unresolved question without converting it into a denial. See Authorities.

07Related concepts

GovernCan this agent do this?RunWill this work with my stack?ProveCan I prove what happened?
Govern. Run. Prove. Three distinct jobs across the governed lifecycle.