Decision lifecycle is the stable story
Decision Record, execution receipt, Outcome Record, policy intelligence, Decision Packet, and verification are the core surfaces to track.
Changelog
A plain public log of meaningful site and product-surface changes. Entries focus on what shipped, what became easier to evaluate, and what buyers or developers can now inspect.
Start here when reviewing whether a change affects integration work, buyer evaluation, or operational trust.
Decision Record, execution receipt, Outcome Record, policy intelligence, Decision Packet, and verification are the core surfaces to track.
Status, security, docs, pricing, live proof, and changelog pages are the fastest path for a procurement or implementation review.
Public npm latest is 0.1.13 as of May 22, 2026. Local source package metadata is ahead at 0.1.14 until the next publish.
| Change type | What to inspect | Impact rule |
|---|---|---|
| API contract | API reference, OpenAPI, and machine docs. | Breaking request/response changes should be explicitly labeled with migration guidance. |
| Verification and packets | Verification docs, SDK verifier, and hosted verifier. | Proof changes should preserve replayability or state the verification delta. |
| Decision Intelligence | Intelligence docs, examples, and policy report endpoints. | Outcome-derived reports should stay explainable and avoid unsupported ML claims. |
| Trust and operations | Security, status, and production smoke checks. | Operational claims should map to visible endpoints, exports, or documented process. |
This log should stay useful for technical evaluation. It should not invent momentum, customer proof, or compliance claims before they exist.
API docs, pricing, proof artifacts, public reliability views, and integration assets that a prospect can inspect.
Anything that makes the Decision API easier to understand, test, integrate, replay, or procure.
No customer logos, certification labels, production counts, or social proof unless the underlying proof exists.
The homepage and Trust page now make the first pricing-exception boundary easier to forward, explain, and review.
Docs and proof pages now frame packets, signatures, verification, and audit chains as trust escalation after the first Decision Record.
Homepage and proof review links now label what each proof surface is before the reader clicks through.
The homepage now separates the evaluation route for implementers from the buyer-review route before production access.
The first screen now states the basic product motion before introducing lifecycle intelligence.
Public navigation and docs now distinguish the Decision API contract from commercial contract terms.
The homepage now introduces pricing exceptions as the first production boundary before the sandbox and broader proof surface tour.
The focused API reference now separates first-boundary endpoints from proof, lifecycle data, and reference utility surfaces.
The homepage and docs now answer the two buyer questions raised by deeper resource review: why not hard-code rules, and which surfaces are core versus supporting.
The production smoke check now verifies the public interaction bundle behind the verifier, status page, pricing controls, API playground, and intake CTAs.
The Reference Source Alerts page now frames the compatibility feed as an operational review packet.
The Pattern Catalog now explains how first-party templates move from starter payloads into verified lifecycle evidence.
The Integration Guides page now starts with a first-boundary rollout packet before connector-specific guidance.
The Platform page now explains production access as a concrete control-plane review packet.
The Live Proof page now works as a reviewable artifact packet, not only a narrative demo.
The Proof page now gives buyers and implementers a compact review packet before the deeper proof narrative.
The Developer Examples page now gives implementers a first-hour path before the full catalog of snippets.
Public Terms and Privacy pages now match the buyer-review structure used by trust, security, and API access terms.
The API access terms page now works as a procurement review artifact instead of only listing basic checkout terms.
Payment success and cancel pages now behave like part of the buyer review path instead of simple Stripe return screens.
The Trust page now routes buyers through a concrete review sequence instead of acting only as a link directory.
The main docs overview now explains the portable Decision Packet without requiring readers to jump into the focused verification page first.
The security page now gives buyers a clearer first-pass packet for procurement, implementation, and security review.
The public evaluation surface now makes the decision lifecycle easier to scan and gives buyer reviewers a clearer status/security/change packet.
404 pages.The docs now give buyers and implementers shorter paths into the same canonical contract instead of requiring every reader to scan the full reference page first.
Decide can now export a portable proof bundle for support, audits, and buyer reviews without requiring the reviewer to trust the hosted ledger.
GET /api/decision/:id/packet returns decision_packet_v1 with the Decision Record, optional input, execution receipts, Outcome Records, policy intelligence, audit-chain metadata, verification hints, and packet_hash.POST /api/decision/packet/verify verifies exported packets, including embedded record verification and linked proof hashes.decisionPacket() and decide verify-packet; public npm latest remains 0.1.13 until the next package publish.Decide now has a single packaged example and public proof path that shows how one proposed action becomes a Decision Record, execution receipt, Outcome Record, and policy intelligence readout.
sdk/examples/lifecycle-proof-pack.js runs the end-to-end proof sequence for technical buyers.@decide-fyi/sdk@0.1.13 documents the packaged proof pack without changing the core Decision API contract.Decide now records a target-system neutral receipt for whether the action authorized by a Decision Record was actually attempted, closing the gap between authorization and final outcome.
POST /api/decision/:id/execution writes a decision_execution_v1 receipt with execution status, target system/object, mutation, execution id, state hashes, action_binding_hash, and execution_hash.GET /api/decision/:id/execution lists execution receipts for a decision in the caller API-key scope.@decide-fyi/sdk now exposes recordExecution() and listExecutions(), plus sdk/examples/action-execution-receipt.js.Decide can now evaluate simulation-only what-if scenarios against a stored Decision Record, making policy tuning and rollout review a first-class API surface.
POST /api/decision/:id/counterfactuals returns decision_counterfactuals_v1 with baseline-to-scenario verdict, action, policy version, and hash diffs.simulation_only so it is not treated as downstream action authorization.@decide-fyi/sdk now exposes counterfactuals(), plus sdk/examples/counterfactual-analysis.js.Decide now has a public first-party catalog for Decision API pattern templates, turning the registry into a browsable onboarding surface without claiming a community marketplace before one exists.
/api/decision/policy-patterns and the packaged policyPatterns() SDK path.Decide now exposes first-party templates for common state-changing workflows so teams can start from a versioned request shape instead of inventing their first payload from scratch.
GET /api/decision/policy-patterns returns decision_pattern_registry_v1 with request, outcome, CRM sync, and SDK example hints.?pattern_id=pricing_exception resolves one decision_pattern_v1; ?tag=crm filters the registry by workflow tag.@decide-fyi/sdk now exposes policyPatterns(), plus sdk/examples/policy-patterns.js.Decide now has a CRM sync receipt primitive so teams can prove a Decision Record was written back to Salesforce, HubSpot, or another source system without storing CRM credentials in Decide.
POST /api/decision/:id/crm-sync writes a decision_crm_sync_v1 record with CRM object references, mapped Decision Record fields, idempotency, and sync_hash.GET /api/decision/:id/crm-sync lists CRM sync receipts for a decision in the caller API-key scope.@decide-fyi/sdk now exposes recordCrmSync() and listCrmSyncs(), plus sdk/examples/crm-writeback.js.Decide can now compare caller-scoped policy outcomes to opt-in anonymized cohorts after minimum privacy thresholds are met, turning Outcome Records into a safer data-moat primitive.
GET /api/decision/policies/:policy_id/benchmarks returns decision_benchmark_v1 with caller metrics, cohort percentiles, comparison deltas, privacy thresholds, and benchmark_hash.DECIDE_BENCHMARKS_ENABLED; raw records are not returned and the caller is excluded from its comparison cohort.@decide-fyi/sdk now exposes policyBenchmarks(), plus sdk/examples/policy-benchmarks.js.New Decision Records now carry a hashed confidence signal derived from caller-scoped Outcome Records, so integrations can distinguish routine verdicts from decisions that deserve closer review.
decision_confidence_v1 includes score, level, similar decision count, policy stability, recommendation, reasons, and confidence_hash.GET /api/decision/policies/:policy_id/confidence returns a confidence baseline for a candidate verdict/action.@decide-fyi/sdk now exposes policyConfidence(), plus sdk/examples/policy-confidence.js.Decision Records now link into a caller-scoped audit chain so a stored decision can be placed in a tamper-evident sequence without changing the stable Decision Record hash.
audit_chain binds decision_id, record_hash, and receipt_hash into a rolling Merkle root.GET /api/decision/chains/:chain_id returns decision_chain_v1 head metadata, retained links, and verification checks.@decide-fyi/sdk now exposes decisionChain(), plus sdk/examples/decision-chain.js.Decide now turns reported Outcome Records into explainable anomaly reports for unusual policy results, without claiming model prediction before enough customer data exists.
GET /api/decision/policies/:policy_id/anomalies returns decision_anomaly_report_v1 from latest Outcome Records per decision.anomaly_hash.@decide-fyi/sdk now exposes policyAnomalies(), plus sdk/examples/policy-anomalies.js.Decide now turns reported Outcome Records into scoped policy effectiveness metrics, giving teams a way to see whether a policy is producing reliable operational results.
GET /api/decision/policies/:policy_id/effectiveness returns policy_effectiveness_v1 metrics from latest Outcome Records per decision.@decide-fyi/sdk now exposes policyEffectiveness(), plus sdk/examples/policy-effectiveness.js.The Decision API can now record what happened after a Decision Record authorized or routed an action, creating the first data-moat primitive for policy effectiveness and future anomaly analysis.
POST /api/decision/:id/outcome writes a decision_outcome_v1 record with outcome_hash, idempotency, execution references, observed metrics, and Decision Record hash links.GET /api/decision/:id/outcome lists stored outcomes for a decision.@decide-fyi/sdk now exposes recordOutcome() and listOutcomes(), plus sdk/examples/outcome-tracking.js.The SDK now ships a public conformance pack with a valid Decision Record, original input, tampered record, and replay/diff example so integrators can test verification behavior without live API access.
sdk/fixtures/valid-decision-record.json verifies with the public conformance HMAC secret.sdk/fixtures/tampered-record.json fails record, receipt, and signature checks.sdk/fixtures/replay-diff-example.json documents the shape of a current-policy drift packet.The public npm package now includes first-party examples for billing discount gates, webhook and queue workers, agent action authorization, and CI Decision Record verification.
@decide-fyi/sdk is published on npm for server-side Decision API integrations.sdk/examples/billing-discount-gate.js shows a billing mutation gated by a stored Decision Record.sdk/examples/webhook-queue-gate.js shows fail-closed queue and webhook side-effect routing.sdk/examples/agent-action-gate.js shows agent execution authorization before the proposed action runs.Decision Record v1 now carries stronger verification fields for production integrations: action binding, policy bundle attestation, true idempotent retries, evidence manifests, receipt hashes, optional signed receipts, an offline verifier, and a verify endpoint.
/api/decide returns receipt_hash, verify_url, policy_bundle_hash, action_binding, evidence_manifest, and integrity metadata.response_view now supports minimal, standard, and full projections over the same canonical record.receipt_signature fields, plus receipt_public_key_fingerprint for portable public checks./api/decision/receipt-keys publishes active Ed25519 public receipt keys when portable public signing is configured.scripts/decision-offline-verify.js verifies exported records by recomputing hashes and checking Ed25519 or HMAC signatures.x-idempotency-key now replays the original record for matching payloads and returns 409 for payload conflicts./api/decision/:id/verify recomputes record, receipt, and policy bundle hashes for stored or supplied records.Added public integration guides, developer examples, and this changelog so a prospect can evaluate how Decide fits into existing CRM, billing, automation, webhook, queue, and agent boundaries.
Promoted the playground as the lowest-friction hero action, clarified the expansion path from one boundary to broader software-action gates, and added an integration handoff panel with cURL, JavaScript, and Python snippets.
The public uptime endpoint default allowlist now stays Decide-only so the status surface does not leak unrelated product domains when environment configuration is missing.
The docs were reorganized around the actual production path: quickstart, auth, rate-limit behavior, request fields, storage fields, outcome handling, error API contract, replay, and cutover checklist.
x-api-key, x-idempotency-key, and rate-header guidance.The pricing story moved away from old workflow-specific language and toward production API tiers by monthly decision records, live action boundaries, and implementation support level.
Public compatibility routes for older reference-app paths remain live, but the current product surface is the Decision API. Reference applications are now positioned as source-backed proof surfaces built on the same recorded-decision pattern.
The highest-signal future entries will come from real customer questions: connector-specific guides, production proof artifacts, security-review updates, and measured rollout learnings.
Testimonials, logos, production counts, and case studies should appear only when they can be backed by permission and evidence.
Add deeper connector pages when prospects repeatedly ask how Decide fits a specific system or workflow.
Operational readiness, monitor coverage, and incident language should remain explicit and modest.