Correctness under partial failure

State correctness per operation and test it under the failures the architecture promises to tolerate. Managed services reduce implementation work but do not select the application contract.

Work from the affected contract

1. Name operations, failure domains, consistency and availability requirements. Decide whether distribution is needed and what is delegated to a managed system.
2. Trace writes, messages, acknowledgments and external effects. Locate crash windows, duplicated effects, lost updates, ordering assumptions and stale owners.
3. Choose idempotency/deduplication, transactions/outbox, fencing/leases and compensation from the actual resources and failure model. Price coordination rather than adding consensus by default.
4. Budget deadlines, retries, queues and backpressure together. Bound overload and specify what is blocked, rejected or shed.
5. Inject applicable crash/partition/duplicate/reorder/clock scenarios and check the declared invariants, recovery and operational visibility.

Scope and completion

Produce the operation/failure matrix, decisions and evidence at the smallest useful scope. N/A is valid with a reason. Claims such as exactly-once effects or linearizable access require stated boundaries and verification; do not infer them from delivery or quorum terminology.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references