In progress
What I'm building now
None of this started from AI. Escalation paths at Epic, verified identity at Doximity, reliability review at CancerCompass, routing and ownership at Transcarent, accountable sign-off at Andwise — the same mechanisms, rebuilt for the case where the thing deciding is a model.
NextConsensus and Ambit get worked on daily — the venture and the research instrument. Everything under them supports one or both: the evaluation work, Refract watching the sources the others cite, the essays, and a few experiments.
Building now
NextConsensus
Reconstructs how medical claims gain support, shed qualifiers, and spread across public sources, then ranks the ones a team should have an answer ready for. Authority-transition forecasting is built on top and is still a research program.
How a program works →Biopharma teams know when new literature publishes, but struggle to see when evidence begins altering accepted medical position across regulators, guidelines, and payers.
Reconstruct claim trajectories across revisions and score evidence transitions before formal institutional action makes them obvious.
Business
Biopharma Medical Affairs, Regulatory, and Market Access teams
When guidelines, approvals, and coverage will move
Evidence transitions are accelerating; teams need lead time, not faster search
Claim Intelligence available; Discovery in validation; forecasting still research
What's shipped
Built the registration system, the deterministic claim-scoring engine, the trajectory-reconstruction pipelines, and the resolution rules that score forecasts against the public record.
The method, claim discovery engine, and public record are at nextconsensus.com. Discovery publishes eighteen entries, each checked against its own source by hand; the forecasting examples are labelled illustrative because none has resolved yet.
My role
Founder — sole engineer to date.
Select a layer for detail.
Without this layer
The live public record at nextconsensus.com — the authoritative account of every forecast filed.
Ambit
AI agents often fail because they don't know what tools, machines, accounts, or permissions they actually have. Ambit keeps a persistent map of those capabilities and how they fit together — and keeps what the system can do separate from what it may do.
Open Source →An agent's action space is in no configuration file. Models, MCP servers, credentials, machines, and human approvers combine into abilities no component lists — so the honest answer to “what can this system do right now?” is usually “nobody knows.”
Read configuration and infrastructure into a graph the agent can query: can I do this already? What am I missing? What would need to be installed, connected, or approved? Capability and authorization stay separate objects in the graph.
What's shipped
A capability engine over a local SQLite graph, a CLI, an MCP server exposing 30 tools, and a browser visualizer. Approval is a human act recorded in the graph — deliberately unreachable over MCP by the agent being approved.
Source, live demo, and roadmap — which states what is not built — at github.com/zz-plant/ambit.
What running it taught
Capability and authority have to be separate objects from the start. Once the graph answers what a system can do, the next question is whether it may — and a model that inferred permission from capability would have to be rebuilt.
A model with a shell, credentials, persistent memory, and access to your infrastructure can do things the same model in a blank chat cannot. Ambit keeps track of that difference — the share of an agent's capability that belongs to the assembled system, which no benchmark measures.
My role
Author
How it works
Research & evaluation
Fast Harm, Slow Repair
A bad AI answer can be corrected in seconds; the damage it caused can last for weeks. An evaluation protocol that measures how errors spread, how long repair takes, and what stays wrong afterward.
Ask about the protocol →Model evaluations measure whether a system answers correctly. Almost none measure what happens after it answers wrongly — how far the error travels before anyone intervenes, and whether the correction ever reaches everything the error touched.
Treat the harm-to-repair gap as a measurable property of a system: a frozen dataset, repeated runs, and deterministic scoring rules fixed before the runs — so the results can be checked rather than argued.
- Built
- Wrote the protocol, the deterministic scoring rules, and the tested fixtures for both the recovered and unsafe-persistence paths.
- Where to see it
- The protocol draft and scorer are available on request. Results publish when the frozen-dataset runs complete.
Role and why it matters
- My role
- Author
How it works
Ethotechnics
An open framework for AI decision accountability — how to contest an automated decision, how to get recourse when it's wrong, and how to prove a system is safe before it ships. It treats evidence, authorization, challenge, reconsideration, correction, and escalation as explicit system states.
Explore Ethotechnics →AI systems get deployed, then drift. Nobody owns what happens when the evidence changes, the model degrades, or a patient is harmed.
Design the questions into the product: who owns the recommendation, who can override it, what happens when it's wrong, and who corrects it when the evidence moves.
- Built
- Wrote the framework's seven proposed standards — two stable, five in draft — covering authorization, contestability, recourse, correction, and safety cases, mapped against NIST AI RMF, ISO/IEC 42001, and the EU AI Act.
- Where to see it
- Full framework and operating model at ethotechnics.org.
Role and why it matters
- Why it matters
- Every hospital, payer, and health system deploying AI faces the same governance gap. The framework is open so they can adopt it without taking on a vendor.
- My role
- Author
Supporting infrastructure
Refract
Tells you when a source changed and which claims or citations built on it may now be out of date. Open-source engine (AGPL-3.0) that replays a source's revision history into a complete, verifiable record — deciding whether a change matters stays the caller's job.
Open Source →When a source silently edits, retracts, or updates, every downstream claim built on it goes stale — and nobody notices.
Replay the source's revision history and emit every change as a verifiable event. Downstream systems decide what matters.
- Built
- Built the graph-based claim-history engine and run the daily observation bot that exercises it in production.
- Where to see it
- Source code, docs, and commit history at github.com/refract-org/refract.
- What running it taught
- Change detection should be deterministic. If the observation layer is probabilistic, you can't trust the rest of the stack.
Role and why it matters
- Why it matters
- Any system that cites sources — citation graphs, evidence trails, compliance records — needs to know when those sources change. Refract is that observation layer.
- My role
- Founder
How it works
Writing
The Crumple Zone
Essays on the gap between automated recommendations and clinical execution.
Read Essays →Automated decisions move faster than the institutions that are supposed to review them. The gap is where people get hurt.
Write about where accountability thins when institutions absorb automated decisions — and what keeps systems answerable.
- Built
- Wrote 230+ essays on institutional power, automation friction, and what keeps systems answerable.
- Where to see it
- All essays at thecrumple.zone.
- What running it taught
- The same structure turned up in fraud filters, benefits queues, and clinical alerts. Those systems share no technology, no regulator, and no vocabulary — which is what turned this from an opinion into something worth specifying. A fix that depended on domain expertise would not have survived the second domain.
Role and why it matters
- Why it matters
- The writing informs the product work. The concepts — cognitive scarcity, governance by attrition, asymmetric irreversibility — show up in the framework and in how I build.
- My role
- Author