Operational Security

Security posture for production decisions.

This security packet gives buyers, procurement, and security reviewers the current API rollout posture: data boundaries, access controls, verification artifacts, incident paths, and the claims Decide does and does not make today.

Public verification path: status, reference assets, and runtime readiness JSON.

View public status Open verifier API reference Request security review

Buyer-ready summary

Decide is designed to sit before software changes state. The security model is to keep production credentials server-side, return a portable Decision Record, bind records to hashes and signatures where configured, and expose public verification surfaces for exported proof.

Primary asset

Decision Record v1 plus execution, outcome, packet, and audit-chain artifacts.

Primary risk

Incorrectly allowing an irreversible downstream action without a valid record.

Default behavior

Integrations should fail closed or route to review when auth, quota, validation, or runtime checks fail.

Review path

Use status, verifier, OpenAPI, receipt keys, policy bundles, privacy, and terms links below.

Security review checklist

Use this as the first-pass packet for procurement and security review. It maps common reviewer questions to the current public answer and the artifact that supports it.

Reviewer question Current public answer Evidence to inspect
Can Decide sit before a production action? Yes, when the caller stores the Decision Record before the downstream mutation and fails closed or routes to review on auth, validation, quota, or runtime failure. API reference, error docs, and status.
What data should cross the boundary? Only the minimum action context needed for a recorded verdict. Customers should avoid unnecessary personal data, regulated data, secrets, credentials, and full source records. Privacy, data handling, and Terms.
How can a reviewer verify a record later? Use the hosted verifier, API verifier, or SDK CLI to recompute record hashes, receipt hashes, policy bundle hashes, and configured signatures. Hosted verifier, verification docs, and receipt keys.
Can readiness evidence be exported? Yes. The status page links a public readiness JSON and CSV export. The export is an operational readiness snapshot, not a certification report. Status and readiness JSON.
What certification claims are made? No SOC 2, ISO 27001, HIPAA, PCI, or regulated-industry suitability claim is made here unless separately published in a contract artifact. Claims and limits, Terms, and Privacy.
Who owns downstream action safety? Decide returns a decision artifact. Customers own action placement, API key custody, downstream mutation behavior, human-review rules, and local retention requirements. Shared responsibility and API access terms.

Architecture and trust boundary

The caller decides where to place the gate. Decide returns the record before the caller mutates CRM, billing, queues, agents, access, payout, or internal workflow state.

Caller Server-side integration

Holds API key, builds minimal action context, and sends an idempotency key when retry behavior matters.

Runtime Decision API

Evaluates declared context and returns a versioned record with policy, evidence, action binding, and integrity fields.

Storage Customer system

Stores the record next to the action and records execution or outcome receipts after downstream work happens.

Review Verifier

Recomputes hashes and checks signatures or registries for exported records without trusting runtime storage.

Control matrix

Control area Current implementation Buyer note
Identity and access Production API traffic uses server-side API keys. Account and ops UI access use Clerk auth with role-gated ops checks. Do not expose production keys from browser clients. Keep keys in server env or secret storage.
Runtime integrity Decision endpoints return deterministic outputs for identical inputs under fixed declared state. Use replay and rollout scorecards to validate consistency under live production traffic.
Audit traceability Decision Record v1 linkage with request_id, decision_id, record_hash, replay URL, request/response hashes, and status metadata. Designed for QA replay, dispute packets, support escalation, and incident review.
Receipt verification Portable Ed25519 receipt signatures can be checked against the public registry at /api/decision/receipt-keys. Use the hosted or CLI verifier for exported records. Keep HMAC secrets private for internal checks.
Rate and abuse control Baseline production limits and route-level protections are configured for API-key traffic. See /docs.json and error docs for published limits and fail-closed handling.
Operational visibility Public status, runtime readiness, monitor suite, and readiness export endpoints are available for review. Status data is an operational snapshot, not a contractual uptime commitment.

Need a vendor questionnaire response? Include framework (for example SIG Lite or CAIQ), required turnaround, and the action boundary being reviewed.

Shared responsibility matrix

Decide provides the decision protocol and verification surfaces. Customers control where the gate sits, what context is sent, and what downstream systems do after a verdict.

Area Decide responsibility Customer responsibility
API key custody Validate production API keys, enforce API-key scoped access, and support rotation or revocation when needed. Store keys server-side, restrict internal access, rotate on exposure, and keep keys out of clients, screenshots, and repositories.
Payload minimization Publish request schemas, docs, and examples that show the minimum useful action context. Choose fields intentionally and avoid unnecessary personal data, regulated data, secrets, credentials, or full source records.
Action boundary Return a Decision Record with verdict, evidence, policy metadata, hashes, replay hints, and action-binding context. Place the gate before the downstream mutation, store the record next to the action, and fail closed or route to review on uncertainty.
Evidence retention Expose Decision Records, Decision Packets, execution receipts, Outcome Records, and verification endpoints. Define retention requirements, export packets for review, and preserve evidence in systems of record according to internal policy.
Incident response Publish status, readiness exports, and support escalation paths for runtime or security incidents. Pause affected action boundaries, provide request_id and decision_id context, and run internal downstream remediation.

Data handling boundaries

Recommended payload scope

Send the minimum action context needed for a recorded verdict: workflow, source record id, requested action, owner rule, risk facts, and evidence codes. Avoid unnecessary personal data in prompts and context.

What is logged for operations

Timestamp, route, latency, response status, request-linked hashes, readiness state, and monitor status for uptime, replay, audit, and incident workflows.

What should remain customer-side

Production API keys, HMAC verification secrets, sensitive source records, and any downstream customer system credentials.

Retention and deletion

Public privacy terms state that information is kept as long as needed to operate the service, provide support, meet billing or security obligations, resolve disputes, and maintain auditability. Custom retention or deletion terms require a paid tier or written agreement that says so.

Service providers

Visible providers include Clerk for authentication and Stripe for payment processing. Other infrastructure providers may support hosting, storage, logs, email, metrics, and alerting. Named subprocessor detail can be handled during security review or in a written agreement.

Transport and browser boundary

Public site and API traffic should use HTTPS. Sandbox history and demo preferences may live in the browser; production Decision API keys should never be placed there.

Verification and auditability

Every production integration should store the returned record before acting. Exported records and packets can then be checked by the hosted verifier, public API verifier, or SDK CLI.

Record hashes

record_hash, receipt_hash, input_hash, and output_hash bind the decision to the payload and response.

Policy bundle registry

/api/decision/policy-bundles exposes bundle metadata so reviewers can compare the record's policy_bundle_hash.

Receipt key registry

/api/decision/receipt-keys exposes public Ed25519 verification keys when portable public signing is configured.

Access, keys, and runtime defaults

Topic Default Integration expectation
Production auth x-api-key on server-side calls. Keep keys out of client code. Rotate on exposure or personnel change.
Idempotency Optional x-idempotency-key for safe retries. Reuse only with the same canonical payload; conflicts should not execute.
Error behavior Auth, validation, quota, and runtime failures return explicit errors. For irreversible actions, fail closed or route to review.
Public sandbox Unauthenticated playground validates shape only. Do not treat sandbox behavior as production auth, quotas, telemetry, replay visibility, or retention.

Incident response

API rollout and production paths include defined owner channels for delivery failures, readiness blockers, and escalation follow-ups. For immediate security issues, contact support@decide.fyi with subject security incident.

Communication path

Customer-facing updates use support@decide.fyi with request_id and decision_id context when available.

Escalation trigger

Delivery failures, readiness blockers, verification failures, or suspected key exposure should pause downstream execution and start owner review.

Public transparency

/resources/status reflects current public operational mode and readiness export status.

Review artifacts

Use these links during procurement, security review, and production readiness checks.

Claims and limits

No certification claim on this page

No SOC 2, ISO 27001, HIPAA, PCI, or regulated-industry suitability claim is made here unless explicitly published in contract artifacts.

Not a legal or compliance opinion

Decide returns a recorded software decision artifact. Customers remain responsible for legal, regulatory, and business-policy review of their workflows.

Action-boundary review

Security review should name the production action boundary, downstream system, data fields, failure behavior, and evidence retention requirements.