Policies
All nine verified policy methods with nested rule expressions.
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:
- rejects with the exact referencing resources; or
- accepts one separately authorized atomic change that explicitly reassigns/removes every reference before deletion.
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 });
page = await sdk.get_policies(GetPoliciesInput(organization_id=organization_id))
operation = await admin.delete_policy(DeletePolicyInput(
organization_id=organization_id,
request_id=request_id,
policy_id=policy_id,
expected_version=expected_version,
))
page, err := sdk.GetPolicies(ctx, &GetPoliciesInput{OrganizationID: organizationID})
if err != nil { return err }
operation, err := admin.DeletePolicy(ctx, &DeletePolicyInput{
OrganizationID: organizationID,
RequestID: requestID,
PolicyID: policyID,
ExpectedVersion: 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#
- Positive: all four verified reads and five verified mutations are present, including singular/batch variants and evaluation history.
- Positive: rule nesting, policy definition, wallet assignment, actor rights, approval and execution remain distinct.
- Negative: no standalone Rule CRUD is fabricated; deletion cannot silently unprotect a wallet; stale or incomplete approval cannot change policy.
See createPolicy, updatePolicy, updateWallet, and Approvals.