Three layers, one system of record.

The three-layer model

The clean separation is what keeps the system honest. Customer-specific detail exists only at Layer 3; the shared substrate (Layer 2) is engagement-agnostic; and Layer 1 — your laptop — holds no customer data at rest beyond what the agents are actively working on.

flowchart TB
  subgraph L1 ["💻   LAYER 1   —   Desktop AI host   (your laptop)"]
    direction LR
    HOST["🤖 AI host
agent sessions"]:::local
    CORPUS["📚 Corpus
~/.copilot"]:::local
    BUS[("🗄️ Local Postgres
message bus")]:::local
    MCP["🔌 MCP servers
DAB · ADO · …"]:::local
  end

  subgraph L2 ["☁️   LAYER 2   —   Shared Azure substrate   (once per programme)"]
    direction LR
    PG[("🐘 Postgres
flexible server")]:::azure
    KV["🔐 Key Vault"]:::azure
    ST["📦 Storage
corpus mirror"]:::azure
    OAI["🧠 Azure OpenAI
embeddings"]:::azure
  end

  subgraph L3 ["🎯   LAYER 3   —   Per-engagement slice   (once per customer)"]
    direction LR
    SCHEMA[("📂 Engagement schema
+ 3 DB roles")]:::engagement
    SECRETS["🗝️ Engagement
KV secrets"]:::engagement
  end

  subgraph APP ["🌐   THE CARDINAL APP   —   SWA + Functions"]
    direction LR
    SWA["🖥️ Static Web App
SPA"]:::app
    FUNC["⚡ Functions
tRPC API"]:::app
  end

  L1 == managed identity · keyless ==> L2
  L2 -. carves out .-> L3
  APP == same SPs · same DB ==> L2

  style L1 fill:#fdf5f7,stroke:#b11f4b,stroke-width:2px,color:#7a1132
  style L2 fill:#f0f7ff,stroke:#0078d4,stroke-width:2px,color:#003966
  style L3 fill:#f0fbf8,stroke:#0d9488,stroke-width:2px,color:#134e4a
  style APP fill:#fbf7ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95

  classDef local fill:#fce4ec,stroke:#b11f4b,stroke-width:2px,color:#7a1132
  classDef azure fill:#dbeafe,stroke:#0078d4,stroke-width:2px,color:#003966
  classDef engagement fill:#ccfbf1,stroke:#0d9488,stroke-width:2px,color:#134e4a
  classDef app fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#4c1d95
      

Both halves — the agents on the desktop and the Cardinal web app — write through the same stored procedures into the same database. That shared write-path is the contract between them. See Data Model for the write discipline.

The operator's laptop runs the desktop AI host. This is where the long-lived agents live, where the skills / role-briefs / workflows corpus sits, and where a small local database backs inter-agent messaging. It holds no customer data at rest beyond what the agents are actively metabolising.

A single set of shared Azure resources that every engagement draws on. Provisioned once for the programme; engagement-agnostic. Resources are referenced here by type and role — the concrete names are deployment configuration, not architecture.

The only layer that carries customer identity. When a new engagement is onboarded, a small, well-defined set of resources is provisioned on top of the shared substrate. Everything customer-specific — including, in these docs, the placeholder customer Fabrikam — lives here and nowhere else.

Cardinal — the web application — is hosted on its own Azure resources, separate from the shared substrate but writing into the same database. The front end and back end deploy independently.

How it ships

• The SPA is built and published to Static Web Apps
• The API is bundled and published to the Function App (Flex Consumption deploys via the platform's deploy API)
• A live smoke-probe confirms the deploy, the Steward attests the shipped change on the audit spine, and the roadmap is updated

Naming & regions

Azure resources follow a consistent, type-first naming pattern. In these public docs we describe resources by their type and role rather than their literal names — the names are deployment configuration, and an instance name carries no architectural meaning a reader needs.

Next: install Cardinal on your machine →