Scope
The emphasis is on what happens at the boundaries of normal operation: uncertain information, incomplete transactions, disputed decisions and handoffs between organisations. A reassuring presentation is insufficient if the underlying service cannot explain its state or correct an error. The questions apply to digital services generally, with particular force where people have limited alternatives or errors are hard to reverse.
Illustrative example
A customer receives conflicting messages about whether a payment was completed. The service should distinguish a confirmed transaction from a pending request, identify the authoritative record, prevent an accidental repeat and provide a route to a responsible person. The example illustrates design requirements; it does not claim that a particular implementation has met them.
Terms and contribution
“Trust-critical” is used here as an editorial category, not a certification or a substitute for domain-specific safety requirements. For AI systems, the NIST AI Risk Management Framework is an established external reference for examining trustworthiness and managing risk. This dossier develops the implications for service design.
Read in this order
- From Interface Craft to Governable Delegation — Begin with recovery and contestability as parts of the experience, rather than afterthoughts.
- Designing for agency — Follow the responsibility chain when software receives authority to act.
- Design Governance OS — Use the proposed delivery framework to ask what evidence and ownership should exist before release.