Policy Pattern Catalog

Start from a decision pattern before your system changes state.

The pattern catalog is intentionally first-party and practical: versioned templates for common Decision API boundaries, with request shapes, outcome hints, CRM sync hints, and SDK examples tied back to the public registry.

Open registry JSON View code examples Integration guides Request API access
decision_pattern_registry_v1 decision_pattern_v1 First-party templates No community claims yet

Pattern adoption packet

Use this packet before adopting a pattern in production. A pattern is not just a sample payload; it should define the action boundary, the lifecycle artifacts to store, and the proof a reviewer can verify after launch.

Choose

Match one boundary

Select the closest first-party template for the first state change, then replace source identifiers and owner rules.

Bind

Name the mutation

Attach target system, target object, requested action, risk context, and idempotency before calling /api/decide.

Prove

Record lifecycle evidence

Capture the Decision Record, Action Execution Receipt, Outcome Record, and Decision Packet v1 for the first live run.

Review

Verify before expanding

Use the hosted verifier or SDK verifier before applying the template to another production boundary.

First-party catalog

These patterns are adoption accelerators, not a replacement for your own policy. Choose the closest template, replace the source identifiers and owner rules, then send the final payload through /api/decide.

RevOps

Pricing Exception Gate

Approve, block, or route a discount or pricing exception before CRM or billing changes state.

pricing_exception CRM Billing
Billing

Refund Review Gate

Route a refund request before billing, automation, or account tooling issues a credit.

refund_review Refunds Risk
Agents

Agent Action Gate

Authorize an agent-proposed action before a tool, workspace, account, or external system is mutated.

agent_action_gate Tools Execution
CRM

CRM Write-Back Gate

Call Decide before a CRM update, then record the CRM sync receipt after fields are written back.

crm_writeback_gate Salesforce HubSpot

Pattern lifecycle contract

Every first-party pattern should lead to the same lifecycle proof path. The template helps with payload shape, but the durable value comes from the records that follow the action.

Pattern fieldHow to use itReviewer signal
decision_request_templateStarter payload for POST /api/decide, with workflow, source record, requested action, and context slots.Decision Record v1 includes verdict, evidence, hashes, policy version, replay URL, and verify URL.
outcome_templateStarter shape for reporting what happened after the action finishes or routes to review.Outcome Record links observed metrics and status back to the original decision.
crm_sync_templateStarter shape for CRM write-back receipts when the pattern stores decision fields on a source object.CRM Sync receipt proves mapped fields were written back without storing CRM credentials in Decide.
sdk_examplesPackaged examples that show the call path and fail-closed handling for the template.Implementation reviewers can compare code against the public first-hour examples.
pattern_hashCanonical hash of the normalized pattern, useful for detecting local template drift.Reviewers can see whether the team changed the template before launch.
Decision Packet v1Export the first live run after the pattern is wired.Portable proof contains the Decision Record, execution receipts, Outcome Records, policy intelligence, audit-chain metadata, and verification hints.

Pattern

Pricing Exception Gate

Use before a discount, quote exception, or package override updates CRM, billing, or an internal approval state.

pricing_exception Recommended policy v3
Required context

Bind the request

Include workflow, source_record_id, and requested_action.

Recommended context

Name the mutation

Add discount, margin floor, owner rule, target system, target object id, mutation, and expiration.

Evidence codes

Explain the verdict

MARGIN_FLOOR_OK, OWNER_RULE_VERIFIED, and DISCOUNT_WITHIN_POLICY.

Fetch the template
curl -i "https://www.decide.fyi/api/decision/policy-patterns?pattern_id=pricing_exception"
Use with SDK
const { policy_pattern: pattern } = await decide.policyPatterns({
  patternId: "pricing_exception"
});

const record = await decide.decide(pattern.decision_request_template, {
  idempotencyKey: "deal_1042_discount_15",
  responseView: "full"
});

Pattern

Refund Review Gate

Use before refund automation or billing credit paths where unclear outcomes should become review states.

refund_review Recommended policy v1
Required context

Identify the request

Include workflow, source_record_id, and requested_action.

Recommended context

Add policy signals

Pass vendor, days since purchase, region, plan, amount, and customer segment when available.

Evidence codes

Keep review visible

WITHIN_WINDOW, OUTSIDE_WINDOW, NO_REFUNDS, and UNSUPPORTED_VENDOR.

Pattern

Agent Action Gate

Use when an agent proposes an action and your system needs a recorded permission boundary before execution.

agent_action_gate Recommended policy v1
Required context

Bind the agent run

Include workflow, source_record_id, and requested_action.

Recommended context

Describe the tool action

Add agent id, tool name, target system, target object id, mutation, and risk level.

Evidence codes

Authorize explicitly

ACTION_BOUND, OWNER_RULE_VERIFIED, and RISK_ACCEPTABLE.

Pattern

CRM Write-Back Gate

Use before writing a CRM object, then record a CRM Sync receipt after Decision Record fields land on the source object.

crm_writeback_gate Recommended policy v1
Required context

Bind the object

Include workflow, source record id, requested action, target system, and target object id.

Recommended context

Map the fields

Add CRM provider, object type, object id, mutation, and field mapping.

Evidence codes

Prove write-back

CRM_OBJECT_BOUND, DECISION_FIELDS_MAPPED, and WRITEBACK_RECORDED.

Registry contract

The page is the human catalog. The API is the machine-readable contract. Use the registry in setup tools, documentation generators, agents, or onboarding flows.

List patterns by tag
curl -i "https://www.decide.fyi/api/decision/policy-patterns?tag=crm"
SDK registry read
const registry = await decide.policyPatterns({ tag: "crm" });

for (const pattern of registry.patterns) {
  console.log(pattern.pattern_id, pattern.pattern_hash);
}
FieldPurpose
pattern_hashCanonical hash of the normalized pattern, useful for detecting local template drift.
decision_request_templateStarter payload for POST /api/decide.
outcome_templateStarter shape for reporting what happened after the action.
crm_sync_templateStarter shape for recording CRM write-back receipts when the pattern involves CRM fields.
sdk_examplesPackaged examples that show the integration path in code.

Pattern readiness checklist

Before a pattern moves from a starter template into a production boundary, each owner should be able to inspect a concrete artifact.

OwnerConfirmArtifact
Policy ownerThe template matches one exact action boundary and has an explicit review path.Pattern id, pattern hash, policy id, and owner rule.
EngineeringThe call is server-side, idempotent, fail-closed, and stores the full Decision Record.SDK example, integration code, and stored record sample.
OperationsThe first launch has a status/readiness check and quota behavior is understood.Status packet and rollout readout.
ReviewerThe first live run exports and verifies as a Decision Packet v1.Hosted verifier output or npx @decide-fyi/sdk verify-packet output.

What this is not yet

This is the foundation for a marketplace, not a public community marketplace claim. Customer-authored templates, ratings, installs, and effectiveness scores should come only after real adoption data exists.

Included

First-party templates

Decide-maintained patterns that make the first API call easier to shape and review.

Excluded

No unearned network effects

No customer download counts, ratings, community authors, or benchmark claims unless the underlying evidence exists.

Next

Connect to outcomes

Pattern-level effectiveness can become meaningful only when customers report enough Outcome Records.