One Privacy Boundary, Six Capabilities: The Control-Plane Thesis

Most enterprises assemble AI from separate tools — a chat vendor, a vector database, a security add-on, a compliance spreadsheet. The control-plane thesis is that chat, memory, security, compliance, audit, and carbon accounting should share one privacy boundary and one record. When they don't, the gaps between them are where your risk lives.

The problem with AI assembled from parts

The default way to build enterprise AI is to buy the pieces. A hosted chat product for the interface, a vector database for retrieval, a guardrail add-on for safety, a governance tool for policy, and a spreadsheet — always a spreadsheet — for compliance. Each is competent on its own. The trouble is what happens between them: data crosses four vendor boundaries, each keeps its own partial logs, and no single place can answer a question that spans the whole interaction.

When a regulator asks "what did your AI decide about this person, and what safeguards were in place," the honest answer from an assembled stack is "let me check five systems and try to line up the timestamps." That reconciliation gap isn't a minor inconvenience. It's precisely where enforcement actions and breaches find room to happen.

What "one boundary" actually means

A control plane inverts the assembly. Instead of six products with six trust boundaries, there is one boundary — your own environment — inside which every capability runs. A prompt doesn't leave your perimeter to be secured, then leave again to be logged, then get reconciled by a compliance tool that wasn't watching. It is secured, answered, recorded, and governed in one place, because all of those functions live inside the same wall.

The six capabilities, sharing one home

In Sphere IQ, six capabilities run inside that single boundary. None is novel in isolation; the point is that they are not separate purchases you have to make agree with each other.

• Chat & RAG — grounded answers over your company knowledge, with citations.
• Engram — long-term memory that follows a user across the platform.
• Bulwark — deterministic security inspecting every prompt and completion.
• Comply AI — regulatory obligations mapped to live controls and evidence.
• Audit — a signed, hash-chained ledger of everything that happened.
• CSRD — per-token carbon accounting for AI, mapped to disclosure.

The interesting property is the connections. Chat retrieves; Bulwark checks the prompt on its way out and the answer on its way back; Comply AI knows which obligations that interaction touched; Audit records all of it; Engram remembers what's allowed; CSRD counts the cost. Because they share a home, those handoffs are function calls, not vendor integrations.

One shared record

The clearest payoff of one boundary is one record. Every module writes to the same signed audit ledger: the prompt, the retrieval and its access scope, the security decision, the completion and its redactions, the memory write, the emissions of the call. So a question about a single interaction reads back as one connected story rather than five partial ones you have to stitch together and hope agree.

This is what turns "prove it" from a project into a query. When the security control, the compliance mapping, and the answer itself all landed on the same chain, demonstrating that a safeguard was in place for a specific decision is a lookup — not a forensic reconstruction across vendors who don't return each other's calls.

Why the seams are the risk

• Where is data exposed? Assembled stack: at every vendor handoff. One control plane: inside one boundary.
• Who has the full record? Assembled stack: no one — it's partial everywhere. One control plane: one shared ledger.
• Answer a cross-cutting question? Assembled stack: reconcile five systems. One control plane: one query.
• Add a new capability? Assembled stack: another boundary to secure. One control plane: another module inside the wall.

Every seam in an assembled stack is a place where data is in motion between parties, where logs diverge, and where "not my system" becomes an available answer. Collapsing the seams is not a convenience feature; it's the security and compliance argument.

Why the boundary has to be yours

A control plane only delivers its guarantee if the boundary is one you actually control. That's why it's self-hosted: it runs inside your own environment, so your prompts, your retrieved documents, and your embeddings don't leave your perimeter to be processed by someone else's service. "One boundary" and "someone else's cloud" are contradictions; the whole thesis depends on the wall being yours.

This also future-proofs the model choice. Because the boundary is yours and keys are yours to bring, you can route across multiple model providers without any of them becoming the place your data lives. The models are interchangeable; the boundary is not.

See six capabilities inside one boundary. Walk through how chat, memory, security, compliance, audit, and carbon accounting share a single self-hosted perimeter and one signed record — so cross-cutting questions become a query. Book a walkthrough.