Developer docs · Design guidance
Separate automation from authority.
A rule can explain a proposed outcome. An approval establishes who accepted it, against which evidence, and for which record revision.
Roadmap boundary. Configurable production rules, policy administration, automated approvals, provider actions, and webhooks are discovery or roadmap work. The current source contains a bounded local approval foundation, not a public rules product.
Control layers
| Layer | Responsibility | Must not imply |
|---|---|---|
| Rule evaluation | Apply deterministic conditions to the current revision and explain each result. | Permission to change a record. |
| Suggestion | Prepare a bounded proposed correction or next action. | An accepted or executed decision. |
| Approval | Record an authorised person’s decision against current evidence. | Provider acceptance. |
| Local release | Persist the operation, audit evidence, and outbox intent atomically. | Booking, label, manifest, writeback, or notification. |
| Provider execution | Submit and reconcile an external side effect. | Available functionality; this remains future work. |
Recommended evaluation contract
- Identify the active policy version and exact record revision.
- Evaluate ordered, deterministic conditions.
- Return named passes, failures, and warnings with safe explanations.
- Show the proposed outcome without applying it.
- Require the configured authority when the decision is consequential.
- Reject stale evidence and changed input.
- Record the accepted decision before any local release.
Approval invariants
- The approver must be authorised for the current workspace and operation.
- An actor must not satisfy a separation-of-duties rule merely by repeating the same approval.
- Approval evidence must identify the policy context and current revision.
- A changed correction invalidates approval that depended on the old input.
- An assistant suggestion or confidence score cannot stand in for human authority.
Change management
A future production rules surface should support draft, review, simulation, versioning, scheduled activation, rollback, and an audit trail. Existing decisions remain attached to the policy version that produced them; a later rule edit must not silently rewrite history.
See validation and evidence and the operator-focused rules and approvals help article.