What changed, and what it means for your floor.

Versioned, leased device policy covering active, suspended, quarantined, and revoked states, with queue-delivery permission as an explicit and independent control.

What it means for a deployment:

• Credential rotation runs with a bounded overlap and durable acknowledgement, then retires the previous credential — no maintenance window required.
• A recommended application version warns; a minimum application version blocks. Version floors are now a control you set rather than a request.
• An activated device cannot be reassigned in place. Moving a verifier to a different location requires revoke and reprovision.
• A detected reboot, or an unavailable boot counter, makes a cached offline lease clock-untrusted and blocks new sessions until authenticated policy refresh. This is a conservative rule about reboot ambiguity, not a claim of secure local time.

Completed outcomes enter a bounded transactional on-device outbox after the result is available; verification remains foreground-first.

What it means for a deployment:

• Once an event reports queued, its stable random identity survives retry, process death, force-stop, manual relaunch, reboot, response loss, and partial synchronization.
• The platform provides at-least-once transport with an atomic, idempotent reporting effect. Exact retries acknowledge without incrementing a counter twice; changed-payload or changed-scope replay fails closed.
• Queue policy is centralized at 5,000 pending rows, 8 MiB of estimated pending storage, and 28 days. Pressure or expiry is visible and quarantined rather than silently evicting an accepted row.
• Heartbeats report queue depth and age and a bounded synchronization category — never queued event bodies, credentials, mobile-ID data, or patron identity.

Known limitation: a process kill in the narrow interval after the result is rendered but before the outbox commit can lose that single aggregate event. Verification is unaffected. See offline reliability.

This release records the Arizona Apple Wallet path validated through the full production flow on a Laurel-qualified enterprise Android profile: portal device creation, activation, encrypted credential storage, configuration retrieval, heartbeat, Fleet Health presence, Apple Wallet verification, privacy-safe ingestion, and aggregate reporting. Current support is a separate live operational status and is not asserted by this static release note.

Scope of the claim:

• Engagement is NFC tap followed by BLE. There is no QR engagement.
• Trust is anchored to Arizona IACA material authenticated by the current signed AAMVA VICAL.
• The request is org.iso.18013.5.1.mDL / org.iso.18013.5.1 / age_over_21 with intentToRetain false — and nothing else.
• Verification is fail-closed: anything short of a cryptographically valid Arizona 21+ proof is not a pass.

No other jurisdiction, wallet, or device is covered by this validation. See the compatibility matrix.

What it means for a deployment:

• The verifier no longer claims a state before it is true. “Phone detected” follows ISO-DEP, “connecting securely” covers handover and transport open, and verifying begins only once a response is present.
• Session ownership is explicit, and every close carries an allowlisted reason. A phone-side close during termination no longer discards an already-complete response.
• An empty transport message is treated as transport termination — never as a holder decline and never as an under-21 result.
• The age claim is read only from the verified document model, after issuer, security-object, digest, device, and session checks have passed.
• Platform library logging is disabled in favor of a typed, bounded in-app trace, so addresses, session identifiers, and payloads are not written to a device log.