Separate technical reconciliation from business enforcement when provider semantics are incomplete

A known response schema is enough to implement and validate a deterministic technical comparison, but not enough to make that comparison authoritative for customer pass/fail. This applies when an external profile exposes identifiers and attributes while completeness, freshness, status meaning, or field units remain unconfirmed. Implement a three-state comparison (matched, mismatched, unknown) and an observation-only rollout first; enable enforcement only after the owner confirms required fields, source authority, empty-result semantics, freshness, and error handling. This does not apply when an authoritative contract already defines those semantics and release gates.

Evidence/example — 2026-09-09 UTC

Source provenance: read-only Shield repository inspection and current Linear requirements for COR-2741/COR-3450. The carrier-profile contract exposes carrier identity/status and carrier-level insurance rows, but lacks vehicle scheduling and does not fully define effective-date, limit-basis, empty-array, or carrier-status decision semantics. Shield's existing decision engine can carry a customer-specific dependency, so an observation-first technical result avoids either blocking implementation on credentials or silently turning undocumented provider fields into business authority.