01Platform
A control plane, drawn honestly.
This page describes the designed architecture of PSIFI Lattice — the layers, their responsibilities and the reference topology they assume. Nothing here claims to be deployed.
02Control plane
Seven layers.
From the operator in a browser to the system of record an agent can change. Layer six is the one that makes the rest possible: the boundary where an action is intercepted.
Holds the agent registry, evaluates policy, routes approvals and appends audit records.
In: evaluation and registration requests. Out: decisions, approval requests, audit events.
FIG. 07 — Designed architecture. Select a layer for its responsibility, inputs and outputs.
03Runtime architecture
Where an action is intercepted, and what happens in the milliseconds around it.
- Interception point
- The SDK, gateway or MCP shim that sits between the agent and the target system.
- Evaluation call
- A synchronous request carrying agent identity, tool, environment and payload.
- Decision
- allow · deny · require_human_approval · redact, returned with the policy that matched.
- Telemetry
- Spans emitted asynchronously so the decision path stays fast.
- Failure mode
- Fail-closed or fail-open per policy, and the unavailability itself is recorded.
04Policy architecture
Policies are compiled, versioned and evaluated against a typed event.
- Model
- Conditions on a structured event, one action, a scope and an environment.
- Compilation
- Rules are compiled and cached, so evaluation is a lookup rather than a parse.
- Versioning
- Every change is a new version; the audit record names the version that applied.
- Rollout
- Observe-only mode records what a rule would have done before it blocks anything.
- Precedence
- Deny beats approval, approval beats allow; the matched rule is always reported.
05Data architecture
Three stores with different lifetimes, because traces and evidence are not the same thing.
- Registry
- Agents, tools, policies, users and approvals in PostgreSQL.
- Telemetry
- Span payloads in object storage with a search index over their attributes.
- Audit ledger
- Append-only records, retained independently of the payloads they describe.
- Redaction
- Applied at ingest, before anything is written or forwarded to a model.
- Retention
- Per-workspace windows for traces, payloads and audit records.
06API architecture
One authenticated entry point for the console, the SDKs and the gateway.
- Authentication
- Scoped API keys per environment; SSO and RBAC for console users.
- Surfaces
- Agents, actions, policies, approvals, traces, audit.
- Idempotency
- Evaluation and approval calls are idempotent on a client-supplied key.
- Webhooks
- Approval requests and policy events delivered with signed payloads.
- Limits
- Per-key rate limits, with the evaluation path prioritised over query traffic.
07AI layer
Model-neutral by design. Lattice records and governs calls; it does not host models.
- Providers
- Several providers side by side, with usage and cost attributed per route.
- Routing
- Planned for Relay: one endpoint, per-route policy, failover between providers.
- Context control
- Data rules applied to the payload before it reaches a model.
- Evaluations
- Recorded traces become fixed cases for scoring output over time.
- No training
- Workspace telemetry is not used to train models.
08Enterprise deployment
Three topologies, in increasing order of isolation.
- Managed
- PSIFI operates the control plane; workspace-scoped data paths.
- Hybrid
- PSIFI operates the control plane, telemetry stored in your own account.
- Private
- The whole control plane deployed in your cloud account — on the roadmap.
- Regions
- Data residency selected per workspace.
- Upgrades
- Versioned control-plane releases with a supported SDK range.
09Cloud architecture
Designed for real cloud workloads.
A reference topology, not a deployment claim. The mapping to named cloud services is illustrative and implies no partnership.
| Layer | Design choice | Component | Why |
|---|---|---|---|
| Frontend | Static build behind a CDN | CDN | Console assets cached at the edge |
| API | Container infrastructure | Containers | Horizontally scaled, stateless request handling |
| Data | PostgreSQL | PostgreSQL | Registry, policies, approvals, audit ledger |
| Events | Queue / streaming | Queue | Telemetry ingest decoupled from query |
| Telemetry | Object storage + search | Object store + search | Span payloads with configurable retention |
| Cache | Redis | Redis | Policy compilation and hot lookups |
| Secrets | Secrets management | Secrets manager | Provider credentials and API keys |
| AI | Model providers / cloud AI | Model providers | Reached through the gateway, never stored |
| Monitoring | OpenTelemetry / cloud monitoring | OpenTelemetry | The control plane is itself observable |
Swipe → for the full table
10Modules
Lattice, Relay, Sentinel.
One control plane with two planned layers around it. Relay and Sentinel are roadmap items: nothing on this site depends on them and nothing here should be read as available.
Lattice
Inventory, observability, policy enforcement, approvals, cost intelligence and audit for production AI.
Relay
Model gateway and intelligent routing across providers, with failover and per-route policy.
Sentinel
Runtime AI security: prompt and payload inspection, data-loss controls and policy enforcement at the edge of the agent.
Agents, models, tools and systems, with policy gates on every governed edge. 13 nodes and 14 connections. Customer agent, a agent in prod · low risk, connects to General large. Research agent, a agent in staging · low risk, connects to Reasoning mid. Finance agent, a agent in prod · medium risk, connects to General large and Reasoning mid. General large, a model in provider a, connects to CRM tool and Knowledge index and Refund API, through a allow gate and allow gate and approval gate. Reasoning mid, a model in provider b, connects to Knowledge index and Ledger database, through a allow gate and redact gate. CRM tool, a tool in read, connects to CRM. Knowledge index, a data in vector store, connects to Warehouse. Ledger database, a data in read, connects to Warehouse. Refund API, a tool in write, connects to Approver. CRM, a system in system of record, terminal node. Warehouse, a system in analytics, terminal node. Approver, a human in finance ops, connects to Payments. Payments, a system in financial, terminal node.
- Agent
- Model
- Tool
- Data
- Human
- System
- Policy gate
Put a control layer around your AI systems.
Connect your agents, understand their behaviour, define their boundaries and operate AI systems with a clear audit trail.