Making applied AI systems easier to understand, inspect and build.
I build with AI, test what happens, and explain what I learn in plain language.
Where are you in the system?
Eight questions an applied AI system has to answer, in the order the answers tend to depend on each other. Follow the sequence, or enter where the question becomes useful.
- How models workWhat is actually generating the output?What an AI Model Actually Is
- Context & retrievalWhat can it see, and how did that get there?Retrieval-Augmented Generation in Plain Terms
- Instructions & contractsWhat are we asking it to do, and what is enforced?Prompting Is Not the Skill You Think It Is
- Action & authorizationWhat can become a real effect?From Agent Intent to Governed Execution
- Human judgmentWhere does a person have to decide?Human-in-the-Loop Is a System Design Choice
- Evaluation & evidenceHow do we know the behaviour was acceptable?What Counts as Good, and How to Check It
- State & continuityWhat has to survive across a boundary?What Has to Survive for Work to Continue
- ReadinessIs there enough evidence and control for this use?When Is an AI System Ready for Real Use?
Ideas that cut across the map.
The I-7 Loop: A Working Method for Delegating to AI
Seven named points where a person decides something before an AI agent acts, and the five-minute version that makes them usable.
ReadPolicy-Governed MCP Runtimes: Trust Boundaries for Tool Execution
When a tool-connected system reads content, that content can contain instructions. What follows for where policy decisions belong, and what isolation can bound.
ReadPrompt, Skill, Workflow, Agent: Telling the Layers Apart
These words name different responsibilities, not stages of sophistication. What each one covers, and how to tell which you are looking at.
Read
See the idea.
Some things are easier to see than to read. These are the diagrams inside the articles, each one opening the piece it belongs to.
Test the idea.
Where the explanations get built and find out whether they hold. Each excerpt is read from its repository at a named commit.
DAX: Governed Execution Workstation
Deterministic runtime contract around stochastic model execution. Sits between the operator and model providers to provide policy checks, replay, and audit logs.
1# DAX Rust Crates23DAX uses Rust only for deterministic proof surfaces around stochastic model execution.45| Crate | Purpose |6| ----- | ------- |7| `dax-core` | Replays canonical run events to reconstruct run state; generates deterministic proof reports |8| `dax-policy` | Evaluates proposed actions against policy context into `allow / ask / deny` decisions |9| `dax-audit` | Evaluates trust posture from six structured run signals |10| `dax-ledger` | Builds and verifies tamper-evident append-only ledger chains |11| `dax-indexer` | Builds deterministic local repo structure indexes for context selection |1213TypeScript orchestrates. Rust decides deterministic facts.The excerpt above is source material. The summary and boundary are editorial interpretation.
Verb: Control Layer for Coding Agents
The control layer around coding agents. The agents generate; Verb owns the environment they run in, the record of what actually happened, and the way back when something breaks.
1* **Sessions that survive process death.** A session keeps its identity across an agent exiting, the2 app being force-stopped, and the machine losing the process entirely - then resumes by the agent's3 *own* conversation id. Proven end to end on a physical Android device for Claude and Codex.4* **Two hosts, one contract.** Android (proot + PTY) and desktop (native Unix PTY) implement the same5 session semantics and the same durable record shape.6* **Structural memory, not surveillance.** Durable records hold identity, context and state. Never a7 PID, process handle, command text, terminal bytes, prompts, transcripts or credentials.8* **One session lifecycle, three recovery-capable agents.** `LIVE -> INTERRUPTED -> RECOVERABLE ->9 ENDED` is implemented for Claude Code, Codex CLI and OpenCode.The excerpt above is source material. The summary and boundary are editorial interpretation.
PaneTera: Workspace Control Plane
Local-first developer control plane designed to govern, inspect, and explore workspaces using the Model Context Protocol (MCP).
1## System Diagram2[Portal UI (Browser)]3 │ (Fetch API + SSE / Bearer token auth)4 ▼5[Express Backend Server (Port 4000)]6 │7 ├─► [Host Policy Engine (myai-policy.json)] (Authoritative check)8 ├─► [Workspace Catalog (myai-workspaces.json)] (State check)9 ├─► [Append-only Logger (server/audit.log)]10 │11 ▼ (stdio spawn / tsx server/mcpWorkspaceServer.ts)12[Workspace stdio MCP Process] (Bound to selected workspace directory)The excerpt above is source material. The summary and boundary are editorial interpretation.