Actions outpace accountability
Rules live in prompts, spreadsheets, Slack threads, scripts, and manual approvals after the system has already moved.
Decide returns yes, no, or review before your product, agent, queue, or internal tool changes state, with evidence, request_id, decision_id, and replay.
Request
{
"question": "Approve 15% annual-plan discount exception?",
"mode": "single",
"context": {
"workflow": "pricing_exception",
"margin_floor": "passed",
"owner_rule": "verified"
}
}
Response
{
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount"
}
Why now
Agents, queues, billing systems, and internal tools now change state on their own. Decide gives each action a recorded verdict before it happens.
Rules live in prompts, spreadsheets, Slack threads, scripts, and manual approvals after the system has already moved.
/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.
First wedge
Pricing exceptions are the first proof, not the whole category. They make the value obvious: revenue is at stake, ownership is clear, and the decision record must travel before CRM or billing changes.
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.
request_id, decision_id, and evidence stay attached, so later review is a 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.
Flagship proof run
This is the canonical buyer wedge: one high-friction software action, one owner, one guardrail set, one auditable decision record that downstream systems can trust.
Approve 15% annual-plan discount for a growth account?
Decide evaluates the context your software would otherwise scatter across policy docs and human review.
{
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount"
}
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.
request_id, decision_id, hashes, and evidence are stored next to CRM or billing state.
Runtime contract
Decide should feel like infrastructure, not another dashboard. Send context and guardrails, then receive 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",
"margin_floor": "passed",
"owner_rule": "verified"
}
},
"response": {
"verdict": "yes",
"request_id": "req_9f3c",
"decision_id": "dec_43b2",
"evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
"action": "approve_discount",
"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 API contract your system can call repeatedly.
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.
request_id travels with the decisionRefund, cancel, return, trial, access, and routing checks use the same verdict contract 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.
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 contract their existing system calls 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 stable handle 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 contract, 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 a verdict, request_id, and evidence trail.
Store the response next to the action, audit trail, memo packet, reference application output, or execution record.
Run the sandbox, copy an integration path, then request production access for one action boundary.
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 stays contract-led 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.
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 contract-defined 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 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 procurement or fit review? Book optional fit call.
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 [email protected].
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 and spend stay explicit.
Estimate monthly review-time effect for one decision boundary and compare it against your selected plan cost.
Reference scenario (assumption-based): 5,000 records/month × 12 review minutes × 15% review-time reduction × $25/hour ≈ $3,750/month review-time impact before error-rate reduction.
Formula: hours saved = (records/month × avg review minutes ÷ 60) × reduction%; labor savings = hours saved × loaded hourly cost; net impact = labor savings - plan cost.
Payback estimate appears after input values are applied.
Modeled estimate only. Use your baseline and measured decision-outcome deltas for procurement decisions.
Run intake-to-rollout operations from one place: commercial readiness checks, runtime telemetry, and launch actions.
These checks confirm intake delivery, checkout links, booking path, and confirmation channel for production rollout.
Launch paths wired directly to your configured links.
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.
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.
The value is not a prettier form. It is the repeatable contract between a decision, its evidence, and the action that follows.
The same input returns the same verdict: yes, no, or review.
Every call gets a request id 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.
The playground proves the record shape. Production access adds the operating controls your system needs before it relies on Decide at a live action boundary.
Run a real action boundary in the sandbox and confirm the fields your product will store: verdict, request_id, decision_id, evidence, and action.
Run sandboxMap the response to the software action that follows, so downstream state changes keep the decision handle and evidence trail.
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 contract, visible controls, and documented incident paths.
Start with one production boundary, one verdict contract, and one replayable evidence trail.
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. Updated daily via automated 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: February 2026
decide provides deterministic decisioning infrastructure for systems, agents, queues, and internal tools, including API calls, reference validation, and audit trails.
What we process: request inputs and outputs needed to run your call. Local validation history and saved cases are stored in your browser unless you use authenticated account features.
What we don't do: we do not sell personal data and we do not use your prompts to train public models.
Operational logs: we may keep service logs (for uptime, abuse prevention, and debugging) with limited metadata such as timestamp, route, status, latency, and hashed request identifiers.
Questions? Email [email protected].
Last updated: February 2026
Service scope: decide offers deterministic decisioning infrastructure, including the Decision API, reference applications, validation tools, and audit trails.
No professional advice: outputs are informational and may be incomplete. They are not financial, legal, or medical advice.
Safety policy: certain high-risk prompts may be blocked (for example financial/legal/medical asks) and the UI will return an explanatory message.
Your responsibility: you are responsible for downstream decisions and integrations that use decide responses.
Availability: features may change, and uptime is best-effort while the platform evolves.
What you can use today
• Decision API for deterministic yes/no/review routing
• Request IDs, evidence arrays, replayable audit trails, 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 [email protected].
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: [email protected]
If you're sharing a validation issue, include your run snapshot link so we can debug quickly.