Reference Architecture: an Operations Platform
This is the generalized shape of a real class of system we build — an internal platform that becomes a business's system of record. It is deliberately generic: the pattern is real, the specifics of any client system are not shown.
The layers
Business inputs. Forms, uploads, inbound email, and events from other systems enter through validated, rate-limited boundaries. Nothing trusted by default.
Application & workflow. The system of record: roles and permissions, the state machine that moves work forward, and the screens people actually use.
Data & intelligence. A modeled data store plus the engines that act on it — scoring, matching, retrieval, document intelligence — with deterministic rules ahead of any model.
Integrations. CRM, accounting, storage, and communications connected through a dedicated layer, so the platform augments the existing stack instead of replacing it.
Human decision & output. Consequential actions surface to a person with the context to authorize them. The system proposes; a human disposes where it matters.
Cross-cutting
Authentication and least-privilege access, observability (logs, metrics, alerts), automated backups with tested restore, and immutable, atomically-switched releases wrap every layer.
Why this shape
Separating layers means each can be tested, deployed, and reasoned about on its own. Putting deterministic rules ahead of models keeps behavior predictable and cheap, and reserves intelligence for the genuinely ambiguous. Treating integration as a first-class layer is what turns a promising app into something that fits an existing business instead of fighting it.