Concepts
Agent Operating Procedures and the Shadow AOP Ledger
These two terms are the heart of Selah. Everything else in this guide builds on them, so they are defined here once, in full.
What an AOP is
In Selah the unit of governance is the Agent Operating Procedure, or AOP.
An AOP is a structured, versioned, machine-enforceable statement of what an agent may do and say in a given situation, and what must happen when it tries to step outside that.
An AOP turns a business rule, a policy, or a compliance requirement into something the engine can enforce automatically, before the agent acts, and record for audit. It is not a document and not a prompt. It is a rule the engine resolves and applies at decision time.
In plain terms, each of these is an AOP:
- An agent of this type may refund up to one thousand dollars without a human.
- An agent may never quote a price or discount that is not in the loaded catalog.
- A reply about returns must include the returns disclaimer.
- In this jurisdiction the agent must not collect a certain identifier.
You do not write code to create AOPs. You author them in the dashboard, or through the configuration API: the actions an agent may take and their limits, the things it may and may not say, the disclaimers it must include, the prices it may quote. Selah ships with a baseline and lets you enable packs of AOPs for your industry and jurisdiction, then layer your own on top.
The five layers
AOPs resolve across five layers in a fixed precedence. When two layers speak to the same action, the higher one wins. This lets a universal rule, a local rule, and your own rule coexist without ambiguity.
| Layer | What it carries | Precedence |
|---|---|---|
| compliance | Rules from law and regulation | Highest |
| jurisdiction | Rules specific to where you operate | Then |
| agent type | Rules tied to the kind of agent | Then |
| base | Your own standing rules | Then |
| campaign | Time or context bound rules, for a promotion or temporary condition | Lowest |
Precedence is compliance, then jurisdiction, then agent type, then base, then campaign. A campaign cannot override a compliance rule.
Packs: AOPs bundled and reused
AOPs are portable. A set of AOPs for an industry or a jurisdiction is bundled into a versioned pack you enable. The baseline plus the packs is the Compliance Library, which is how governance is reused instead of rebuilt per customer. This is also the foundation for the longer term direction: a library of AOPs by vertical and jurisdiction, and over time a marketplace where third parties contribute and consume governance patterns. Compliance and jurisdiction packs are the first form of that library.
The Shadow AOP Ledger
You do not write AOPs perfectly on day one. You grow them from real data, and the Shadow AOP Ledger is how.
The Shadow AOP Ledger is the record Selah builds while it runs in shadow mode. For every action and response, the engine computes the decision your AOPs would produce and writes it down without enforcing it.
The ledger is two things at once:
- Proof of what governance would have caught. You can show exactly what would have been held or blocked, which is what makes a pilot or a managed engagement persuasive.
- Raw material for authoring and refining AOPs, drawn from your real traffic rather than guesses.
The AOP lifecycle
Putting it together, adoption follows four stages, and the ledger is the engine of the middle two.
- Observe. Run the checks in shadow, so the engine evaluates real traffic without enforcing.
- Capture. Every decision the AOPs would have made, and every gap a human looked at, lands in the Shadow AOP Ledger.
- Author and refine. Turn the ledger into AOPs: tighten, correct, and codify until what the engine would do matches what you want.
- Enforce. Promote the validated AOPs and switch enforcement on. The same records now reflect enforced decisions.
This is why every integration guide tells you to start in shadow: you are building your ledger, then promoting it into enforced AOPs.
A note for engineers and for other systems
If you are reading the database or seeding another system with this context, two honest mappings matter.
- There is no single table named
aopstoday. An AOP is realized as the combination of policies across the five layers, the output configuration for responses, and the packs you enable. The AOP Runtime resolves and enforces them together. A first-class AOP object is a planned consolidation. - There is no separate ledger table. The Shadow AOP Ledger is realized as the decision records written with the shadow flag set, together with the review items that capture gaps. Querying the shadow-flagged decisions is querying the ledger.
The concept is the contract; the policies, packs, output configuration, and shadow-flagged decisions are the implementation.