Testing and conformance

Minimum integration tests

Test the host integration with synthetic data before connecting a real provider:

1. unambiguous grounding and authorization;
2. ambiguous candidates and clarification;
3. authorization denial before dispatch;
4. provider rejection and precondition failure;
5. acknowledgment followed by PRESENT;
6. acknowledgment followed by ABSENT_FINAL;
7. response loss and UNKNOWN;
8. verifier indeterminate or unavailable;
9. verifier-only reconciliation with zero redispatch;
10. wrong-tenant and stale-context rejection;
11. two concurrent first requests for the same host identity admit at most one provider dispatch;
12. after host restart, a repeated delivery returns the saved bounded result or remains safely pending, with no second dispatch;
13. wrong operation, effect, execution, subject, saved proposition, tenant, or returned claim permission withholds customer effect wording;
14. independent authoritative reads establish the exact effect or final absence, including when provider acknowledgment conflicts with that read;
15. in a multi-effect workflow, one committed effect and one refused or unresolved effect produce separate, bounded customer statements.

Assert dispatch count, physical mutation count, verifier reads, result, identities, saved host claim plan, returned claim permission, and customer wording. Run the concurrency and restart cases against the host's actual admission and persistence implementation; provider idempotency keys alone do not prove host duplicate suppression. Do not infer correctness from a provider response alone.

These are minimum host integration checks for a consequential action. Production hardening additionally needs provider-specific authorization, fault and crash handling, distributed leases/fencing where applicable, monitoring, load limits, privacy review, and incident procedures. The synthetic checks above do not certify those properties.

Conformance boundary

The Portal documents the Adapter Kit model and the checks a separately controlled offline conformance runner would perform across bounded provider/verifier seams, hostile inputs, lifecycle counters, privacy rules, and closed result expectations. The admitted Portal distribution does not include that runner or a current bounded conformance report. Even when separately executed by maintainers, those checks do not certify a live provider, persistence layer, restart safety, production readiness, or package availability.

External-consumer validation must use the exact approved package artifact or authorized release channel, package-root imports, a clean consumer, and synthetic data. The portal currently publishes the declaration/API surface but does not claim that public package installation is open.