Shuttle Docs

Policies

All nine verified policy methods with nested rule expressions.

GroupPolicy catalog and evaluation
RuntimesTypeScript browser/server, React admin mediation, Python/Go server
Updated2026-09-15

Status and scope

Proposed target SDK catalog based on all nine verified public policy methods. Documents createPolicy and updatePolicy remain the detailed single-policy contracts; this page supplies the complete lifecycle and read surface without replacing them.

A policy is a reusable definition evaluated for protected actions. Its rule expressions are nested inside the policy definition. The inspected SDK exposes no standalone Rule CRUD, so no createRule, updateRule or deleteRule method is invented.

Read methods#

Method Meaningful input Result
getPolicy organizationId, policyId one policy definition and version
getPolicies organizationId all visible policies
getActivePolicies organizationId each policy plus whether its time window is currently active
getPolicyEvaluations organizationId, underlying action/approval ID recorded policy evaluations for that action

“Active” means the policy's own time window currently permits evaluation; it does not mean the policy is assigned to every wallet or that a proposed action passes. getPolicyEvaluations is an audit/explanation read tied to one underlying action. Reads create no assignment, approval or protected effect.

Mutation methods#

Method Meaningful input Result or effect
createPolicy requestId, name, effect, nested condition/rules, owner/admin context and approval when required one policy ID/version
createPolicies requestId, one or more complete definitions one batch operation with created policy IDs
updatePolicy requestId, policyId, expectedVersion, complete replacement definition one guarded next version and explicit applicability impact
deletePolicy requestId, policyId, expected lifecycle/version guard one deletion disposition
deletePolicies requestId, policy IDs and guards one batch deletion disposition

All mutations return the shared operation envelope. Batch behavior must state atomic or partial outcomes before implementation; the target default is all-or-explicit-partial, never a success that hides omitted failures.

Definition, assignment and rights#

Creating a definition does not assign it to a wallet. updateWallet owns assignment/removal and signer-right changes. Replacing a definition preserves its stable identity and uses expectedVersion so every assignment observes one defined cutover or remains on the prior version.

Deleting a policy that is still referenced must not silently remove a restriction. The target backend either:

No omission, empty list or failed approval weakens policy. Removing a restrictive assignment is not the same as revoking a user's wallet right, and approval of a policy mutation cannot bypass immutable owner, minimum-approval, recovery or last-authorized-actor guards.

Approvals and evaluation#

Policy evaluation applies to the underlying business action at its defined boundary. Some reads or lifecycle steps may not be policy-controlled, so the catalog does not claim universal evaluation for every state transition. When review is required, Approvals exposes the participant decision; the policy still re-evaluates current ownership, assignment and version at the effect boundary.

An approval response is bound to the exact policy/action fingerprint. It cannot authorize another rule set, assignment, resource or version. Approval is not execution: after authorization the policy mutation or wallet action may still fail and must expose its operation result.

Runtime and authority#

Policy reads may be available within granted scope. Embedded-wallet policy changes require owner/admin authority. Server-wallet policies and transaction/fee limits require service/admin authority and configured approvers. An end-user session or frontend role cannot acquire treasury or policy authority. Secret-bearing administration stays server-side.

TypeScript browser TypeScript server React adapter Python server Go server
Granted reads and explicitly confirmed changes only Full proposed admin target Calls authorized TypeScript core; no policy-admin hook is implied Full proposed server target Full proposed server target
const page = await sdk.getPolicies({ organizationId });
const operation = await admin.deletePolicy({ organizationId, requestId, policyId, expectedVersion });

Failure contract#

Foreign ID, malformed rule, unknown expression version, ambiguous condition, stale expected version, denied/expired approval, referenced deletion, timeout or unavailable evaluator returns a typed non-success. Rejection creates no definition, version, assignment or rights change. Unknown mutation outcome is recovered with the same requestId through getOperation.

Acceptance#

See createPolicy, updatePolicy, updateWallet, and Approvals.