Internal Framework / Published Excerpt

The AI Production Framework.

The operating system I use when a team is betting real money on AI. Cloud-agnostic doctrine, with a production-tested reference implementation. The architectural adult in the room, written down.

Version 1.0Last updated May 2026Maintained as a living document
Why this exists

Traditional software is deterministic. Agentic AI is probabilistic. Production systems have to account for that shift architecturally, not aspirationally.

Most teams shipping AI today treat the model as the system. They wire an LLM call into a request handler, sprinkle a guardrail on the input, and ship. Then the agent gets prompt-injected, the cost graph hockey-sticks, the audit team asks for a replay log that doesn't exist, and the whole thing quietly gets sunset.

This framework is the opposite posture. The model is one untrusted component inside a deterministic envelope. Routing is infrastructure. Memory is typed and scaffolded. Prompts are versioned artifacts. Permissions are architectural. Evaluation gates deployment. Every decision is replayable. Cost is a circuit breaker.

It's the document I wish I'd been handed the first time I got pulled into a Series B that had spent eighteen months building an AI feature nobody could explain to the board.

Structure

Three layers. Ten pillars.

Each pillar lives inside one structural layer. Each layer answers a different question.

Layer 1

Design Doctrine

How AI systems must be built

The non-negotiable architectural rules that govern probabilistic systems running inside deterministic infrastructure.

Layer 2

Risk Control

What prevents failure and exposure

The threat model and the defenses. Security, privacy, reliability, governance, transparency, and fairness, enforced architecturally.

Layer 3

Survivability & Sustainability

What lets the system live long-term

Societal impact, economic architecture, and operational sovereignty. The reasons a system gets sunset are rarely technical.

The pillars

Ten positions I've staked, with the reasoning compressed to one paragraph each.

The full framework expands each into principles, enforceable rules, tactical artifacts, AWS implementation patterns, anti-patterns, and industry alignment. What you see here is the load-bearing opinion.

P01

Production AI Design Doctrine

Design Doctrine

Probabilistic reasoning must live inside deterministic infrastructure. Every LLM call gets wrapped in a state machine, structured output, retry, and fallback. If you can't draw the deterministic envelope around the model call, you don't have a production system. You have a demo.

P02

Security: Zero Trust for Agentic AI

Risk Control

Prompt injection is an architectural problem, not a model problem. No amount of system-prompt hardening will stop a motivated attacker. The defense is the Three-Point AI Firewall: inspection at user input, agent output, and external content, plus infrastructure-enforced least privilege that denies the action even if the model is manipulated into requesting it.

P03

Privacy

Risk Control

Security controls access. Privacy controls data boundaries. The Four-Point PII Inspection Pipeline extends the firewall with detection at user input, retrieval, output, and system prompt construction. If you can't execute a GDPR Article 17 erasure as a technical operation, your privacy program is documentation, not architecture.

P04

Reliability

Risk Control

Probabilistic systems fail silently. Evaluation replaces assertion. Six testing disciplines (golden set, red team, regression, drift, fairness, load) gate deployment. If you can't replay a decision end-to-end six months later, you can't debug it, defend it, or learn from it.

P05

Governance

Risk Control

If a system's decisions cannot be explained to regulators, auditors, or boards, it is not production-ready. Governance is infrastructure-enforced: prompts as versioned artifacts, approval workflows with anti-rubber-stamping controls, configuration drift detection. Documentation alone is theater.

P06

Transparency & Human Control

Risk Control

HITL, HOTL, HOOTL: these aren't synonyms. They're a taxonomy. The wrong one for the risk tier creates either bottleneck or blind spot. Graduated autonomy advances by statistical power analysis and fault injection validation, not by vibes. Most teams give the agent too much authority too fast.

P07

Fairness & Bias Control

Risk Control

Fairness is a quantitative discipline, not an audit. Statistical significance with Holm-Bonferroni correction. 80% power at Cohen's h ≥ 0.2. Minimum 30 observations per subgroup. The four-fifths rule plus UK Section 19 proportionality. Anything less is a press release.

P08

Societal Impact

Survivability

AI systems are societal infrastructure. Environmental cost, workforce displacement, and emergent feedback loops show up in the system's economics whether you measured them or not. Deployments that ignore this get regulated, boycotted, or sunset.

P09

Economic Architecture

Survivability

If the system doesn't scale economically, it gets killed regardless of technical quality. Per-call cost ceilings, model cascade routing, prompt caching for up to 90% reduction, batch inference for non-real-time workloads, cost-triggered circuit breakers. Unit economics are an architectural concern, not a finance concern.

P10

Operational Sovereignty

Survivability

If your internal team cannot operate and evolve the system independently, you built dependency instead of capability. Vendor lock-in, opaque pipelines, and consultant-only runbooks are failure modes, even when the consultant is me.

Unlocked artifact

Artifact #1 of 14, published in full.

The LLM Elimination Checklist. The gate every proposed LLM call must pass before it enters the system. If a candidate call fails any of these, it should be a rule, a lookup, a state machine, or nothing.

ARTIFACT 01 / PILLAR 01 / PRINCIPLE 03
LLM Elimination Checklist
Unlocked
Purpose

Force-justify every LLM call in the system. LLMs are expensive, slow, and non-deterministic. They earn their place by doing something a rule, a lookup, or a state machine genuinely cannot. This checklist is the gate.

The 6-field justification, required for every LLM call
Purpose
What decision or output is this call producing? One sentence, no marketing language.
Non-deterministic rationale
Why can't a rule engine, lookup table, regex, or state machine handle this? If you can't answer, the call is rejected.
Per-call cost
Token-based cost estimate at the chosen model tier, including prompt-cache-adjusted system prompt cost.
Latency impact
p50 and p95 expected latency, and which user-facing or workflow SLO it consumes.
Expected volume
Calls per day at launch, and the projected volume at 10x scale. Drives caching and batch decisions.
Replacement path
If this call has to be removed (cost spike, provider outage, model deprecation), what replaces it? Cached response, rule fallback, degraded UX, human queue. No call ships without one.
Elimination triggers: when an LLM call must be replaced
Input space is finite and enumerable
Output is a fixed schema with deterministic field mappings
Decision can be expressed as a rule set or decision tree
A regex, parser, or grammar fits the problem
Lookup against a known table or index suffices
Task is solved by a smaller classifier model at <1% the cost
Approval gate, required before merge
  1. 1Submit the 6-field justification as a PR description on the call inventory file (llm-calls.yaml in the reference implementation).
  2. 2Architecture reviewer confirms no deterministic alternative was missed. A "no" here is final.
  3. 3Cost owner confirms the call fits inside the per-workflow token budget at projected volume.
  4. 4Replacement path is implemented or scheduled before the call goes to production, never after.
Anti-pattern

A team adds an LLM call to "summarize" a five-field structured record into a sentence for a dashboard. The fields are always the same. The sentence is always the same shape. They're spending $400/month and adding 800ms of p95 latency to produce a template string. The checklist rejects this on field 2 the first time anyone fills it out.

What's still locked

Thirteen more artifacts. Ten full pillar deep-dives. The AWS reference implementation.

These ship with the engagement, wired into your repo, your CI/CD, your IAM, your CloudWatch. Not as a PDF someone forwards once and forgets.

Artifact 01
LLM Elimination Checklist
Artifact 02
Routing vs Reasoning Decision Tree
Artifact 03
Replayability Spec
Artifact 04
Evaluation Harness Template
Artifact 05
Red Team Playbook
Artifact 06
Prompt + Retrieval Versioning Standard
Artifact 07
Cost Observability Dashboard
Artifact 08
Model Right-Sizing Matrix
Artifact 09
Permission Boundary Template
Artifact 10
Autonomy Level Registry
Artifact 11
Fairness Evaluation Template
Artifact 12
Explanation Format Standard
Artifact 13
Load Testing Playbook
Artifact 14
Memory Architecture Template
14
Core design principles, each with enforceable rules
25+
AWS services mapped to specific principles
~50
Pages of doctrine, controls, patterns, and anti-patterns
Aligned to

Not a vibe. Mapped to the frameworks regulators and auditors actually use.

EU AI ActNIST AI RMF 1.0ISO 42001GDPROWASP LLM Top 10 (2025)NIST SP 800-207 (Zero Trust)MITRE ATLASAWS Well-Architected AI LensEC HLEG Trustworthy AIOECD AI PrinciplesC2PA v2.1HIPAASOC 2 Type IISchrems II / EU-US DPF

The framework is the deliverable, not the pitch.

If you're betting capital on AI and want the rest of this (the 13 remaining artifacts, the per-pillar deep-dives, the AWS reference implementation wired into your stack), start with a conversation.