Discounts are decisions with margin risk.
A 15% exception can be fine or reckless depending on plan, term, owner, and margin floor. Decide makes the rule check explicit before the action lands.
Send context and guardrails before CRM, billing, agents, or queues change state. Start with pricing exceptions: get yes / no / review, evidence, IDs, and replay in one Decision Record.
First-boundary loop: name the action, send the context, map the verdict, store the record.
curl -X POST https://decide.fyi/api/decide -d @pricing_exception.json
Request
{
"question": "Approve 15% annual-plan discount exception?",
"mode": "single",
"context": {
"workflow": "pricing_exception",
"source_record_id": "deal_1042",
"requested_action": "approve_discount",
"margin_floor": "passed",
"owner_rule": "verified"
}
}
Response
{
"decision_record_version": "decision_record_v1",
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount",
"action_binding": {
"system": "pricing_exception",
"resource": "deal_1042",
"proposed_action": "approve_discount"
},
"policy_id": "pricing_exception",
"policy_version": "v3",
"policy_bundle_hash": "b81c...",
"record_hash": "7f3a...",
"receipt_hash": "c91e...",
"verify_url": "/api/decision/dec_43b2/verify",
"replay_url": "/api/decision/dec_43b2/replay"
}
First production boundary
Pricing exceptions are the first production boundary, not the whole category. Bad exceptions leak margin; unrecorded approvals become audit archaeology. The record must travel before CRM or billing changes.
Now onboarding first-boundary pricing-exception pilots: one workflow, one server-side gate, one measured outcome path.
A 15% exception can be fine or reckless depending on plan, term, owner, and margin floor. Decide makes the rule check explicit before the action lands.
The first integration does not require a new department. It sits where decision policy, CRM metadata, and billing changes already meet.
decision_record_version, decision_id, record_hash, receipt_hash, policy version, and evidence stay attached, so later review is a verification or replay instead of a retrospective search.
Once the decision record is trusted for pricing, the same pattern extends to access changes, eligibility, routing, payouts, reference applications, and execution gates.
Who owns this boundary
Decide gives each team one artifact to inspect instead of asking them to trust scattered CRM notes, workflow branches, and chat approvals.
Defines the request path, review owner, and where the Decision Record is stored.
Sets margin, packaging, approval, and escalation rules for exceptions.
Checks whether exceptions preserve revenue quality and clean audit evidence.
Adds the server-side call before CRM or billing state changes.
Uses security, status, terms, and verification artifacts before rollout expands.
Plain example
CRM is about to update the deal. Decide checks margin floor, customer tier, policy version, and owner approval rules. It returns review, stores the evidence, and gives RevOps a replayable Decision Record before billing changes.
Pilot proof structure
This is the structure for first paid rollouts. It stays synthetic until real customer data is approved for publication.
Discount approvals live across Slack, CRM notes, manager memory, and spreadsheet exceptions.
CRM or billing calls Decide before applying the pricing exception.
Each exception gets a verdict, evidence, owner rule, hashes, replay, and execution receipt.
Review time, margin exception rate, routed decisions, and closed-won/lost outcomes feed the readout.
Try the pricing-exception boundary, inspect the returned record, then copy cURL, JavaScript, or Python when the shape fits.
Sandbox calls are for integration design. Production keys add auth, quotas, telemetry, replay visibility, and commercial controls.
Each preset changes the action context sent to the Decision API.
pending
Recorddecision_id pending
Replaypending
Actionwaiting
The value is not a prettier form. It is the repeatable API boundary between a verdict, its evidence, and the action that follows.
The same input returns the same verdict: yes, no, or review.
Every call gets a replay URL and durable record hash so teams can inspect, rerun, and attach outcomes.
Each request is scoped to current context, so old chat drift does not leak into production decisions.
Response fields are compact and easy to route into products, automations, queues, agents, and MCP tools.
Reference applications show how the same primitive gates source-backed policy, pricing, and execution workflows.
Start with one production boundary, one recorded verdict, and one replayable evidence trail.
Decision API
Decide should feel like infrastructure, not another dashboard. Send context and guardrails, then receive yes, no, or review with a decision record your system can store, replay, and attach to the action that follows.
{
"endpoint": "/api/decide",
"request": {
"question": "Approve 15% annual-plan discount exception?",
"mode": "single",
"context": {
"workflow": "pricing_exception",
"source_record_id": "deal_1042",
"requested_action": "approve_discount",
"margin_floor": "passed",
"owner_rule": "verified"
}
},
"response": {
"decision_record_version": "decision_record_v1",
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount",
"policy_id": "pricing_exception",
"policy_version": "v3",
"policy_bundle_hash": "b81c...",
"record_hash": "7f3a...",
"receipt_hash": "c91e...",
"verify": "/api/decision/dec_43b2/verify",
"replay": "/api/decision/dec_43b2/replay"
}
}
Pick the moment where software needs a deterministic answer before it changes state. Production access is keyed, metered by monthly decision records, and scoped to live action boundaries.
Reference applications prove the runtime shape; production value comes from the Decision API your system can call repeatedly.
Decision lifecycle
One API call gates the action before state changes. When the workflow becomes production-critical, the same trail can add execution receipts, outcomes, intelligence, and a portable Decision Packet.
Name the action, send context, get yes, no, or review with evidence before state changes.
Record the attempted mutation, target object, executor, and state hashes when the action is attempted.
Link the business result and observed metrics back to the original decision.
Use outcomes to score effectiveness, confidence, benchmarks, and explainable anomalies.
Export the record, receipts, outcomes, and verification hints when a buyer, auditor, or support reviewer needs proof.
Outcome Records show which policies succeed, fail, route to review, or lack enough terminal signal.
Similar caller-scoped outcomes create confidence baselines before the next action is allowed.
Deterministic reports flag unusual decisions with reason codes, severity, baselines, and recommendations.
Opt-in cohorts, Decision Packets, and audit chains turn proof into a portable operating artifact.
Why now
Agents, queues, billing systems, and internal tools now change state before teams can reconstruct why. Decide gives each action a recorded verdict before it happens.
A wrong discount, access grant, refund, or payout can land before the owner rule and policy evidence are attached.
/api/decide turns context and guardrails into a decision record your system can store with the action.
Every call creates replayable evidence. Over time, the decision record becomes the system of record for why software acted or stopped.
Flagship proof run
The risky moment is not the discount request. It is CRM or billing changing state before margin, owner, and evidence checks are attached.
Approve 15% annual-plan discount for a growth account before the billing update lands?
Decide checks the facts that usually live across CRM fields, policy docs, and human review before the action can proceed.
{
"decision_record_version": "decision_record_v1",
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount",
"policy_id": "pricing_exception",
"policy_version": "v3",
"policy_bundle_hash": "b81c...",
"record_hash": "7f3a...",
"receipt_hash": "c91e...",
"verify_url": "/api/decision/dec_43b2/verify",
"replay_url": "/api/decision/dec_43b2/replay"
}
dec_43b2 can be replayed against pricing_exception:v3.
Replay compares verdict, evidence, and record hash, so review is anchored to the original policy run instead of screenshots, chat history, or memory.
The playground proves the record shape. Production access adds keys, quotas, telemetry, and replay visibility for the one action boundary your system is ready to gate.
Run a real action boundary in the sandbox and confirm the fields your product will store: verdict, IDs, action binding, policy version, evidence, receipt hash, verify URL, replay URL, and action.
Run sandboxMap the response to the software action that follows, so downstream state changes keep the full Decision Record v1 object attached.
View proof artifactRequest keyed access, choose the monthly record tier, and launch one production boundary with auth, quotas, telemetry, and replay visibility.
Request accessDecide should be easy to test publicly and boring to approve privately: one API surface, visible controls, and documented incident paths before live usage.
Start with the API docs and examples, then verify the artifact shape before production access.
Use the pricing proof, plan, and security packet to approve one production action boundary.
Why not hard-code this?
Decide is useful when the same action boundary touches CRM, billing, queues, agents, or internal tools and the reason needs to survive outside the code path that made the call.
Products, queues, and agents can call the same API instead of each team reimplementing the rule and escalation path.
Decision ID, evidence, policy version, record hash, verify URL, and replay URL stay beside the downstream state change.
Teams can replay a stored decision, compare drift, and verify hashes instead of reconstructing intent from scattered code and logs.
Execution receipts and Outcome Records show what was attempted and what happened after the verdict, creating evidence hard-coded rules rarely keep.
Production questions
The production path is intentionally narrow: keep the existing workflow, add one Decision API call before the state change, and store the record with the action.
No. Decide sits before the existing CRM, billing system, queue, agent, or internal tool changes state.
Decision Record v1: verdict, IDs, evidence, action binding, policy version, record hash, receipt hash, verify URL, replay URL, and the action that followed.
Your product routes, holds, or blocks using the same verdict and record instead of inventing another approval surface.
Keyed API calls, monthly record tiers, quotas, telemetry, replay visibility, security docs, and launch support by plan.
Expansion path
The API can gate any bounded software action. Start with one expensive boundary, then expand as teams trust the record.
Approve, deny, or escalate discount and packaging decisions before billing or CRM state changes.
record_hash and receipt_hash travel with the decisionRefund, cancel, return, trial, access, and routing checks use the same verdict shape once one boundary is trusted.
Agents, wallets, queues, and internal tools can require a Decide response before value moves or state changes.
Proof surfaces
Use these only after the core idea is clear: one API call returns a record your system can store.
Run the sandbox, copy an integration path, then request production access for one action boundary.
Production integration
A customer does not need a new workflow portal to understand Decide. The first production proof is whether one existing software action can require a deterministic decision record before it changes state.
Sales, RevOps, CRM, or billing emits a request that should not auto-apply without guardrails.
workflow, owner rule, margin floor, account segment, plan term, and source metadata become the payload.
yes, no, review, or escalation maps to proceed, block, route, or hold.
The full Decision Record v1 object is stored next to CRM or billing state, including policy version, record hash, and replay URL.
Who buys first
The first buyer already has a workflow where a wrong action costs money or trust. Decide wins when it becomes the small Decision API call their existing system makes before that action happens.
Guard margin, owner rules, and packaging exceptions before CRM or billing changes land.
Budget signal: revenue quality.Require a verdict before automations execute, route, refund, grant access, or move value.
Budget signal: automation safety.Keep a deterministic reason attached to the action, not buried in a chat thread or spreadsheet.
Budget signal: review and dispute cost.The surface area stays small on purpose. Every integration gets the same durable fields instead of another bespoke workflow UI.
A deterministic yes, no, review, or ranked outcome that downstream systems can route without inventing a new decision process.
A versioned record for every call, so the decision can be replayed, inspected, stored, escalated, or attached to another system.
Rules, source fields, rationale, and checks that explain why the verdict happened and what changed the outcome.
The same input can be tested again against the same API version, making QA, compliance review, and dispute response much less vague.
Start where a product, agent, queue, or internal tool already needs a clear verdict before action.
Pick one decision boundary, required context, guardrails, and the output your software needs before it acts.
Send the payload to /api/decide and receive Decision Record v1: verdict, IDs, evidence, policy version, record hash, and replay.
Store the response next to the action, audit trail, decision artifact, reference application output, or execution record.
Simple model: run Evaluate for free validation, then buy a Production API tier by monthly decision records (10k -> 50k -> 200k) and live action boundaries. Annual billing saves 20%, and burst packs handle temporary spikes.
Use docs and runtime references to test deterministic outputs and request-linked evidence fields.
Choose by monthly decision records, then by how many production action boundaries need to require a Decide verdict. Enterprise uses commercial contract terms when governance and procurement controls are strict.
Up to 10,000 records/month
Self-serve production Decision API.
Up to 50,000 records/month
Growth tier for multiple boundaries and faster launch support.
Up to 200,000 records/month
For multi-team governance, procurement review, and strict enterprise controls.
Decision Records, execution receipts, Outcome Records, and self-serve packet export for the first production boundary.
Policy effectiveness, confidence, and explainable anomaly reports turn observed outcomes into rollout decisions.
Benchmarks, packet review, audit-chain governance, and the security package support procurement and multi-team rollout.
Compare decision scope, delivery model, rate-limit envelope, and expansion path before you request access. Default delivery is remote integration handoff (not on-site services).
| Plan | Price | Delivery model | Monthly decision scope | Rate-limit envelope | Overage / expansion | Support + uptime terms |
|---|---|---|---|---|---|---|
| Evaluate ($0) | $0 | Sandbox + live demo validation only. | No production usage. | Shared demo limits; no contractual uptime terms. | Move to API Starter, API Team, or API Enterprise for production. | No production uptime terms. |
| API Starter (from $299/mo) | From $299/mo | Standalone keyed /api/decide access. |
Up to 10,000 decision records/month for one live boundary. | Default Starter envelope: 20 req/min per API key (returned in x-ratelimit-*). |
Use burst packs (+10k/+25k/+50k) or upgrade to API Team. | Self-serve runtime with docs-first implementation handoff. |
| API Team (from $1,199/mo) | From $1,199/mo | Quote-based API runtime with included implementation support. | Up to 50,000 decision records/month across multiple boundaries. | Higher commercial contract envelope than Starter. | Use burst packs or move to Enterprise for stricter governance and larger envelopes. | Launch support + contracted uptime terms + implementation support included. |
| API Enterprise (from $3,999/mo) | From $3,999/mo | Enterprise runtime with included rollout/governance support. | Up to 200,000 decision records/month and/or strict multi-team controls. | Custom throughput and uptime envelope by commercial contract. | Further custom tiers above 200k/month as volume and controls expand. | Full procurement/security package and enterprise support model with implementation support included. |
Need first-boundary review? Book a pricing-exception workflow review.
Yes. Choose API Starter for direct API runtime access, add burst packs for temporary spikes, or move to Team/Enterprise for larger envelopes and controls.
You land on /payment/success with handoff steps, and receive kickoff confirmation by email. If missing after 10 minutes, check spam/promotions and contact support@decide.fyi.
No. Evaluate is for runtime testing and payload validation only. Production usage starts with API Starter (or higher API tiers).
Usually when monthly volume approaches or exceeds 200,000 decisions, when multi-team governance is required, or when procurement/compliance controls need custom contract terms.
Modeled estimate: Typical adoption starts with one product or internal workflow creating 3,000-5,000 decision records/month. Base-case review-time impact is often $6k-$9k/month before error-rate reduction. Production runtime starts on API Starter, API Team, or API Enterprise.
Use assumption-based decision-volume math before commercial commit so upside, spend, and payback assumptions stay explicit.
Estimate monthly review-time effect for one decision boundary and compare it against the selected pilot or plan cost. This is a planning model, not a savings guarantee.
Reference scenario, not a promise: 5,000 records/month × 12 review minutes × 15% handle-time reduction × $25/hour ≈ $3,750/month modeled review-time impact before error-rate reduction.
Formula: hours saved = (records/month × avg review minutes ÷ 60) × reduction%; estimated monthly impact = hours saved × loaded hourly cost; net modeled impact = estimated impact - plan cost.
Payback estimate appears after input values are applied.
Modeled estimate only. Use your baseline, pilot records, and measured decision-outcome deltas before treating any impact number as procurement evidence.
Use Console as an evaluation and onboarding path: describe the workflow, map the first boundary, run proof, then request production access when the fit is clear.
Evaluation Console
Tell us the software action you want to control. The mapper turns it into a first Decide boundary, relevant evidence fields, artifacts, and docs to review.
This is an evaluation aid, not production/legal/security advice. It only maps to documented Decide patterns.
Start with the action that changes state: CRM update, billing mutation, support refund, queue job, or agent tool call.
Paid rollout controls confirm intake delivery, checkout links, booking path, and confirmation channel for production rollout.
Use these when the evaluation is ready to become a first-boundary rollout.
Use your x-metrics-token to load 24h runtime metrics and export the rollout scorecard snapshot.
| Top event (24h) | Count |
|---|---|
| Load metrics to view top events. | |
Build a concise rollout brief from current readiness checks and telemetry. Use this for customer updates and weekly rollout readouts.
No report generated yet.
Refund, cancel, return, and trial checks show how clients can consume deterministic verdicts with stable endpoints, source links, and replayable evidence.
Registry links, MCP install URLs, REST endpoints, and source references remain on *.decide.fyi. This is a preserved reference application for the broader Decision API.
Stable Decide runtime for refund eligibility checks. Returns ALLOWED, DENIED, or UNKNOWN based on each vendor's official refund policy window.
Stable Decide runtime for cancellation penalty checks. Returns FREE_CANCEL, PENALTY, or LOCKED based on each vendor's cancellation terms.
Stable Decide runtime for return eligibility checks. Returns RETURNABLE, EXPIRED, or NON_RETURNABLE with return type and method.
Stable Decide runtime for trial terms checks. Returns TRIAL_AVAILABLE or NO_TRIAL with trial length, card requirement, and auto-conversion status.
Run the stable Decide reference remotes, inspect deterministic responses, and keep a scoped audit trail for QA and incident review.
Run a request to see output.
| Time (UTC) | Reference app | Mode | Status | Latency | Req hash | Actions |
|---|
Add the stable Decide reference remotes to any MCP-compatible client.
{
"mcpServers": {
"refund-decide": {
"url": "https://refund.decide.fyi/api/mcp"
},
"cancel-decide": {
"url": "https://cancel.decide.fyi/api/mcp"
},
"return-decide": {
"url": "https://return.decide.fyi/api/mcp"
},
"trial-decide": {
"url": "https://trial.decide.fyi/api/mcp"
}
}
}
curl -X POST https://refund.decide.fyi/api/mcp \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "refund_eligibility", "arguments": { "vendor": "adobe", "days_since_purchase": 12, "region": "US", "plan": "individual" } } }'
curl -X POST https://refund.decide.fyi/api/v1/refund/eligibility \ -H "Content-Type: application/json" \ -d '{"vendor":"spotify","days_since_purchase":5,"region":"US","plan":"individual"}'
Deterministic outputs, no hidden state, and stable remotes for products that build on Decide.
Same input, same output. Every time. Fully auditable decisions your agent can cite.
No sessions, no tokens, no stored data. Pure function over HTTP.
JSON-RPC 2.0 over HTTP POST. Works with Claude Desktop, Cursor, and any MCP client.
Adobe, Netflix, Spotify, Microsoft 365, and 96 more. Checked every 6 hours via automated source checks.
Reference validation runs sandbox-first; production Decision API access uses explicit keys and commercial runtime controls.
Full reference rules, source links, and server code on GitHub. Verify everything.
Use the proof surfaces to validate the primitive, then integrate Decide where your workflow needs deterministic verdicts.
Last updated: May 21, 2026
decide handles account data, API request data, payment metadata, local browser data, logs, and support messages for the site, API, checkout, source-alert, and support workflows.
What we don't do: we do not sell personal data and we do not use customer prompts or decision inputs to train public AI models.
Last updated: May 21, 2026
decide provides deterministic decisioning infrastructure, reference applications, API keys, records, replay, documentation, and support workflows. Production use depends on your plan, API access terms, or signed agreement.
Important limit: outputs are operational decision records, not financial, legal, medical, employment, or professional advice.
What you can use today
• Decision API for deterministic yes/no/review routing
• Decision Record v1 with IDs, evidence, action binding, policy version, record hash, receipt hash, verify URL, replay URL, and production status surfaces
• Reference applications that show how the same primitive gates policy, pricing, and execution workflows
Best for
• Systems and agent workflows that need deterministic verdicts
• Teams that need reproducible run history and troubleshooting context
Integration help: contact support@decide.fyi.
Share one decision boundary, expected volume, and success metric. Pick API Starter/Team checkout, Enterprise review, or guided implementation.
For product feedback, integrations, or partnership requests:
• X: @decidefyi
• Email: support@decide.fyi
If you're sharing a validation issue, include your run snapshot link so we can debug quickly.