Decision Record v1 plus execution, outcome, packet, and audit-chain artifacts.
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.
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.
Incorrectly allowing an irreversible downstream action without a valid record.
Integrations should fail closed or route to review when auth, quota, validation, or runtime checks fail.
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.
Holds API key, builds minimal action context, and sends an idempotency key when retry behavior matters.
Evaluates declared context and returns a versioned record with policy, evidence, action binding, and integrity fields.
Stores the record next to the action and records execution or outcome receipts after downstream work happens.
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.
Data handling boundaries
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.
Timestamp, route, latency, response status, request-linked hashes, readiness state, and monitor status for uptime, replay, audit, and incident workflows.
Production API keys, HMAC verification secrets, sensitive source records, and any downstream customer system credentials.
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.
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.
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.
Customer-facing updates use support@decide.fyi with request_id and decision_id context when available.
Delivery failures, readiness blockers, verification failures, or suspected key exposure should pause downstream execution and start owner review.
/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 SOC 2, ISO 27001, HIPAA, PCI, or regulated-industry suitability claim is made here unless explicitly published in contract artifacts.
Decide returns a recorded software decision artifact. Customers remain responsible for legal, regulatory, and business-policy review of their workflows.
Security review should name the production action boundary, downstream system, data fields, failure behavior, and evidence retention requirements.