CodeBlu

Context

Every other property built with the open-source framework is a website. That leaves an obvious question unanswered: is this tooling for making websites, or is it for building software?

CodeBlu is the answer. It is an AI voice simulation product for police de-escalation training, and it is on this site as a demonstration that the framework reaches past content sites into a real product with real-time voice, authored safety constraints, and an assessment model.

It is also the one piece of work here that connects directly to the eight years before the technology career: de-escalation training is a subject I learned on the other side of, as a deputy rather than as a builder, and that is why I could tell whether a scenario behaved like the real thing.

Owned

Everything, as sole builder: the scenario design, the voice architecture, the guardrails, the quality detectors, and the assessment framework the sessions are scored against.

Architecture

A trainee speaks to a simulated person in a scenario, in real time. Several distinct characters can appear in one session, each with a voice and a disposition, which is what makes a scenario feel like a situation rather than a conversation with a chatbot. Voice synthesis runs on ElevenLabs, and the reasoning behind each character runs on Claude.

The interesting engineering is not the voice. It is the guardrails.

A de-escalation simulation has to be able to go badly. A subject who calms down because the model prefers to be agreeable teaches nothing, and worse, teaches a trainee that the words worked when they did not. So the constraints are authored rather than emergent: what a character will and will not do, where a scenario is allowed to escalate, and where it must stop. The model has room to improvise inside a boundary somebody drew on purpose.

Behind that sit QA detectors that read session transcripts and flag the failure modes the guardrails are meant to prevent, which is how you find out whether the boundary held without listening to every session yourself.

After a session, an after-action review scores what happened against an eight-competency framework^{Source note 1}. The after-action review is the part of this that came straight from public safety practice: the debrief is where the learning is, and a simulation without one is an experience rather than training.

Decisions

• Authored guardrails over model judgement. A model left to its own preferences makes de-escalation feel easier than it is, which is the one outcome that would make the product worse than useless.
• Multiple characters in one scenario. Situations involve more than one person, and the training value is in managing that.
• Detectors on transcripts, not spot checks. A spot check reads one session well; a detector reads all of them for the specific things that must not happen.
• Structured after-action review over a score. A number tells a trainee how they did. A competency breakdown tells them what to change.

Outcome

Shipped and running. The framework that builds content sites also built a real-time voice product with authored safety constraints and an assessment layer, by one person.

Revision

I would have written the detectors before the guardrails rather than after. I authored constraints based on what I expected to go wrong, then built detectors to check, which is the wrong order: the detectors would have told me which failures actually occurred and the constraints could have answered the evidence instead of my expectations.