Skip to main content

Architecture at a Glance

An architect deciding whether this belongs in front of their data needs three answers: what the platform is made of, where access is enforced, and what happens on every request. They are independent — the shape of the system does not determine the order of a request, and the order does not reveal the shape.

What the platform is​

Consumers

  • Applications
  • AI Agents
  • People
The OneThe One

The Platform

Governance

Applied on every request

  • Isolation
  • Permissions
  • Policy
  • Masking

Evidence

  • Audit

  1. Surfaces

    • REST API
    • Governed Agent Endpoint
    • Console
    • In-app Assistant
    • Event Stream

  2. Resolution

    • Standardize
    • Validate
    • Match
    • Merge
    • Relate

  3. Record

    • Golden Records
    • Lineage
    • History
    • Relationships
    • Reference Data

Source Systems

  • CRM Platform
  • ERP System
  • Core Operational Database
  • Data Warehouse
  • Data Lake
  • SaaS Apps
  • HR System
  • Core Banking
  • Policy Administration
  • Claims

Source systems contribute records. The record layer holds one governed golden record per real-world thing, with the lineage, the history and the governed links behind it. The resolution layer is what turns the first into the second. The surfaces serve it — four you call and one that calls you when something changes, each the same capability behind a different protocol, none holding a rule of its own.

Governance is not a stage data passes through once. It is applied on every request through every surface. A new consumer inherits it without re-implementing anything, and two consumers cannot disagree about a rule because neither of them owns one.

Audit sits apart from the four enforcement layers because it is evidence, not enforcement. Resolution covers the stages that change a record; getting data in and serving it out are the boundaries either side of it.

Where access is enforced​

Four independent layers. A request passes all four, and each can refuse regardless of what the others allow.

  1. RequestWith the caller's token
  2. 2Role-based access controlDoes this role hold the permission?
  3. 3Attribute-based policyFirst pass — before any record exists
  4. 1Row-level isolationEnforced by the database, never by the query
  5. 3Attribute-based policySecond pass — on each loaded record
  6. 4Field maskingOn the surviving records
  7. Response
LayerDecidesEnforced by
1 · Row-level isolationWhich organisation's rows exist at allThe database, never the query
2 · Role-based access controlWhether this role holds the permission the operation requiresThe request pipeline, before anything is read
3 · Attribute-based policyWhether this caller may see this record — evaluated twiceThe pipeline, then again on each loaded record
4 · Field maskingWhich values within a visible record are redactedResponse generation, for every response shape

Row-level isolation is the one no application mistake can bypass. It applies when data is read, in the database rather than in the query, so a query that forgets to filter by organisation returns nothing rather than everything.

Attribute-based policy is evaluated twice, and the two passes see different things. The first runs before any record exists, so it can only judge the caller, the action, and the request. The second runs once records are loaded and can judge the record itself — its type, its values, who the caller is related to, what consent covers it.

Masking is not a layer you can route around. It runs inside the same pass that made the access decision, on whatever survived it, for every response shape rather than per endpoint.

How a request flows​

A request can be refused at three points — authentication, identity resolution, or the permission and policy check — and if it is, it ends there. Otherwise it comes back one of two ways.

Two different refusals, and the difference matters. A record you asked for by name is refused. A record that merely appears inside a response — a row in a list, the other end of a relationship, one side of a match pair — is removed from the response instead, and the count reported alongside it drops to match. You never receive a placeholder for something you may not see.

The whole request is one transaction. The organisation is set on it as the first statement, and nothing is read before that happens.

That is the path a tenant request takes. Cross-organisation administration follows a separate path with its own gate, and public endpoints such as sign-in skip identity resolution entirely.

Storage characteristics​

  • Every business table keeps full version history, gap-free and non-overlapping.
  • The audit log is append-only; the database itself refuses updates and deletes, and its numbering is issued by the database, so a missing entry is 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 workers 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. The claim is fenced: a worker that stalls and comes back cannot overwrite work a peer has already finished.

Workers pull, they are not pushed to. The queue is a table and a worker claims from it, so there is no broker to run and no dispatcher to lose work. They are also split by the kind of work rather than pooled, so a long matching run cannot starve a load, and adding capacity for one does not require touching the other.

Next​