Skip to content

Method

I don't ask AI to be confident. I ask it to be verifiable.

That one line is my method, and it runs through everything I build here — the agent catalog, the Agentic Runtime and RAWLY: AI drafts the work, deterministic gates decide what may continue, and every claim I publish traces back to a versioned artifact. The word proven is earned on this site, not asserted.

I split the work into three responsibilities:

  • Draft — expert agents produce the first version.
  • Check — an isolated verifier re-derives every claim, and gates screen each step.
  • Decide & record — the go/no-go is mine at named points, and every run becomes a dated trace.

It matters because I don't trust an AI result just because it looks convincing. So I control the work before, during and after — the pipeline below.

AI drafts, gates check, I decide

Across the catalog, the runtime and RAWLY, I run the same pipeline.

  1. AI drafts in shared context. Expert agents — chained by declarative BPMN workflows in the runtime, a nutrition expert and a copywriter for RAWLY articles — produce the first version. Business value: domain expertise is captured as reusable, versioned agents instead of being re-improvised on every request.

  2. An isolated checker verifies blind. It receives none of the drafting context and re-derives every claim from the source of authority — RAWLY's fact-checker re-resolves every PMID and DOI from scratch against the live registries, never from memory. Business value: a citation that looks perfect but is wrong is caught before it ships — I put this in place after auditing RAWLY's legacy articles and finding four hallucinated PMIDs.

  3. Deterministic gates decide what continues. After each step an eval-gate I built checks the result: a blocking failure stops the chain, an advisory finding is recorded but lets it continue. No LLM ever evaluates another LLM's output. Business value: an error found at step 3 does not silently become the input to step 4, 5 or 6.

  4. I decide at named points — not a blanket sign-off. The division of labor is fixed: the LLM proposes, deterministic code disposes, I decide. I give the go/no-go before any billed run, choose the model for that run, and merge any change to the catalog — nothing bills or ships on autopilot. Business value: cost and adoption stay under my control, at the points where a wrong automatic decision would be expensive.

Verifiable before it ships, controlled while it runs, provable afterwards — so a plausible-but-wrong result is stopped at a gate, not discovered by a client.

Prove it live, fail closed

I call a workflow proven only after a real run traversed it end to end, with eval-gates enforced at every step and the per-step verdicts committed as verbatim JSON traces. A run that merely looks finished is not evidence — the trace is.

Fail-closed means a run has three honest outcomes, and I publish all three:

Outcome What it means Exhibit
completed Every gate passed; the deliverable shipped Nine workflows on the live proofs page
⟲ returned A counter-review gate sent the work back; the final report was withheld by design WF-008
gate-halt A gate rejected its input and stopped the chain WF-009's second trace

The last two are not failures of the method — they are the method working. A returned audit and a halted chain prove the gates discriminate: they can say no, so their yes means something.

The same discipline governs the dispatcher. Before any workflow runs, the runtime's router decides which one — and it can decline. Out of twenty test briefs it routed nineteen to the process a person would have chosen; the twentieth it refused with NO_MATCH, naming the nearest miss. When a brief is too thin to route it returns PARAMS_MISSING, naming exactly what it needs — and only after I amend it and give the go-ahead does the routed run proceed. See the dispatcher runs.

Versioned, or it didn't happen

Every repository I ship carries the same regime: SemVer, annotated git tags, GitHub Releases, and a dated changelog entry per release.

  • The catalog versions its 38 agents, 37 skill folders and 10 workflows as code — all 85 assets indexed in a CI-validated sidecar.
  • The runtime commits its live-run traces verbatim under docs/audit/live-runs/ — the same files the live proofs page quotes.
  • This site follows the identical discipline: each release folds its changelog entry, and the model that did the work is recorded per release.

Explore the evidence