Conformance and production-readiness checklist

Check your integration

Use this checklist to gather evidence for your own review. The Generic HTTP first-action example shows the selected SDK path, while the API reference gives exact interfaces. Record the package versions, scenario and observed results for each check.

• SDK compatibility. Use the selected Core, Runtime and Actions versions together, Node.js 22+ for the combined integration, and package-root imports. Compile against the selected declarations. See Versioning and migrations.
• Identity and authorization. Authenticate each request and replay. Bind the requester, tenant, provider account, exact target and policy decision under host control. Check that another tenant or an altered request cannot reuse that authority. See Trusted context and Authorization.
• Execution and verification. Record when dispatch may have crossed the provider boundary. Verify the exact effect through an independent read of the authoritative business system. Check both the verified outcome and claim permission before telling a customer it happened. See Provider and verifier responsibilities and Safe claims.
• Duplicates and uncertainty. Exercise repeated requests, a lost provider response and conflicting evidence. Preserve UNKNOWN when the effect is unresolved; use verifier-only reconciliation without blind redispatch. Check the original dispatch and effect-identity bindings. See UNKNOWN reconciliation.
• Durable state and restart. Persist admission and accepted recovery records before relying on restart recovery. Verify stable routing, verifier registration, source-record digests and atomic compare-and-set; use leases or fencing where multiple workers can act. Test an orderly restart and document how your host handles interruption and unresolved work. See Host operations.
• Privacy and diagnostics. Keep credentials and unnecessary customer data out of results, logs and Trace files. Restrict access to retained evidence, set retention and deletion practices, and confirm diagnostic observations are not treated as proof of the business effect. See Security and privacy and Diagnostics & Logging.
• Operations and capacity. Monitor error states, unresolved records, verifier latency, heap and RSS. Set bounded admission and queues, storage-failure handling, process-drain rules and incident procedures. Validate your own workload against the current operating envelope; no production throughput or sizing guarantee is established for this package set.

Before production use

Review the recorded results with the people responsible for the application, provider, security and operations. The current reference examples establish bounded local behavior; abrupt process-loss cleanup is not proven for every host. The Portal supplies no current conformance runner or report. Passing this checklist provides evidence for owner review, not a readiness certificate or a guarantee that an external effect occurred. Your deployment still needs its own security, recovery and capacity decisions.