Current work
Products and systems being built now
NextConsensus tracks when medical evidence moves ahead of guidelines. Ambit distinguishes the tools an agent can reach from the actions it is authorized to take.
Building now
NextConsensus
Reconstructs how medical claims gain support, shed qualifiers, and spread across public sources, then ranks the ones a team should prepare for.
How a program works →
Ambit
Capability and authorization infrastructure for AI agents — records which tools an agent can use, which it has been shown to use correctly, and which a person has allowed it to use, so autonomy can be granted one action at a time rather than all at once.
See the code →The gate checks actions when a runtime calls it. The downstream environment is simulated; Ambit does not compel other runtimes to use the gate.
An agent with broad tools and credentials can perform actions no one explicitly intended. Model capability alone is not authority: an agent with database access should not automatically be permitted to drop a production table.
Ambit separates what an agent can reach from what each action is allowed to do. When a runtime calls Ambit before execution, the gate checks the proposed action and either permits it, blocks it, or holds it for a person’s approval.
- Built
- I built a capability engine that stores its graph in local SQLite, with a CLI, an MCP server, and a browser view. For actions routed through its gate, it checks authority separately from capability: commit can be permitted while merge is not. Authorization is a person’s act, recorded in the graph, and the agent being approved cannot reach it over MCP.
- Where to see it
- Source, live demo, and roadmap at github.com/zz-plant/ambit. The roadmap states what is not built.
Ambit keeps what an agent can do and what it may do as separate records from the start. A design that inferred permission from capability would have to be rebuilt before it could ever refuse. A model with a shell, credentials, memory and access to your infrastructure can do far more than it can in a blank chat. Ambit measures that difference, which model benchmarks do not.
Capability vs. authorization in three scenarios
Each row is the answer Ambit gives when a runtime asks. Nothing makes a runtime ask yet: one that never calls Ambit is unaffected, and the systems on the other side are simulated. Refusals happen before anything runs.
Clinical chart extraction
UNCHECKED tool level
A model with EHR API access can read any chart the credential touches — there is no runtime check on which patient, which field, or which action the read serves.
BLOCKED before execution action level
The capability graph records that the EHR read exists; a separate authorization boundary restricts access to patients on the agent’s active case list. A prompt injection asking for a different patient’s records hits the authorization check and is blocked before the API call executes.
PR auto-merge
UNCHECKED tool level
A coding agent with GitHub write access can merge its own pull request — the tool permission is all-or-nothing, and self-approval is the default unless a branch-protection rule explicitly forbids it.
GATED — human approval action level
The capability graph shows merge is reachable; the authorization boundary marks merge as requiring human approval. The agent can open the PR and request review, but the merge action is gated — the system records who approved and when, and the agent cannot reach the approval record over MCP.
Financial data pull
UNCHECKED tool level
An agent with a payment API key can call any endpoint the key authorizes — balance queries, transaction history, and wire transfers all go through the same key.
BLOCKED before execution action level
The capability graph distinguishes balance-read from transfer-initiate. Authorization marks balance-read as autonomous and transfer-initiate as forbidden without human sign-off. A prompt injection crafting a wire transfer request hits the authorization check at the action level, not the tool level, and is stopped before execution.
Research & evaluation
Fast Harm, Slow Repair
A draft test that measures how far an AI error spreads, how long repair takes, and what stays wrong afterward.
Ask about the protocol →Model evaluations measure whether a system answers correctly. Almost none follow a wrong answer outward to see how far it travels before anyone intervenes, or whether the correction reaches everything it touched.
The protocol treats the gap between harm and repair as something to measure: a frozen dataset, repeated runs, and scoring rules fixed before the runs, so the results can be checked instead of argued.
- Built
- I built the case and state schemas, the scorer, one worked test case, and examples of an error that was fixed and one that was not.
- Where to see it
- The protocol draft, scorer, schemas, and fixtures are available on request. The preregistration is not frozen. No model or clinical results exist.
Ethotechnics
Specifies how to contest an automated decision, get recourse when it is wrong, and evaluate the evidence required before deployment. The open framework makes evidence, approval, challenge, review, correction and escalation things a system records, rather than things people are trusted to remember.
Explore Ethotechnics →Teams are accountable for a deployed clinical system’s uptime and cost. The ones I have worked on named nobody to answer when the evidence changes, the model degrades, or a patient is harmed.
The framework builds the questions into the product: who is accountable for the recommendation, who can override it, what the correction path is, and who runs it when the evidence moves.
- Built
- I wrote ten proposed standards covering authorization, contestability, recourse, correction, delegation, and safety cases, each crosswalked to NIST AI RMF, ISO/IEC 42001, and the EU AI Act. Ambit implements the authorization half in agent infrastructure.
- Where to see it
- The framework, and every standard with its version and status, at ethotechnics.org.
Supporting infrastructure
Refract
Tells you when a source changed and which claims or citations built on it may now be out of date. The open-source engine (AGPL-3.0) replays a source’s revision history into a record anyone can re-run and get the same result. The caller still decides whether a change matters.
See the code →Reproducing the event stream checks consistency. It does not establish medical truth, forecasting accuracy, or independent adoption.
When a source silently edits, retracts, or updates, downstream claims can go stale without anyone noticing.
Refract replays a source’s revision history and records every change as an event that names its source and time. Downstream systems decide what any of it means.
| Event | What it detects |
|---|---|
| Claim appears | When a claim first appeared |
| Hedging shifts | Whether its hedging strengthened or weakened |
| Revert and return | Whether it was reverted and then reintroduced |
| Promotion | Whether it was promoted into the lead |
| Dispute | What editors disputed |
| Page watched | Events in 30 days | Newest event | Seen |
|---|---|---|---|
| Bitcoin | 127 | a citation replaced | |
| COVID-19 | 100 | a section reorganized in “Bioethics” |
A 30-day window per page, replayed from the page’s revision history each morning and committed only when it changed. The raw files →
- Built
- I built the claim-history engine and run the daily observation bot in production. The same source always produces the same events, so anyone can re-run it and check. The published test set is 16,146 recorded edits across ten Wikipedia articles.
- Where to see it
- Source code, docs, and commit history at github.com/refract-org/refract.
- My role
- Founder
Citation graphs, evidence trails, and compliance records all depend on sources that can change, and almost none of them watch for changes. Refract gives the same output every time it runs on the same source, so anything built on it can be checked by running it again.
Writing
The Crumple Zone
Essays on the gap between automated recommendations and clinical execution.
Read the essays →Automated decisions move faster than anyone can review them, and people are harmed in the time between the two.
Each essay takes one automated decision, follows it to whoever has to carry it out, and names the point where nobody was accountable for it.
- Built
- I have written 230+ essays on institutional power, automation friction, and what keeps systems answerable.
- Where to see it
- All essays at thecrumple.zone.
Fraud filters, benefits queues, and clinical alerts kept producing a common structure despite sharing no technology, regulator, or vocabulary. Because the structure recurred across domains, a fix had to work without domain expertise, and that made it worth writing down as a specification. The patterns the essays kept finding became requirements in the framework: decisions made under depleted attention, systems that deny by waiting, and harms that are fast to cause and slow to undo.
Creative & open source
Independent open-source tools, civic data projects, and graphics engineering built alongside my primary systems work.
A preset that compiles is not necessarily a visual match to projectM. Measured results apply to the presets and reference captures tested.
The engine and its tests are inspectable. Whether its recommendations improve independent users’ decisions remains unvalidated.
How the systems connect
| Mechanism | Built at |
|---|---|
| Escalation paths | Epic |
| Verified identity | Doximity |
| Reliability reviews | CancerCompass |
| Accountable routing | Transcarent |
| Physician sign-off | Andwise |
I now build the same mechanisms into systems where a model makes the recommendation.
Every one of these projects deals with the same failure: a record that has gone out of date and is still being relied on. A guideline that no longer matches the evidence. A permission that no longer matches what the system can reach. A correction that never reached the people who acted on the error.
The pieces refer to one another through one shared record — who handed a decision to software, on what evidence, and how to take it back — published as an open standard, STD-07, the Revisable Delegation Record. A conformance checker reads those records and reports the level a system actually meets, so a system that overstates its level gets caught.
| Order | Loop step | Project | What it holds |
|---|---|---|---|
| 1 | what’s true now | NextConsensus | estimates when an institution will change its position |
| 2 | what’s allowed | Ambit | records what an agent can do and which of that it has been allowed to do |
| 3 | what to do | Whether | turns changed conditions into a weekly operating call |
| 4 | what changed | Refract | detects when a source has changed |
| 5 | the shared record | Ethotechnics | specifies who may act, on what evidence, and who may object |
How I build
I run my own tools by the rules the framework argues for: a claim holds only while it still matches its evidence, and what an agent is allowed to do is kept apart from what it can reach.
- Agent-driven development
- I build with AI coding agents, including this site. I write the repeated jobs, like a copy review or a pre-deploy check, as reusable instructions the agents follow. They live in this site’s repository, beside the code they check. One of them tells the agent to check my claims as a prosecutor would, not as a reviewer.
- Capability accounting
- Ambit reads my own toolchain and records which tools are working, one setup step away, or breaking, and keeps what an agent can do separate from what it is allowed to do. What Ambit is →
- Local model routing
- I send classification, extraction, summarization, and log scanning to models running on my own machine, because their output is cheap to check, and reasoning to a frontier model. When a local model silently stopped being able to call tools, I wrote a script that re-tests every model.
- Behavioral agent evaluation
- I test agents on whether they complete the task, not whether the answer sounds right. Fast Harm, Slow Repair is a draft recovery-evaluation scaffold.
- Claims checked at build time
- Every claim on this site is backed by a source, by an artifact, or by my own account, and the page says which. A script I wrote fetches each cited source and reports a refusal as unknown, not as a pass, because a live URL is not evidence that the page says what the claim says. The build fails when the two come apart. The last run’s result is printed beside every source on a case study and in the footer of every page.
- Readable by agents
- Every page has a machine form — llms.txt, /api/brief.json, resume.json — and the same documents answer as tools over MCP at
kanav.net/mcp, so an agent screening candidates can query the record rather than scrape it.
Revised