Trust & Procurement

Trust model for production adoption.

Use this page for governance-level trust signals, transparency links, and review workflow. For technical control details, see the dedicated Security page.

Source links: security controls, status, reference alerts, terms, privacy, API access terms.

View security controls Request security review View readiness JSON

Trust signals at a glance

Deterministic outcomes

The same input and declared runtime state return the same verdict, reducing reviewer concern around answer drift.

Verifiable evidence

Each decision can be tied to a request_id and hash-linked metadata for QA, disputes, and audits.

Visible source freshness

Reference applications publish scheduled source checks and alert history so teams can verify maintenance is active, not implied.

Buyer review sequence

The fastest review path is not one giant questionnaire. It is a sequence of public artifacts that let product, security, legal, and implementation teams inspect the same decision boundary from different angles.

01 Product fit

Confirm the action boundary in the playground or live proof path before connecting production systems.

02 Protocol review

Inspect Decision Record, execution receipt, Outcome Record, Decision Packet, and verification docs.

03 Security review

Map data boundaries, API-key custody, fail-closed behavior, readiness evidence, and incident path.

04 Commercial review

Review pricing, API access terms, support boundaries, and written-agreement requirements.

05 Launch decision

Export readiness evidence, store first production records, and assign owner review for fallback paths.

Send this to the reviewer who owns the question

The trust hub should be forwardable. Use the role below to route the same pricing-exception boundary to the person who needs to approve it.

For CTO

Can this fit our architecture?

Start with the API contract, first-hour examples, and verification docs.

For RevOps

Does this protect margin?

Use the pricing proof, billing guide, and first-boundary rollout packet.

For Security

What data and controls exist?

Review security controls, status/readiness, and the hosted verifier.

For Procurement

What are we buying first?

Review pricing, API access terms, and the implementation path.

Procurement packet

A buyer should not have to infer the trust story from scattered pages. These are the source-of-truth artifacts to forward during security, legal, and implementation review.

Security controls

Transport, access, audit traceability, data boundaries, and current certification limits.

Status + readiness export

Live endpoint status, readiness JSON, monitor scope, and incident communication path.

API contract

Request shape, response contract, authentication, idempotency, and usage limits.

Commercial terms

Kickoff scope, production billing, cancellation terms, and support boundaries.

Privacy policy

Account data, API request data, logs, local browser data, payments, and support workflow boundaries.

Terms of Service

Public service terms, API key responsibility, advice limits, availability, and written-agreement precedence.

For security

Security packet, status, readiness JSON, verifier, receipt keys, policy bundles, and incident path.

For legal

Terms, privacy policy, API access terms, written-agreement precedence, and certification claim limits.

For engineering

OpenAPI, docs JSON, SDK notes, error reference, packet anatomy, and integration examples.

For operations

Production smoke status, readiness export, changelog, support contact, and fallback review rules.

Procurement quick answers

Question	Answer	Where to verify
How do we verify current security controls?	Security implementation details are centralized on one technical page to avoid stale duplication.	/resources/security
How do we know reference monitoring is active?	Scheduled checks for source-backed reference applications produce a public alert feed and linked evidence artifacts.	/resources/policy-alerts
How can legal or compliance review terms?	General terms, privacy, API access terms, and readiness artifacts are available as dedicated resources.	/terms · /privacy · /resources/pilot-terms
What is the evidence model for a decision?	Decision runs expose `request_id`-linked traces, Decision Packets, verifier paths, execution receipts, and Outcome Records for replay and export.	packet anatomy · verification docs
What can we forward internally?	Use the procurement packet above for security, legal, engineering, and operations. It avoids unsupported certification claims and links to the current public evidence.	procurement packet · changelog
What happens if the API is uncertain or unavailable?	Production integrations should fail closed or route to human review on auth, quota, validation, runtime, or verification failure.	error reference · shared responsibility
How do we start a formal review?	Share framework and timeline to receive a scoped review packet.	support@decide.fyi

Need questionnaire support? Include your framework (for example SIG Lite or CAIQ) and target date in your request.

Review workflow

Most teams evaluate decide in this order: product fit in the sandbox, runtime visibility on the Status page, technical controls on the Security page, then procurement artifacts (Terms, Privacy, API access terms, proof package, and reference alerts). This keeps trust review fast without duplicating specs across pages.

No SOC 2, ISO 27001, HIPAA, PCI, or regulated-industry suitability claim is made on this public trust page unless separately published in a contract artifact.