Retail branches, festival gates, and housing viewings share one failure mode: the moment you need a check, the uplink dies. Cloud-only IDV tells the customer to wait. Offline-proof queues tell the verifier a signed story they can trust for a bounded time.
At a summer festival, door staff must confirm age at peak entry. The backhaul saturates. A cloud-only checker times out. Queues form. Security overrides the system because the show must start. That override is exactly what offline queues prevent: a verifiable provisional yes or no with a TTL, not a shrug and a wristband.
Queue anatomy
Each step has a contract. The request carries policy ID and subject reference. Local prove evaluates against data already on the edge device or LAN host. The signed queue entry includes outcome, expiry, and method flag. Serving reads the queue, not a remote API. Reconcile replays when connectivity returns and flags conflicts.
Design rules that survive audit
- TTL on every provisional outcome. No immortal offline yes.
- Explicit method flag. Mark offline versus live in the signed payload.
- Replay on reconnect. Policy may have changed while you were down.
- Human path for conflicts. Do not auto-approve silent upgrades.
Risk tiers: a museum gift shop and a pharmacy counter should not share the same offline TTL. Write the tiers down before launch.
Why signatures matter more offline
Offline mode removes the comfort of a live server saying no. Signatures become the trust anchor. Provisional outcomes signed with keys your verifier already pins cannot be forged by a bored operator with a text editor. When the link returns, reconciliation compares queued outcomes against current policy and surfaces mismatches for review.
Offline is not trust on honour. Offline is trust on maths with an expiry date.
| Risk class | Example | Suggested offline TTL |
|---|---|---|
| Low | Event wristband pickup | 2 to 4 hours |
| Medium | Retail age-restricted sale | 30 to 60 minutes |
| High | Pharmacy or financial counter | 5 to 15 minutes, mandatory reconcile |
See Edge Audit for the same pattern against a local store, and How it Works for the prove path.
On the host
The prove step
Where AffixIO fits in offline and edge checks
Cloud-only verification treats the network as someone else's problem. At a counter, the outage is yours. AffixIO is the local prove step, with a queue that still signs.
- StaysEdge host
- Runs hereQueued prove
- LeavesSigned TTL result
It runs on the branch host, gate device, or LAN server beside the local store. If the uplink drops, prove still produces a signed provisional outcome with a TTL. When the link returns, reconciliation replays against current policy.
What stays on the host
- The local store. Eligibility data does not have to round-trip to a remote API for every decision.
- The queue. Edge Audit uses the same pattern against a local eligibility file.
- Method flags. Each payload records offline or live, so audit is not a guess.
- The signature. ML-DSA-65 remains valid when the queue drains hours later.
What the gate receives
- A signed yes or no. Staff are not asked to invent an honour-system override.
- A TTL. Low-value gates can queue longer than a pharmacy counter.
- A conflict list on reconnect. Policy that changed while offline is surfaced, not overwritten.
- Nothing unsigned. A blank screen is still better than an unsigned scribble.