The Effective Intelligence Stack
Nine layers that together make AI genuinely safe — not by policy, but by architecture. Each layer closes an entire class of attack that the others cannot.
Every AI safety proposal today tries to make AI systems behave well. The EI Stack is built on a different premise: that behavior is the wrong surface to defend. Rules can be broken; structures cannot be escaped.
The Effective Intelligence Stack is nine composable layers, each of which physically constrains what the AI can do. By the time a Safebot agent acts, its entire universe of possible actions is a prebuilt toolbox with known semantics. It cannot write arbitrary code, access arbitrary data, or run on servers it could modify. The safety is not a guardrail bolted on afterward — it is the shape of the system.
The same architecture that makes AI safe also makes it dramatically cheaper. When the AI fills blanks in a known schema instead of generating PHP from scratch, the cost of customization falls by roughly 95%.
The Nine Layers
Each layer is listed bottom-to-top, matching how they compose. Click any row to jump to that layer's section.
A Stream is Qbix's fundamental data unit: a typed, permissioned sequence of messages or records. Every piece of data in a Qbix app lives in a Stream. There is no general database query surface; you either have permission to read a stream or you don't.
This is not just an access-control layer on top of SQL. The Stream API is the only interface. An AI working in this system cannot issue SELECT * FROM users — that interface does not exist. It can read the fields of a Stream it has been granted access to, and nothing more.
Each Stream type has a formal registry entry: the type identifier, the fields exposed on page.*, and the Embed DSL tools that can render it. The AI reads this registry to generate valid Embeds. Field names it doesn't know are physically unavailable, not just forbidden.
The Embed DSL is a domain-specific language of custom elements and reactive bindings. It is the only target for AI-generated frontend output. The AI does not write JavaScript.
Custom elements like <q-each>, <q-if>, <streams-preview>, and <users-avatar> compose into full interfaces. Bindings come in two forms: stamp-once (${expr}) and live-reactive (@{expr}). Every element and binding is a known quantity with defined semantics.
<streams-preview stream-id="@{page.streamId}">
<users-avatar user-id="${item.publisherId}"></users-avatar>
<q-if condition="${item.type === 'video'"}>
<video-player src="${item.url}"></video-player>
</q-if>
</streams-preview>
The runtime interprets this declaration. There is no eval(), no inline <script>, no access to window or document. The AI's output is data that the runtime interprets — not code that the browser executes.
Qbix embeds in third-party sites via a standard <iframe> serving on the Qbix origin. The embedding page communicates via postMessage, passing a payload of template identifier, scope data, and overrides. The browser's same-origin policy enforces the boundary.
This is not a rule that code must follow. It is a physical boundary enforced by the browser's process model. A script running on the embedding site cannot read the Qbix frame's DOM, cannot access the user's session cookie on the Qbix origin, and cannot inject content into the frame. An AI generating content for the frame cannot affect the embedding page, even if the output is malicious.
// Embedding page
qbixFrame.contentWindow.postMessage({
template: 'community.discussions',
scope: { communityId: '12345' },
overrides: { theme: 'dark' }
}, 'https://app.qbix.com');
The Qbix app owner configures an embedding domain whitelist. Frames from unlisted origins are rejected. The user's session is authenticated by the Qbix origin's own cookie, not a token that could leak to the embedding page.
The Websites plugin defines pages as a hierarchy of sections, blocks, and tools, expressed as JSON. A page is not a template file with embedded PHP — it is a structured document that the Qbix renderer interprets.
Each tool has a defined option schema. The AI customizes a page by producing a JSON payload that conforms to this schema: which tools appear, in which blocks, with which options. It cannot introduce new code paths. Every option the AI can set was defined by a human in the tool's spec.
A Qbix app is a cloneable directory with a known structure. Deploying a new app means cloning the template and running configure.php — not provisioning infrastructure from scratch. The resulting instance is as verifiable as the template it came from.
HTML, CSS, and JS are the natural surface for visual customization. App-level configuration lives in local/app.json. A clone of a clone is identical in structure to the original. Branches work the same way: each branch is a clone that shares the core with its parent.
This makes customization legible. An audit of what a deployment does is an audit of the template it was cloned from, plus a diff of its local/app.json. There are no hidden modifications, no one-off server-state, no "we changed it manually in production."
The AI customization layer is where a language model translates a user's natural-language intent into platform payloads. The model reads the Stream type registry, the page schema, and the Embed DSL tool catalog — all of which are structured documents — and produces structured JSON output.
The AI never writes PHP. It never writes JavaScript that runs on a server. Its output is a JSON payload describing what to render and with what data. The Qbix runtime interprets that payload. If the AI hallucinates a field name that doesn't exist in the stream registry, the runtime rejects it at validation time, not at execution time.
RAG (retrieval-augmented generation) over the app's own stream content gives the AI factual grounding. Structured output schemas (JSON Schema or equivalent) constrain its responses. The result is customization that is both fast and auditable: what the AI produced is a diff from a known baseline, not an opaque binary.
Safebox is a deployment architecture, not a policy. A Safebox server is two AMIs: one runs the application; one runs the security monitor. Neither can modify the other post-deployment. There is no SSH. There is no console access. The server boots from a known-good image, remote-attests its state via hardware TPM, and refuses to start if the attestation fails.
This closes the most fundamental gap in cloud security: the privileged insider. Even a compromised employee with AWS console access cannot modify what is running. The application image is sealed at build time and verified at boot. Any tampering breaks attestation and the server refuses to serve traffic.
The two-AMI architecture means that the security monitor has no dependency on the application AMI's packages, and the application has no mechanism to disable its own monitor. They share hardware but not software stacks.
The EI Stack runs on open-weight models. This is not a preference — it is a requirement. A model whose weights cannot be inspected cannot be audited. A model running on a proprietary API cannot be verified to produce deterministic output for a given input.
The KV cache tree is a structured representation of the model's context: the exact sequence of tokens that produced a given output, stored in a form that can be reproduced and audited. When a Safebot agent takes an action, the inference trace that produced that action can be replayed deterministically.
This makes the AI layer of the EI Stack as auditable as the layers below it. The payloads the AI generates are not just inspectable after the fact — they are reproducible from a known starting state.
A Safebot is an agentic AI that operates within the EI Stack's constraints. It can take multi-step actions — reading streams, generating embed payloads, creating new app branches, publishing to page schemas — but every action it can take is a call to a tool in the known toolbox.
The Safebot's scope is defined at instantiation: which streams it can read, which tools it can call, which page schemas it can modify. It cannot self-modify its scope. It cannot call arbitrary APIs. It cannot write to the filesystem outside its defined workspace.
When a Safebot generates a new tool for the toolbox, that tool goes through the same provenance chain as any other: it runs in the Embed DSL sandbox, its schema is registered in the type registry, and it can only access streams it's been permissioned to read. A Safebot creating new capabilities does not expand the attack surface — it extends the known, bounded toolbox.
95% Cost Reduction
The cost reduction is not a marketing claim — it follows directly from the architecture.
Traditional AI customization
EI Stack customization
When the AI generates PHP from scratch, every output is a new, unaudited artifact. It must be reviewed, tested, deployed, and maintained. The cost is per-feature and compounds.
When the AI fills blanks in a known schema — choosing among sections, tools, and options that already exist and already work — the output is a diff from a known baseline. Review is a schema validation. Testing is against the same test suite as every other app using those tools. Deployment is a clone.
The 95% figure comes from three compounding effects: (1) no code generation means no code review; (2) schema-validated output fails fast at validation instead of in production; (3) reuse of the toolbox means most customization is configuration, not construction.
| Activity | Traditional | EI Stack |
|---|---|---|
| Custom feature build | PHP dev, 2–4 weeks | AI payload, ~1 hour |
| Security review | Full code audit | Schema validation |
| Deploy new customer | Infrastructure provisioning | Clone + configure.php |
| Audit what changed | Server access + git blame | Diff of local/app.json |
| Agent takes action | Opaque; hard to replay | KV trace; reproducible |
Structural Safety vs. Policy Safety
Policy-based AI safety says: the AI must not do bad things. This requires the AI to correctly understand what counts as bad, in every context, forever. It requires the rules to be complete. It requires that they cannot be circumvented by clever prompting. None of these requirements is achievable.
Structural safety says: the AI physically cannot do the bad thing. Not because it has been told not to. Because the interface for doing it does not exist.
Why each layer is necessary
The layers are not redundant. Removing any one of them opens a different attack class that the remaining layers cannot close:
| Remove this layer | This attack opens |
|---|---|
| Streams | AI can enumerate any database table it can name |
| Embed DSL | AI can inject arbitrary JS into the rendered page |
| iframe boundary | AI output can access the embedding page's cookies and DOM |
| Page schema | AI can introduce new code paths outside the toolbox |
| App templates | Deployments become undiffable snowflakes |
| AI layer constraints | Schema drift; hallucinated fields cause runtime errors |
| Safebox | Privileged insiders can modify running servers |
| Open models | Inference cannot be audited or reproduced |
| Safebot scope limits | Agents can expand their own capabilities |
Why this matters now
The current wave of AI deployment puts language models at the keyboard of production systems — writing code, submitting pull requests, executing SQL, calling APIs. The only safety mechanism in most of these deployments is the model's training. That is a policy-based defense, and it is demonstrably insufficient.
The EI Stack is the answer to the question: what would AI deployment look like if we took structural safety seriously from the start? The answer turns out to also be cheaper, faster to deploy, and easier to audit. Safety and efficiency are not in tension here. They are the same design.