Skip to content

Reference Architecture

How the platform is built on Google Cloud — and why each layer exists.

The architecture exists to serve one goal: deliver regulator-grade results with evidence, while keeping your data isolated and the deterministic mathematics protected. It separates concerns cleanly so that each layer can be governed, secured, and reasoned about on its own.

The Operating Path

This is the path every governed result travels, through real Google Cloud components. Available today.

flowchart LR
    A[Client systems / Workbench] --> B[API Gateway]
    B --> C[Translation]
    C --> D[Canonical objects + governed run bundle]
    D --> E[Asynchronous orchestration]
    E --> F[Runtime dispatch]
    F --> G[Isolated deterministic execution]
    G --> H[Evidence + artifacts]
    H --> I[Analytical loader]
    I --> J[BigQuery analytical truth]
    J --> K[APIs, Workbench, BI, Explainability]

The Layers

Northbound API And Identity

A governed API boundary with policy control and identity is the single front door. Clients and the workbench use the same typed APIs — there is no privileged backdoor that bypasses governance. Available today.

Control Plane

The control plane owns translation, launch governance, and dispatch. It is operational, not computational — it decides what runs and records what happened; it never alters the deterministic mathematics. Available today.

Deterministic Runtime

Regulator-grade analytics execute on isolated compute on Google Kubernetes Engine, optimised for Google Cloud Axion (Arm) for efficient, repeatable execution. Execution is separated from the API and experience layers so a result is reproducible and protected. Available today.

Evidence And Analytical Truth

Two concerns are kept deliberately separate:

  • Evidence custody — immutable submissions, evidence, governed bundles, and retained result artifacts in Cloud Storage. Available today.
  • Analytical truth — canonical facts, serving summaries, and analytical products in BigQuery, organised into six governed dataset families. Available today.

Consumption

Your teams and systems consume governed facts — never raw runtime folders — through /api/v1, the workbench, BI, and explainability surfaces. Available today, with richer BI and explanation on the roadmap.

The Six Dataset Families

Your analytical truth is organised so that intake, governed objects, execution state, outputs, serving, and consumption are each first-class and auditable. Available today.

flowchart LR
    A[Intake] --> B[Governed objects]
    B --> C[Execution state]
    C --> D[Outputs and facts]
    D --> E[Serving]
    E --> F[BI and consumption]
Family Holds
Intake What arrived and how it was interpreted
Governed objects Canonical platform objects (trades, counterparties, portfolios, scopes)
Execution Run and job control state, readiness, approvals
Outputs Evidence, artifacts, and canonical result facts
Serving Query shapes optimised for APIs and workbench review
Consumption Governed dashboarding and wider analytics

What This Means For You

  • Your data does not leave your tenant to be processed; the architecture is built around per-tenant isolation.
  • The maths is protected. Deterministic execution is walled off from the control and experience layers, so results stay reproducible.
  • Everything is queryable as governed facts, which is what makes results, evidence, and explanation consistent across the API, the workbench, and BI.

Where The Platform Is Today

The full operating path and the six dataset families are available today. Embedded BI dashboards and the richest explanation surfaces are on the roadmap — see Capability Maturity And Status.