Platform Gateway
- identity · tenant
- request context
- authn / authz context
Toward a Governed Enterprise AI Platform
I built these systems independently and tested each one against its own evidence. This page shows the larger architecture I’m evolving them toward.
From trusted organizational knowledge, to structured-data reasoning, to controlled business action.
Evidenceimplemented systems first
Architecturerelationships earned by evidence
Integrationfuture work stays labeled
How the systems are evolving together.
The proven nodes are existing, independently tested systems. Building and evolving nodes show active work or the direction of integration.
KNOW
What does the organization know?
UNDERSTAND
What does the structured data tell us?
ACT
What should the system do?
SHARED MODEL RUNTIME
MODEL LIFECYCLEpromotion / rollback
OPERATE
Why did it break?
existing relationship / implementation target integration
Expand full architecturethe target system, with what is built marked
The graph above shows what exists and how it connects today. This is the architecture those systems are being built toward. Every box carries its own status, because without that the target reads as though it were already finished.
Request entry
Capability Router
NEXT- which capability handles this request
Capability planes
Each plane proposes; the deterministic controls inside it decide.
Knowledge plane
PROVEN- scoped retrieval + reranking
- typed research graph (PydanticAI)
- page-image reading + calculation in code
- source, value and scope checks
Data plane
PROVEN- schema retrieval
- global SQL policy
- request-scoped authority
- server-owned grain safety
- EXPLAIN cost gate
- read-only execution
Action plane
PROVEN- target resolution
- policy
- confirmation
- revalidation
- idempotent execution
Shared model runtime
Model choice never changes permissions.
Adaptive Model Router
EVOLVING- core routing engine: PROVEN
- task · capability · complexity aware
- quality · latency · cost · budget aware
- health · fallback · escalation
- 1 real integration · 3 contract-tested
Model tiers
NEXT- specialist SLM
- general reasoning LLM
- vision and multimodal
Inference providers
- local open models
- OpenAI-compatible APIs
Model lifecycle
A candidate reaches the router only through an evaluation it passed.
CauseTune
PROVEN- QLoRA / PEFT
- frozen benchmark
- resource profiling
Offline evaluation
PROVEN- base vs fine-tuned
- quality · VRAM · efficiency
- generalization slices
ModelOps Control Plane
PROVEN- canary 10 → 25 → 50 → 100
- quality and reliability gates
- delayed ground truth
- promotion · rollback · reconciliation
Model registry
NEXT- versions and lineage
- feeds the router
Cross-cutting governance
Shared contracts and central governance over independent services, not one monolith.
Enterprise Context
NEXT- one entity across planes
- data · knowledge · metrics · actions
- role / tenant / scope
Capability Gateway
NEXT- typed capabilities
- REST / OpenAPI · MCP
- databases · knowledge · business systems
Unified Registry
NEXT- models · agents · knowledge bases
- entities · tools · policies
- eval suites · deployments
Control Plane
NEXT- identity · policy · lifecycle
- evaluation · deployment state
- observability · audit · cost
One trace across every plane
knowledge.rag
- retrieve
- rerank
- evidence.build
- model.route
- validate
decision.sql
- schema.retrieve
- sql.generate
- sql.parse
- policy.evaluate
- query.execute
agent.runtime
- proposal
- target.resolve
- policy.evaluate
- confirmation
- tool.execute
Operations
Incidents are investigated from evidence; remediation is proposed, never executed.
Agentic SRE
PROVEN- read-only in-cluster Connector
- evidence journal with explicit gaps
- deterministic root-cause rules
- replayable diagnoses
Implemented systems.
Four independent subsystems, each with a different failure surface and an explicit evidence trail.
Status is a claim boundary, not a project-management label.
PROVENImplemented independently and backed by explicit evidence.
BUILDINGActive implementation.
EVOLVINGA working subsystem exists; its role or abstraction is being generalized.
NEXTNot implemented yet.
KNOW · Trusted organizational knowledge
Knowledge Base RAG
Evidence-backed access to unstructured organizational knowledge.
Engineering decision
Agents choose what to look for; tenant scope, tools, calculations and release stay application-owned.
Current evidence
- 101/120 accepted outcomes on 120 distinct long-document questions
- PydanticAI agents on a typed research graph with application-owned ResearchState
- Original page-image reading, checked inputs and calculation in application code
Stack / boundaries
- PydanticAI
- typed research graph
- ResearchState
- Qdrant
- Qwen3 embeddings
- BM25
- RRF
- BGE reranking
- tenant ACL
- page-image reading
- calculation in code
- OpenTelemetry
ACT · Agent Runtime foundation
Agent Runtime
Controlled business actions where the model proposes intent but deterministic software owns execution authority.
Engineering decision
The LLM never receives mutation authority.
Current evidence
- 540/540 measured deterministic safety attempts
- 0 unsafe executable survivors
- 0 unsafe executions
Stack / boundaries
- LangGraph
- FastAPI
- PostgreSQL
- SQLAlchemy
- typed tools
- deterministic policy
- confirmation
- revalidation
- idempotency
- OpenTelemetry
MODEL LIFECYCLE · Evidence-based model lifecycle management
ModelOps Control Plane
Canary delivery and promotion control where candidates earn traffic through explicit evidence gates.
Engineering decision
A candidate earns production traffic by satisfying predefined evidence gates, not by existing.
Current evidence
- 10% → 25% → 50% → 100% automated canary progression
- PASS / FAIL / INCONCLUSIVE verdicts with automatic rollback paths
- 279 backend tests · ~91% statement coverage
Stack / boundaries
- FastAPI
- SQLAlchemy
- canary rollout
- quality + reliability gates
- delayed ground truth
- automatic rollback
- reconciliation
- Docker Compose
OPERATE · Incident investigation for the Kubernetes runtime
Agentic SRE
Root cause analysis for Kubernetes incidents from evidence, with a read-only Connector inside the cluster.
Engineering decision
A bounded investigator gathers evidence; deterministic rules decide the root cause.
Current evidence
- 27/27 held-out testbed runs with the true cause named · HOLDOUT23
- 0 false RESOLVED · 0 false strong authority · decoy never named
- 18/31 exact on ITBench-Lite · 0 model calls in every measurement
Stack / boundaries
- Python
- Kubernetes
- gRPC over mTLS
- read-only Connector
- PostgreSQL evidence journal
- deterministic RCA
- offline replay
- Prometheus · Loki · Tempo
- Chaos Mesh testbed
- React console
Specialization has to earn its place.
CauseTune is intentionally shown as NEXT here. The question is not whether a model can be fine-tuned; it is whether specialization actually beats the base model.
Base Model
CauseTune / QLoRA
Offline Evaluation
Candidate
ModelOps
Canary
Registry
Adaptive Model Router
NEXT
CauseTune / QLoRA
Potential evaluation: task quality, SQL execution accuracy where relevant, retrieval/generation quality, latency, throughput, VRAM, cost, and generalization.
Engineering principles.
The platform direction is coherent because the boundaries repeat, even when the subsystems do different work.
Models provide intelligence. Deterministic systems provide authority.
Evidence decides what gets promoted.
Evaluation gates are defined before looking at the result where applicable. A candidate can improve some metrics and still be rejected. Rejected experiments remain evidence instead of being rewritten as success.
Read the frozen reranker decision (opens in a new tab)Failures stay attributable.
retrieval miss ≠ reranker loss ≠ generation error ≠ validator error ≠ policy failure ≠ execution failure
Aggregate “AI accuracy” is not enough to decide which subsystem needs to change.
Integration second. Platform last.
These are target integrations, not current deployment claims. The sequence starts with a second real data consumer and grows the contracts only when the next boundary is earned.
- BUILDING
DecisionSQL
Structured data plane
- NEXT
Enterprise Context V0
One entity consumed across planes
- NEXT
Cross-plane integration
Knowledge, data, and action contracts
- NEXT
Shared capability contracts
Stable boundaries between bounded services
- NEXT
Unified Registry
Models, agents, knowledge, data, tools, policies, evaluations, deployments
- NEXT
Unified Control Plane
Common identity, configuration, policy, and lifecycle
NEXT
Enterprise Context V0 starts with Order.
Enterprise Context starts only after DecisionSQL creates a second real data consumer, avoiding a speculative ontology layer.
The first success criterion is simple: the same Order entity is actually consumed by RAG, SQL, and Agent subsystems.
Order
data: commerce.ordersknowledge: order-policy · refund-policymetrics: order_value · refund_rateactions: cancel_order · refund_orderKnowledge Base RAGDecisionSQLAgent RuntimeOrder
NEXT
Unified Registry
Models · Agents · Knowledge Bases · Data Sources · Tools · Connectors · Policies · Evaluation Suites · Deployments
NEXT
Unified Control Plane
Common identity, configuration, policy, and lifecycle across independent bounded services.
Independent bounded services+shared contracts+common control plane
Not one giant repo containing every project.
Built independently. Measured explicitly. Now being connected deliberately.