Aperture Architecture
A deterministic measurement engine with no model in the path — built to be reproduced, not believed.
Confidential · June 2026. This document describes the Aperture engine's design and current build status. Any figures are illustrative. The engine is pre-MVP on live data: connectors are built but have not yet run against a live API.
Aperture is the engine that runs the standard and engine. It exists to answer a single question with audit-defensible precision: what AI is actually being used here, by whom, at what cost — including the part nobody declared. Everything below is built around making that answer reproducible.
The canonical attributed event
The engine reduces all activity to one record type: the attributed event. Every event carries metadata only — pointers, not payloads. Who (an attributed identity), what surface, when, how much (tokens, calls, cost), and a provenance pointer. There is no message body, no prompt text, no document content. Content keys are forbidden by contract, not merely discouraged — the connector layer cannot emit them, so sensitive data never enters the measurement path in the first place.
This is the "pointers not payloads" posture, and it is enforced. It is what lets the engine run inside a regulated enterprise's own environment without becoming a new exfiltration risk.
Determinism — no model in the measurement path
There is no LLM in the path that produces a number. Aperture is deterministic: the same input record yields the same output, every time. Measurement is arithmetic and attribution, not inference. This is the property that makes results reproducible and audit-defensible — and it is what separates Aperture from observe-and-summarize tools that ask a model to estimate usage. An attestation built on a model's guess cannot be re-derived; an attestation built on Aperture can.
A direct consequence: no double-count. Events are reconciled deterministically so the same call is never tallied twice across overlapping sources. The total is a fact, not an approximation — on the event shapes tested to date; the no-double-count guarantee across overlapping live sources is proven once real connectors run.
The shadow bucket is first-class
Unattributed usage is not an error state to be hidden — it is a first-class output. When an event cannot be tied to a sanctioned, attributed surface, it lands in the shadow/unattributed bucket with a dollar figure attached. Shadow AI with a number on it is the engine's most distinctive output: the demonstration figure of roughly $121k / 22% shadow is the real engine running on synthetic seed data ("Meridian Software" is a PRNG seed) — it is modeled, not measured, and it is not a customer result. The architecture is built so that, once connected to a live API, that same path produces a measured figure with no change to the method.
The connector contract
Connectors are the only way data enters the engine, and they sign a strict contract: emit attributed, metadata-only events; never content; conform to the canonical event shape. Because the contract is narrow, adding a source does not widen the engine's trust surface. The connectors are built, but they have never run against a live API — that is the next gate, not a shipped capability.
Deployment posture — single-tenant, in your cloud
Aperture's current posture is single-tenant, deployed inside the customer's own cloud. Evidence stays portable and sovereign; the engine does not pool tenants or move records to a central store. This is deliberate: it suits a regulated buyer today, and it is the honest description of where the build is — multi-tenant isolation does not yet exist.
The seam to govrn
Aperture does not render verdicts. It exposes a read-only, typed, versioned view of its record to the govrn standard across the govrn-interface seam. The interface carries evidence, not a verdict — the standard reads, the engine runs, and independent attestation is intended to be performed by a structurally separate arm against a fresh record. As a 5-person, pre-entity company, that separation is the intended structure, not a current operating fact. This seam is currently designed in a markdown spec; it is not yet code.
Built vs. next build
| Capability | Status |
|---|---|
| Deterministic measurement, no-double-count | Built + tested (synthetic data) |
| Metadata-only event model, forbidden content keys | Built |
| Shadow/unattributed bucket with dollar figure | Built (modeled on seed data) |
| Connectors (the contract) | Built — never run live |
| Single-tenant in-your-cloud deployment | Built |
| govrn-interface seam | Designed (spec), not coded |
| Live connectors against real APIs | Next build |
| Multi-tenant isolation, auth, RBAC, audit log | Next build |
The discipline here is the point: the engine is honest about what it has measured versus modeled, and the moat — the running engine plus fresh-record attestation — only compounds once these next gates close.