Designing composable systems.

Signing platforms usually start out as closed products: one certificate provider, one identification method, one format, one way of storing evidence. They work well until something changes: a client arrives from another country, a new provider appears, a regulation requires a different level, or an algorithm ages. A composable system is designed for that moment. Its pieces can be swapped without rebuilding the whole.

What composable means

A system is composable when it is made of independent capabilities, with clear boundaries and explicit contracts, that can be combined in different ways to address different cases. In electronic signatures, those capabilities are easy to recognize.

1. Identity. Who the signer is: accounts, national identities, external providers, document verification.
2. Signature. What the signing is done with: local devices, remote signing, the organization's own keys, organizational seals.
3. Time. Who sets the time: one or more timestamping authorities, with an order of preference and fallback.
4. Trust. What validation is checked against: trusted lists, national roots, policies.
5. Evidence. What is recorded and how it is preserved: chained events, reports, archiving.
6. Workflow. The order in which everything happens: signers, approvals, deadlines, notifications.

Design rules

• Interfaces before implementations. Each capability is defined by what it promises, not by who delivers it.
• Catalog, not code. Adding a provider or a method should mean registering a piece, not modifying the core.
• Declared failures. If a piece does not respond, the system uses the next one or records the level achieved; it never silently drops to a lower level.
• Shared evidence. Every piece writes to the same log, so that there is a single story.
• Isolation. Each organization sees only its own data, enforced in the database and not just in the application.

← All notes