Rules

A rule is a plain-English statement of what your agent must not do. The people who own the workflow (AP managers, compliance, claims supervisors, CS leads) write the rules themselves, in the platform dashboard’s RULES tab. There is no engineering ticket and no security-team translation in between. Natural-language rule authoring by the workflow owner is core to Novarch, not a convenience.

Authoring rules

Open RULES in the platform (/app/rules — its own top-level surface; rule authoring requires an admin sign-in). WORKBENCH is where you compose, test, and commit; COVERAGE shows which action types your rules gate. A rule is the plain-English text plus the verdict it carries: pause (hold) or block (kill). Write what the action must satisfy and what should happen when it doesn’t; you describe the policy, not the plumbing.

Novarch validates rules on save and stores each one with its own rule_id and a server-owned version (v1 on create, bumped on every save). Every create, edit, and delete is recorded to an append-only audit log with the exact rule text and the author’s identity — a rule’s full prior wording stays recoverable after any edit. Saves apply to new sessions; sessions already in flight keep the rule snapshot they started with. From then on the Novarch engine applies the rule to every matching action.

Scope

Each rule is scoped by action_type, the short string that names the write it governs. The Novarch engine matches a rule against an action when the action’s action_type equals the rule’s applies_to. A rule scoped to process_invoice applies to invoice payments; a rule scoped to issue_refund applies to refunds; a rule you author for grant_access applies to access grants. The bundled AP and CS packs are nothing more than rules scoped to process_invoice and issue_refund. Your own action_type is a first-class peer.

A rule with no applies_to is un-scoped: it applies to every action, across every workflow. Use it for a policy that must hold everywhere.

Rules compose by most-restrictive-wins: adding a rule, scoped or un-scoped, can only tighten, never loosen. There is no rule that overrides another into a pass.

Citations

When the Novarch engine pauses or blocks an action, it must say why. Every hold and kill Decision carries:

• rule_id_cited: the rule that fired, and
• signals_cited: the specific evidence from the session that triggered it.

This is enforced, not advisory: the Novarch engine cannot return a paused or blocked verdict without naming a rule. That citation is what makes the audit trail credible. An operator (and later an auditor) sees exactly which plain-English rule the action violated and on what evidence.

A worked example

Here is a real rule body, the AP off-cycle-payment rule, as your admin would author it. It enforces a company policy the agent has no way to know about, which is exactly the gap Novarch closes:

Off-Cycle Without Exception Ticket → BLOCK

Kill any vendor payment scheduled outside the standard payment cycle that does not reference a valid exception ticket. Finance maintains an exception-ticket queue (EXC-NNNN, four-digit) for any payment deviating from the regular cadence: bonus runs, rush wires, end-of-quarter true-ups. The exception ticket is the audit trail for why the deviation was authorized. An off-cycle payment without an exception ticket has no audit trail, no human authorization, and no policy record. It must not proceed regardless of vendor, amount, or domain. The agent has no way to know whether an exception ticket exists; Novarch enforces it.

When an off-cycle payment arrives without a valid EXC-NNNN reference, the Novarch engine blocks it and cites this rule by its rule_id along with the signals that fired (the off-cycle flag and the missing exception ticket). A long-tenured vendor with a perfect domain match still fails. The rule is about the authorization paper trail, not the vendor’s legitimacy.

Why plain English wins

A real production agent has no idea your Finance team requires exception tickets for off-cycle payments, that your refund policy caps at a certain amount, or that a re-submitted invoice should be paused for review. Those policies live in the heads of the people who run the workflow. Novarch lets them write the policy down, in their own words, and have the Novarch engine enforce it across the agent’s whole session, without ever filing an engineering ticket.

Measuring a rule’s reliability

The workbench’s TEST stage can judge one case several times against your draft. Pick a case from MONITOR (or paste a session log), say what verdict you expect, choose how many runs, and measure. The result is the count of runs that agreed with you over the runs that could be judged, the verdict distribution the judge actually produced, and the judge’s own reasoning on every run that disagreed. Measuring costs about a cent a run and executes nothing.

“This rule alone” is the default and answers whether your text does what you mean. “With the active rules” answers what the deployment would do, where another rule can win the citation. A measurement is bound to the judge model and the exact prompt it was taken under; if either changes the panel says so. Saving a rule with a current measurement of that exact draft records it in the rule’s history. Nothing here blocks a save.