Make operating rules
part of execution.

An organization can delegate work to agents while making its operating rules conditions of execution. Those rules can apply across workers with different models and plans, and their decisions can leave records for independent review. Chio provides the kernel checks and signed evidence; the organization defines the controls and deploys the paths that enforce them.

In your project, agents may prepare price changes while publishing a deep discount stays with your pricing lead. A control makes that division binding on the governed call: pricing.discount above 40 percent requires the pricing lead’s approval bound to the exact SKU and percentage, and a call without one never reaches the tool.

The work starts with the paths. Identify the tool, the resource owner, the reviewer, and every route by which publication can happen, then put the control on each of them. A policy file states the intended rule; the deployed application and host make sure the operation encounters it.

Chio evaluates the configured requirements for every mediated call. The surrounding application supplies the reviewer interface, durable records, key handling, and operating procedures. The control is that combination, and each part can be inspected on its own.

A route to an action includes the calls that come before it. Separation of duties involves the agent that asks and the people who approve. A deployment rule depends on what ran earlier in the session. A data rule follows information from the call that read it to the call that sends it. Chio enforces each of these as a decision on the consequential call, and each decision leaves a signed record.

Separation of duties says that no single agent or person both requests spending and approves it. A threshold approval makes that a condition of execution. The policy names the eligible approver keys and a threshold, such as two of three, and can refuse a vote from the key that submitted the request. The kernel holds the call as a pending admission, counts one signed approval per distinct eligible key against the exact proposal, and returns the call to admission only when the threshold is met. The completed call’s signed receipt names its admission operation; the kernel retains the proposal with that operation, and the approval collector’s store keeps the counted votes.

A deployment rule says the deploy tool runs only after the test tool has run in the same session. A sequence rule states it, with required_predecessors mapping the deploy tool to the test tool. The kernel records each governed call in the session journal, and before dispatch the behavioral-sequence guard denies a deploy whose predecessor has no record. The deny receipt names that guard. The rule establishes that a test call is on record; a deploy that must wait for passing tests also needs a check on the test result, which the application supplies. Rules across a session covers the other order and volume rules.

A data rule says records from the customer system never reach the analytics vendor. The tools that read that system declare an output_label it owns, and the vendor’s upload destination has a destination clearance that does not retain that owner. Each read joins its information label into state the kernel retains for the principal, its delegation lineage, and the session, so a send three calls later is still checked against it.

Before the send reaches the vendor, the kernel compares that state with the clearance and refuses. On a kernel built with active defense, the signed deny receipt names the chio-flow-pre-invocation guard and records the flow denial as its evidence. An approved exception is a declassification grant, signed and bound to one request, destination, and purpose.

Rule v1 stops publication before dispatch. Rule v2 requires an approval for the named report, and when that exact approval is supplied, the request reaches the tool. The path and the retained attempt change together.

The record keeps the last six evaluated attempts with their original inputs, so a blocked attempt and an admitted one sit side by side. Versioned rules identify the configuration that produced each decision. Exercise both the permitted and the refused paths, and keep their inputs and results with the configuration that produced them.

The policy guide is a small executable starting point: block a tool, observe the preflight refusal, restore access, and observe Allow. Preflight checks policy without dispatching the tool, so a consequential workflow still needs its own execution and outcome observations.

Choose “Bound approval,” open the request details, and change the target to report-43 while the approval still names report-42. Evaluate the edited request: the approval no longer matches, and the dispatch boundary stays closed.

The captured oversight run below shows the same property in Chio’s approval code. When the approval guard holds a call, it stores a request with an identifier and a hash of the exact call: server, tool, and arguments. A reviewer’s decision is a signed token, and resume accepts it only when the token names that request, carries that hash, comes from an approver the request trusts, falls inside its validity window, and verifies. A token for any other action is refused, and the request stays pending for the right one. Once a decision resolves the request, presenting it again is refused, so one signature cannot authorize a second run.

Approval is one requirement among several. The request still needs an appropriate grant and must pass its other configured guards and budgets. A signed decision cannot supply a missing payment adapter or authorize an unrelated tool. Revocation works forward: in the run, revoking the capability denies the next call, and the call that already ran stays counted.

A refusal before dispatch and a refusal at the output stage leave different records. The first can leave the handler untouched. In the second, the tool may already have produced an effect before its output was rejected.

Choose “Rejected output” to see the second history. Admission succeeds, the handler runs, and the output check refuses the result. The drawing keeps the tool effect between those two boundaries, which a single “denied” badge would erase. A reviewer needs the inputs and the observations of execution beside the decision.

Choose “Bound approval” again, then edit the request to omit an independent outcome observation. Evaluate it and compare the new record with the earlier one: both may permit execution, and only one supplies the observation. Each original record stays intact. Permission, execution, and success are separate claims. A useful record lets the reviewer tell them apart.

The oversight run writes its record as it goes: the approval request when the call is held, the reviewer’s decision when it resolves, and a signed receipt for each call the kernel evaluates, the approved call and the one stopped after revocation. The operation records this evidence as each stage completes.

A signed receipt lets a verifier check a record against a signing key. The verifier still decides which keys it trusts and which claim the record supports. A valid signature establishes who signed the record; it does not establish every external fact the application mentions.

A package also has a scope. It may omit historical calls or lack a checkpoint publication. Retain the capture window, the relevant policy context, the expected coverage, and the verification material, so the recipient can assess the account it actually received.

Another party can inspect the exported files under its own trust requirements and determine which conclusions the evidence supports.

An organization can extend delegated work to more applications while keeping its controls in their execution paths. By retaining each governed decision, it builds an account of the rules applied and the work authorized as agents and responsibilities change.

Review the versioned rules alongside refusal tests, bound approvals, and retained records. Assess the wider control against its deployment scope and operational evidence.

A bound approval establishes that a trusted reviewer accepted this exact call before it ran. It does not establish that the reviewer was the right person, that the tool did what was asked, or that the outcome was correct; each of those needs authentication, execution observations, or outcome evidence of its own. Revocation stops later calls under the capability. It does not reverse a completed effect or cancel arbitrary remote work.

The recorded run uses a local reviewer key and a process-local approval store, and receives approve or deny as an argument. An application must authenticate its reviewer, protect the reviewer’s key, provide the review interface, and retain decisions durably. A rule in code governs the paths that route through the kernel; a path around it is outside both the control and the record.