Skip to main content

Architecture Decision Records

ADRs are maintained in the repository under docs/adr/. Each records the context, decision, and consequences of a significant choice. The directory is canonical; this table is an index of it and nothing more.

ADRDecision
001Modular monolith
002PostgreSQL as system of record
003PostGIS for geospatial
004Keycloak for identity
005OpenFGA for authorization
006NATS JetStream for events
007Temporal for durable workflows
008React Native with Expo
009S3-compatible object storage
010AI service isolation
011Docusaurus for documentation
012Coolify for deployment
013Tenant isolation via row-level security
014Stripe Connect for payments
015Managed SFU for video transport
016PIMS integration strategy
017Animal-relational policies read the grant tables
018Scoped pool acquisition for untransacted reads
019Platform-reference authoring runs as its own role
020Brevo is the email provider, and what its receipts may claim
021Country activation registry, and the removal of the French default
022OpenCage is the geocoding provider
023Stripe hosted checkout, and the statuses a webhook makes observable
024Contact points are what a verified token asserted
025Scheduled maintenance runs as its own role
026A capability token is a row-level-security scope
027The treating-clinic arm, and the bound on it
028The incapacity review runs as its own role
029Accreditation is recorded per country, and the credential claims only that
030The client IP is what a trusted proxy says it is
031The mobile app is a product, and which portals get a native client

When a decision changes, update the existing ADR or add a new one — never leave an architectural decision undocumented. ADR-031 §4 is worth reading as an example of the protocol working: it records a decision that was reversed within an hour of being taken, and why, rather than quietly replacing it.