Arnaldo Sepulveda
Senior AI Engineer building governed AI infrastructure for regulated industries.
I build AI systems for environments where a wrong answer, an unauthorized retrieval, or an unaudited action carries real consequence. That means authorization-first retrieval, governed multi-agent orchestration, reproducible evaluation, and fail-closed behavior — running on customer-controlled infrastructure with local models. For the last ~18 months I have been building that thesis as a platform, Keystone.
Keystone: a governed AI platform, not a RAG demo
Keystone began as governed retrieval and grew into a platform. The interesting problem was never "answer the question" — it was doing so under constraints that regulated work actually imposes: prove the evidence, enforce who may see what, refuse when the ground is uncertain, and leave a record that survives scrutiny. Those constraints are enforced in architecture — the retrieval flow, the orchestration layer, the database model, the audit chain — not in a prompt.
Underneath the workloads is a shared governance substrate: a PostgreSQL agent registry for identity and roles, a task-lifecycle and orchestration layer, event-driven coordination over NATS JetStream, a dispatch abstraction that keeps agents interchangeable, and sealed evaluation artifacts. Build governance once, inherit it everywhere.
- Agent identity & roles (PostgreSQL registry)
- Task lifecycle & orchestration
- Event-driven coordination (NATS JetStream)
- Dispatch abstraction
- Sealed evaluation artifacts
- Tamper-evident audit chain
Positions earned by implementation
Regulated orgs have a retrieval problem, not a knowledge problem
The documents almost always exist. What is missing is the ability to find the right one, prove it is the source, and show who was allowed to see it. Framing it as retrieval — not "knowledge" — is what makes it tractable and governable.
Evaluation should be able to embarrass the system, not flatter it
An eval that only passes is marketing. The useful ones are built to surface failure — adversarial access probes, out-of-scope queries, fail-closed cases — and the failing runs get published next to the passing ones. That is where the real design feedback comes from.
Governance has to be structural, not a prompt instruction
A rule that lives only in a prompt can be reworded away. Access control belongs in the retrieval path and the database; refusal belongs outside the model; the audit record belongs in an append-only chain. If a control can be argued with, it is not a control.
Agents need visible control planes and auditable state transitions
A tool-using agent is only trustworthy if you can see what it is allowed to do, what it did, and why — as explicit, authorized, logged state transitions. The control plane should be a first-class, inspectable object, not an emergent property of a prompt.
Local, on-prem constraints improve architectural clarity
Building for customer-controlled infrastructure with local models removes the cloud API as a crutch. You are forced to be explicit about cost, latency, failure modes, and data boundaries — and the architecture gets clearer for it.
Notes from building the thing
I write about governed AI, retrieval, evaluation, auditability, and system design — the lessons that only show up once you have implemented and measured something. Writing is a first-class part of this site, not an afterthought.
The same governance model — Serve, Block, Route, Mutate — carried from workplace safety to acute-care medicine with no structural change. Built at the Boston AI Tinkerers hackathon.
Every tool call authorized by role and written to a tamper-evident log; the interface itself changes with what the user is permitted to do.
From enterprise contact centers to governed AI
Before Keystone I spent nearly 13 years at Genesys, building the AI intelligence layer of enterprise contact centers for regulated and public-sector customers. That work — knowledge retrieval, chat, e-services, contact intelligence — ran in environments that demanded production reliability, security controls, and the ability to prove what happened, when, and who authorized it.
The contact-center industry solved severity-tier escalation, per-step validation, compliance logging, confidence-threshold refusal, and policy-aware routing long before LLM products rediscovered these needs. Keystone is, in large part, me carrying that operational rigor onto the LLM substrate — as architecture, not as a slide. I hold an MScE in Electrical Engineering from the University of New Brunswick, with a thesis applying machine learning to smart-grid load control.
What is public now
I try to make claims that map to something you can inspect. The eval baselines below are published, with their methodology and lineage, in the ledger.
Governed retrieval — keystone-core/retrieval-v1 (2026-04-11): P@1 0.75, MRR 0.79,
adversarial ACL 8/8 blocked, fail-closed 5/6, Alberta OHS safety corpus.
Governed agent extension — keystone-core/agent-v1 (2026-05-20): 186 eval cases,
12 categories, 0 failures; failing precursor run published alongside.
Work I want to do next
I am most useful on governed AI infrastructure for regulated or high-consequence environments: retrieval and authorization, evaluation infrastructure, agent orchestration and control planes, and the auditability that makes any of it defensible. If that is the problem you are staffing — as an employer, an engineering leader, or a collaborator — I would like to hear about it.