Private preview · 0.2.0-preview.1

Conformance and production-readiness checklist

What remains to check?

What conformance can establish

A conformance report is evidence about declared scenarios and observed behavior. It is evidence for owner review, not a readiness certificate for every deployment. The Adapter Kit evaluates a bounded contract within its declared run; it does not turn a package digest or a passing fixture into production certification.

Readiness checklist

CheckEvidence to reviewStatus or scope
Exact package and contract identityPinned package-root declarations and canonical report inputsIn scope; record the exact chain
Package-root imports and strict TypeScript compilationPositive examples, negative fixtures, compiler outputIn scope
Clean-environment verificationFresh-environment install and declaration checksIn scope for the declared kit run
Declared scenarios executedScenario manifest and observed lifecycle recordsIn scope; bounded to the run
Mutation implementations independently detectedInjected defect and validator resultIn scope
Expected values separated from observed executionProvider, verifier, and projection observationsIn scope
Provider and verifier separationIndependent registrations, calls, and evidenceIn scope
Dispatch, mutation, verifier-read, finality, and redispatch countersCounters in the report and Trace projectionIn scope
Finality behaviorPRESENT, ABSENT_FINAL, and INDETERMINATE handlingIn scope
Reconciliation acceptance and rejectionVerifier-only reconciliation and zero redispatchIn scope; process-local authority
Privacy markers and bounded outputsRedaction, omission, size, and error checksIn scope
Canonical report and digest integrityCanonical bytes and SHA-256 digestIdentity evidence only
Process-loss execution and cleanup evidenceAbrupt child termination and cleanup observationIncomplete: PROCESS_LOSS_CLEANUP_UNPROVEN
Known projection behaviorActions PROJECTION_FAILED result mappingIncomplete: current mismatch blocks certification
Operational owner decisionsDeployment, authentication, storage, incident response, and legal reviewOutside the kit's scope; owner decision

The checklist distinguishes the process-loss cleanup evidence gap from the current Actions projection mismatch. It does not invent a new certification result.

What the Adapter Kit evaluates

The kit evaluates declared scenarios, lifecycle observations, defect mutations, provider and verifier counters, finality, reconciliation acceptance and rejection, privacy, projection integrity, process-loss evidence, and actual observation rather than expectation echoing. Conformance evidence is bounded to the declared run and scenario.

Shipping-label mutation example

A fulfillment application uses an authenticated backend to bind an exact shipment and label. A carrier provider adapter reports that the label was voided, while an independent carrier verifier reads the authoritative carrier record and finds the label still active. The conformance mutation must detect that provider acknowledgment cannot yield COMMITTED; the normalized result remains bounded and the projection must not report unsafe success. This proves the declared lifecycle behavior, not every future carrier deployment.

Digest versus behavioral evidence

A SHA-256 digest establishes that canonical bytes match. It does not prove semantic correctness, provider authority, deployment safety, credential cleanup, or production readiness. Behavioral evidence comes from the declared scenario, independent mutation detection, lifecycle counters, provider/verifier separation, and owner review.

Current unresolved evidence

An abruptly terminated child can be observed, but current evidence does not prove required cleanup after process loss. Ordinary passing tests cannot replace that evidence, and no durable-reconciliation claim follows. Separately, the known Actions PROJECTION_FAILED mismatch remains open: the current baseline maps it to INTEGRATION_FAILURE, while the frozen target is UNKNOWN with internal truth preserved and zero redispatch. See Provider and verifier responsibilities for the authoritative mismatch detail.

Owner review

The adapter owner supplies the provider and verifier implementation, credentials, authoritative system, operational cleanup, fixtures, and deployment assumptions. The kit evaluates the bounded declared contract. It does not decide the deployment host, authentication, storage, invitation, signed delivery, incident response, or legal policy. Review a report by starting with its scenario and injected defect, inspecting observed counters, comparing provider observation with authoritative verifier evidence, confirming result and projection, and recording incomplete evidence and scope. Treat the digest as identity only.

Some operational choices remain P2B decisions, including authentication, immutable object storage, signed delivery, deployment host, and invitation workflow.