Architecture at a glance
What runs
| Component | Role |
|---|---|
| API | Serves every request. All business rules live here. |
| Worker fleet | Runs asynchronous jobs — bulk loads, recomputes, matching at scale |
| Database | Holds all data, and enforces tenant isolation itself. |
| Cache and queue | Session state, permission caching, job coordination. |
| Identity provider | Federated sign-in. Users and groups originate here, never in the platform. |
| Console | The web interface. Presentation only. |
| AI layer | The governed endpoint and the in-app assistant. Presentation only. |
The API is the single place business rules exist. The console and the AI layer are siblings over it, holding none — which is why they cannot disagree about a rule, and why a new consumer inherits every guarantee automatically.
How a request flows
Three properties are worth noticing.
ABAC policies are evaluated twice. Once before any data is loaded, for the conditions that need no record — who you are, what you are doing, where you are calling from — and again on each record once loaded, for the conditions that depend on the record itself. A record you asked for directly is refused with a 403; a record merely referenced by another is removed from the response, and list counts reflect the removal.
Tenant context is established before any data is touched, and the database enforces it. A query that forgets to filter returns nothing rather than everything.
Masking is the last step, applied once, to whatever the response contains. It is not implemented per endpoint, which is what makes it impossible to bypass by calling a different one.
Storage characteristics
- Every business table keeps full version history, gap-free and non-overlapping.
- The audit log is append-only; the database refuses updates and deletes, and gaps in its sequence are detectable.
- Search is served by the database's own text and similarity indexing — no separate search cluster to operate or keep in sync.
Asynchronous work
Bulk loads and recomputes run on the worker fleet rather than in a request. Work is split into chunks that workers claim independently, so a worker dying mid-job loses at most one chunk and another reclaims it. Adding workers adds throughput without reconfiguring the job.
Next
Last verified against commit 952ed91b (2026-08-03)