Flow

Policies and approvals

Pilot separates operator intent, executable policy, semantic interpretation, consent, rollout, and post-action response.

On this page

Choose a control surface

SurfaceUse it forRuntime effect
Signed policy ruleExact node, action, resource, risk, disclosure, amount, destination, or approval behavior.The first matching rule establishes the deterministic ceiling.
Policy statementHuman-readable restrictions such as “Do not accept trust from anyone.”Compiles into reviewed deterministic rules and/or semantic clauses; no effect until rollout activation.
Semantic clauseMeaning that cannot be resolved from exact metadata, such as confidential content leaving the company.A hosted evaluator may deny or request the pinned approval plan; it never grants above the base answer.
Approval planEligible approvers, quorum, validity, approved outcome, and constraints.May create one payload-bound, single-use continuation after quorum.
ProcedureAlert, investigate, quarantine, refresh, export, or notify after an outcome.Runs after durable activity and cannot modify the original authorization.

Governed actions

The managed action vocabulary covers browser navigation; process execution; arbitrary tool invocation; HTTP and webhook requests; data read, export, and text/JSON/binary send; file read, write, delete, and share; event publication; trust request, accept, auto-accept, reject, revoke; wallet payment; and custom registered actions.

Policies also bind the target resource, risk, recipient, purpose, labels, content type, residency, retention class, transaction value, destination, and node scope where relevant. An adapter must report an action before Pilot can govern it. Publishing a rule does not create interception.

Natural-language policy workflow

  1. Create or select an approval-plan revision first if the desired semantic outcome is approval.
  2. Open Policy statements and create a statement with an explicit node scope. * means all nodes in the tenant.
  3. Enter the ordinary-language instruction. Add entity-to-resource bindings when a human name must map to a canonical target.
  4. Select exact action hints for content-sensitive meaning. Semantic fallback is opt-in and limited to the reviewed deny or approval outcome.
  5. Compile the statement. Inspect the source hash, compiler version, deterministic rules, semantic clauses, failure posture, warnings, and unresolved phrases.
  6. Edit and recompile until the interpretation is exact. Unresolved compilation cannot enter review.
  7. Submit review, approve the source, create a signed rollout draft, inspect its diff and simulations, publish it, obtain signed node acknowledgements, and activate it.

A prose sentence is never sent directly to a model as unrestricted authority. It remains a revisioned source object bound to the reviewed compilation and active signed policy revision.

Structured policy workflow

  1. Select the target node or fleet scope.
  2. Choose registered actions, resource prefixes, and applicable risk classes.
  3. Select deny, allow, allow with constraints, or approval required.
  4. For constraints, set maximum value, allowed destinations, and typed disclosure requirements.
  5. For approval, select the exact immutable approval-plan revision.
  6. Enter a title and auditable reason; choose full-fleet or canary rollout and acknowledgement thresholds.
  7. Create the inactive candidate, run diff and deterministic simulation, obtain required independent approval, publish, then activate.

Editing produces a higher immutable revision. Removing a rule is also a reviewed signed change. Rollback creates a new higher revision rather than lowering a node's rollback floor.

Runtime order and composition

  1. Locally pinned trust and mandate define the hard maximum.
  2. The active signed policy evaluates deterministic rules in document order. The first match wins; no match means deny.
  3. An eligible active semantic clause may inspect exact hosted content. Semantic allow preserves the base result; deny or approval may narrow it. A base deny remains deny.
  4. Conflicting semantic approval plans fail closed. Evaluator, model, prompt, policy, clause, timeout, failure mode, and usage metadata are journaled.
  5. The node verifies the final signed result before releasing or blocking the side effect.

No active semantic clause means no model call and no semantic usage charge. High- and critical-risk failure posture should be explicitly fail closed when the business requirement cannot tolerate an unevaluated action.

Approval and continuation

An approval plan is tenant-scoped and immutable by revision. It lists purpose-limited approver keys, required quorum, validity duration, approved outcome, and optional constraints. A transaction binds the exact signed intent and payload hash. Distinct eligible signatures count toward quorum.

Approval is not a reusable exception. Quorum creates one single-use continuation for the same request. Rejection, cancellation, expiry, payload mismatch, agent mismatch, plan mismatch, or replay remains blocked. The node stores payload-free continuation state with exclusive creation and a restart-safe lease so at most one resume attempt can occur.

Examples

Operator statementCompiled or runtime meaning
Don't accept trust from anyone.Deterministic deny for trust.accept and trust.auto_accept on the selected nodes.
Do not transact with Acme.After binding Acme to a canonical merchant resource, deny matching wallet.pay actions.
Do not send confidential material outside the company.Explicit send/share scope plus a reviewed hosted semantic clause that may deny or request security approval.
Finance may pay approved-vendor up to 1,000 USD.Structured node/action/resource rule with amount and destination constraints.

Prove enforcement

  1. Confirm the target node reports a blocking capability for the governed action.
  2. Activate the exact signed policy revision and wait for the node acknowledgement.
  3. Run one allowed action and inspect its complete exchange and post-hook result.
  4. Run a violation with a distinctive inert marker.
  5. Confirm the decision cites the expected deterministic rule or semantic clause.
  6. Confirm the external side effect or marker does not exist.
  7. Test approval, expiry, cancellation, replay, evaluator outage, and hook timeout separately.
Policy presence is not enforcement proof. Pilot's coverage report combines the signed connector capability, action inventory, blocking/approval support, receipts, and recent runtime evidence. Uncovered targets require an explicit audited exception.
← Harness Coverage