Intent policies

An intent policy captures what you mean, rather than every surface an agent might use to do it. In OpenLatch you write it as an Agent Intent Policy (AIP), and OpenLatch compiles it into deterministic rules the client applies before each covered action.

From your words to an AIP

You start from a brief: a sentence, a pasted policy document or a recorded conversation. OpenLatch splits it into intent atoms, one per rule, and generates two things from each atom: a sentence you can read, and concrete test cases.

Atom field	What it holds	Example
who	The agents the rule is about	any agent
does what	The action	deploy
to what	The target	a production namespace
only if	The condition that permits it	an approved change ticket is linked
unless	The exception	an incident bridge is active
class	Whether the atom can be enforced: enforceable, monitor-only or out of scope	enforceable

You never fill these fields in. OpenLatch extracts them from your brief, and you change them by editing the sentence.

You ratify the sentence

For the atom above, you read this sentence:

While no incident bridge is active, when an agent requests a deployment to production, the system shall require an approved change ticket.

Beside it, the test cases show what the policy would decide in concrete situations, for example a deployment with a ticket, one without a ticket, and one without a ticket during an incident. The cases are there so your answer is informed. You answer Yes or No on the sentence:

• Yes accepts the atom.
• No opens a note where you say what you meant in your own words. OpenLatch changes the fields, regenerates the sentence and its cases, and marks the cases whose verdict moved. The atom comes back for a fresh Yes or No, because an answer given on the old sentence does not cover the new one.

You never see or approve the compiled rules. You approve what you can read.

From an AIP to the client

Once its atoms are accepted, you ratify the AIP into zero, one or several zones, each in its own mode. The platform compiles the atoms into rules and builds one policy bundle per agent from its effective zone. The bundle is integrity-checked, and the client keeps it on the machine, so it keeps deciding with the network unplugged.

An atom’s class matters at runtime: a monitor-only atom stays in Monitor even when its policy runs in Enforce, because it can be watched but not enforced.

The policy lifecycle

1. Write a brief or bring a source document.
2. Review the generated sentences and their cases, and accept them.
3. Replay the policy against your recent agent activity to see what it would have decided.
4. Ratify it in Disabled, Monitor or Enforce.
5. Run it in Monitor, read its anomalies, and move it to Enforce when it is accurate.

Write your first policy walks through these steps in the console.