DSP 03 / ORIGINAL EDITORIAL
What survives when the connection drops
Resilience starts by deciding what the person can still see, save, verify, and undo without a live service.
A workflow that assumes uninterrupted access can fail quietly: a draft disappears, a retry creates a duplicate, or a reviewer cannot reach the evidence. Design the degraded path before calling the system complete.
Define the minimum useful state
List what must remain available when the model, network, identity provider, or source system is unavailable. A saved draft, last verified record, queued action, and visible timestamp may be more valuable than a clever fallback answer.
Make retries safe
Every queued or retried action needs an idempotency boundary and a visible state. A person should know whether work is unsent, pending, accepted, rejected, or safe to retry.
Rehearse recovery
Test a dropped connection during input, generation, review, approval, and publication. Recovery is part of the user journey and should not depend on technical staff interpreting logs after the fact.
TAKE TO THE FIELD
Questions before transfer
- What remains useful offline?
- Which action must never run twice?
- How does a person recognize stale evidence?
- Who owns reconciliation after recovery?
The degraded path is part of the product, not an exception to it.