DEV Community: Zain Dana Harper

A self-hostable AI workstation with a coding agent and answer-checking (Flywheel 1.0.1)

Zain Dana Harper — Sat, 19 Sep 2026 23:50:13 +0000

Flywheel is a self-hostable AI workstation and coding harness. You run it on your own machine, point it at any model you hold a key for or a local one, and keep a record of every run. This post walks the parts a developer touches first: install, the coding agent, check-output, and the receipt path.

Install and start the gateway

pip install flywheel-verify
flywheel up

flywheel up starts the local API gateway on http://127.0.0.1:8799 and serves a browser shell there. The installed runtime uses only the Python standard library. The PyPI distribution name is flywheel-verify; the command it installs is flywheel.

No model download is required. Point the router at a hosted provider you hold a key for, or run local through ollama over HTTP, or fetch the published 14B and 32B weights. The roster reports that a credential is present, never its value.

flywheel auth login <provider>

That runs a stepwise sign-in, stores the token in your OS credential store, and the router picks it up.

The lanes

Fifteen lanes are declared in the roster; ten bundle natively from hash-pinned source. List their configured state, or probe each lane's live MCP connection:

flywheel lanes
flywheel lanes --probe    # live MCP handshake per lane

Lanes cover research intake (gather), a workspace map and symbol graph (index), memory with source checks (mneme), multi-agent routing (forum), claim recheck (crucible), writing quality and AI-tell detection (articulate), and more. Each runs on its own and composes with the others through JSON.

The coding agent

relay is a permission-gated coding agent that works over your own folders on a local or hosted model:

flywheel relay

Stage four of a run is the capability check. It reads a shell command the way a shell reads it and names what the command is able to do, and that name settles the decision: allow, refuse with a reason returned to the model, or escalate to a person. A blocked request is not a fatal error. The reason goes back to the model, which can pick a different route, and the ledger keeps the request, the refusal, and the reason.

One honest gap the repo does not paper over: the map of executable names is curated by hand, so a command it has never seen is admitted and written down as unknown rather than silently trusted.

Checking an answer before it ships

An assistant that rechecks its own arithmetic gets the same wrong number twice. So Flywheel checks a value against the source that decides it and reports three outcomes:

flywheel check-output --contract task.contract.json --answer answer.json --allow-commands

Exit 0 means confirmed, exit 1 means the value disagrees, exit 3 means nothing could confirm it. An unchecked value never reads as a confirmed one. The report also says whether the answer may ship: RELEASE, RELEASE_WITH_CAVEAT, or HOLD with the fields that blocked it. Inside a lane, a held answer does not accept.

Finance, medicine, and law each ship a pack of field templates for the values that go wrong the same way: a dose banded by a formulary rather than computed, a deadline counted in calendar days where the rule counts court days, an amount carried to two decimals in a currency that has none. A pack ships field shapes and arithmetic, no domain data; the authorities stay yours to supply.

flywheel packs medicine

Add --lean Answer.lean --verify-lean and the check is emitted as a Lean 4 file that the kernel runs. What the kernel settles becomes a theorem, what an outside authority decided becomes a named axiom, and one #print axioms line prints everything the result rests on.

The receipt path

Routed runs keep a ledger of tool names, arguments, and outputs. With sealed tool-call receipts enabled, each receipt also records the capability, the outcome, argument and output hashes, and the prior receipt's hash. Sealed receipts form an ordered hash chain, so if one receipt is invalid, later entries in that chain become unverifiable.

The end-to-end gate runs oracle to group to receipt to re-witness with no model and no candidate code executed, and exits 0 only on a MATCH:

flywheel gate

An independent witness re-runs the recorded check offline and reports MATCH, DRIFT, or UNVERIFIABLE. No learned model sits on the accept path. That is the whole point of the receipt: a run you can hand to someone who was not there, and they reach the same verdict.

Honest null

On the shipped benchmark, continued pretraining on the workspace corpus did not improve general code completion: -3.05 points over 164 tasks, p = 0.40. The retired arms benchmark read +0.100 with 95% CI [-0.236, +0.420], an interval that includes zero. No capability uplift is claimed. A receipt shows the check reproduces. Whether the answer is right about the world is a separate question.

A bit about myself, and my mission.

Zain Dana Harper — Mon, 14 Sep 2026 05:48:21 +0000

I spent eleven years on a tree crew and stayed on the ground for all of it. On the ground I was the rigging specialist. I kept the climber safe if something let go above me, and I ran the timing, getting branches and logs of every size and shape to come down safely and fit into places they ordinarily would not, which took finesse and planning. Most of it ran on silent visual contact with the climber up in the tree. A lot of what we did was like a synchronized dance, a ballet of physics where a mistake has real consequences. We made very few mistakes over eleven years, and my father did the same work for twenty years before me.

My family runs back through generations of broken people, and in the house I grew up in the damage never got a name. I picked it up young from the adults around me.

The tree work was my day job. At night I built tools in my free time. I cheated at games and reversed them, working through their memory hooks and offsets to learn how the systems ran from outside.

I still work on AI and its governance from outside the usual circles. There is little traction, and few people outside it know the work is happening. It is the same method I brought to the games, coming at a system from the outside and pushing it to see how it behaves.

I build tools that attack AI systems, and I use AI to build them. That is the purple team method. I aim it at AI safety and alignment. I build the adversarial side so the defensive side has something real to test against, then I feed what the attacks find back into the defenses that are supposed to hold. That is threat-informed defense. The method sits close to me because it runs along my own impulsiveness and the line where accountability starts, and because I still falter.

The companies building systems at scale will not hold themselves to account. I mean the class running the large platforms and the feeds that decide what a lot of people see. I watched what the platforms did to people's attention and to what they take as real. Agentic AI is the next system like that, and the check on it has to come from outside.

One thing I finished on my own is a rendering preset called E L D E R . E N B, built for Skyrim SE. I made it because I wanted a specific quality of light in the game that I could not get any other way, and I built it with no money coming in for the work. It went up on NexusMods, where the download count is approaching one million, with well over a hundred thousand separate accounts running it inside their game.

I work under the name Zentropy Labs. It is not filed as anything and there is no payroll, because I have nobody else to pay. The tools I build under that name are aimed at frontier AI labs, and no pilot is in place at any of them yet.

My main tool is called Flywheel, and it is accountability infrastructure for agentic AI. Every tool call the agent makes gets a sealed receipt attached to it, signed with ed25519. There is a false-accept corpus I test the verifier against, so I know what it will wave through wrong. A learning loop on top of that lets an organization watch its own drift over months. Any run the tool produces has to be re-derivable by somebody outside my machine. If it is not, it does not ship.

I have a young son. He will grow up with AI already part of the world. Safety researchers keep resigning from the largest labs. They do not think the models are being made safe fast enough. The people who run those labs are now asking the industry to pace the frontier and put more into alignment and outside evaluation. That is the work I already do, and I want to keep doing it while he grows up.

The failed install was part of the evidence: reproducing an agent-action receipt

Zain Dana Harper — Fri, 17 Jul 2026 10:09:37 +0000

A reproducibility report gets weaker when it records only the green ending.

Today I evaluated PermitReceipt v2.2.6-public-eval, an evaluation-only release for agent-authorization receipts, in a fresh Windows 11 and CPython 3.12 reviewer environment. The useful result was not just that the final checks passed. The documented portable install path failed first.

That failure belongs in the evidence.

The bounded question

Could a fresh, unaffiliated reviewer verify the release artifacts and run the documented reviewer path without relying on hidden environment state?

This was a narrow reproducibility test. It was not a production-readiness audit, an IETF review, or a claim that the receipt proves an agent action was authorized correctly.

What verified before installation

The release ZIP had this SHA-256 digest:

e5c40eca74fe2f451a0723db915c64b201e1d52f382cee24062e4dfc61fc632f

The archive scan found 261 entries and zero unsafe paths. The release digest and artifact sidecars verified before package installation.

That distinction matters. Artifact integrity, package installability, and behavioral verification are separate claims. One passing result should not silently stand in for the others.

The first failure

Inside the fresh virtual environment, the documented portable path included:

python -m pip install --no-build-isolation -e . --no-deps

It failed with:

BackendUnavailable: Cannot import 'setuptools.build_meta'

--no-build-isolation tells pip to use build tooling already present in the environment. The fresh reviewer environment did not contain the expected backend, so the supposedly portable path depended on setup state that the command did not establish.

This is a small packaging defect, but it is exactly the kind of detail that disappears when a report records only the final green state.

Minimal recovery and downstream result

Installing the pinned build backends was enough to recover:

python -m pip install setuptools==83.0.0 wheel==0.47.0
python -m pip install --no-build-isolation -e . --no-deps

After that recovery, the downstream reviewer suites reported:

IETF-format review packet: 20 of 20 passed
Independent recomputation: 17 of 17 passed
Independent cryptographic verification: 19 of 19 passed

Those suite names come from the release materials. Passing them does not imply IETF endorsement, external certification, or production readiness.

What the receipt should preserve

A useful run receipt needs enough structure to explain both the failure and the recovery. In this case, the minimum record looked like this:

artifact:
  release: v2.2.6-public-eval
  sha256: e5c40eca74fe2f451a0723db915c64b201e1d52f382cee24062e4dfc61fc632f
environment:
  os: Windows 11
  python: CPython 3.12
attempt:
  command: python -m pip install --no-build-isolation -e . --no-deps
  outcome: failed
  error_class: BackendUnavailable
  missing_backend: setuptools.build_meta
recovery:
  packages:
    - setuptools==83.0.0
    - wheel==0.47.0
  outcome: install_succeeded
verification:
  review_packet: 20/20
  recomputation: 17/17
  crypto: 19/19
non_claims:
  - not an IETF endorsement
  - not a production-readiness determination
  - not proof that every agent action was correctly authorized

The exact schema can vary. The important property is that a later reviewer can distinguish what happened from what was inferred.

Five practical lessons

Preserve the failed command. A recovery does not erase the original portability defect.
Separate integrity, installability, and behavior. They are different verification layers.
Pin build backends when using --no-build-isolation, or use build isolation so the backend is established mechanically.
Treat limitations as first-class fields. A receipt should say what it does not prove.
Publish the reproduction path. A claim becomes more useful when another person can inspect the commands and challenge the conclusion.

Public reproduction

I reported the exact bounded outcome, including the failed install and minimal recovery, in the public repository:

https://github.com/meridianverity/permit-receipt/issues/1

If you maintain an agent, MCP, evaluation, or workflow tool and have a public, credential-free fixture, I am interested in running one similarly bounded case and publishing the raw result, including a negative result when that is what the evidence shows.

Disclosure

I maintain the evidence tooling behind Project Telos at Zentropy Labs. I do not maintain PermitReceipt. The tested release is evaluation-only. I used an AI assistant to help structure and proofread this article. The commands, hashes, counts, links, and limitations were rechecked against the recorded run before publication.

Four inspectable workflows for context, research, orchestration, and evaluation

Zain Dana Harper — Mon, 13 Jul 2026 02:08:13 +0000

I learn more from a complete technical workflow than from a feature reel.

A complete workflow shows the input, the command or interface, the intermediate state, the usable output, and the condition that limits the claim. It also leaves enough material behind for another person to inspect the run.

I applied that standard to four public Project Telos tools: Index, Gather, Forum, and Crucible. The resulting recorded-workflow hub contains short cuts, full recordings, commands, evidence packages, and an explicit boundary for every demo.

Here is what each workflow actually establishes.

1. Index: map a workspace, then check the map

Index 2.9.0 scans a sanitized workspace with three repositories. The captured run produces three high-confidence dependency edges and records the file-and-line witness behind each one.

The workflow then checks one dependency directly, returning MATCH for the edge from operator-console to routing-service at pyproject.toml:5. It also builds a bounded context result: 738 of 1,200 tokens, all three repositories retained, zero omitted. The final artifact is an offline atlas.

The fixture is deliberately small enough to inspect by hand. It proves the mapping, evidence, bounded-context, and workbench path. It is not a scale benchmark or a claim of complete language coverage. The run uses no model and no network.

2. Gather: keep the receipt with the research

Gather 1.6.1 converts local source material into addressable, content-hashed blocks. The demo extracts seven structured blocks, stores two records in a local corpus, and re-reads both stored bodies against their provenance records.

The initial verification returns 2/2 MATCH. The workflow then changes a receipt and runs the check again, exposing the tamper path instead of hiding it.

The useful design property is straightforward: recall and verification operate on the stored material, not on a retrospective claim that the material is unchanged.

3. Forum: preserve causal structure across dependent work

Forum 1.13.0 routes one cross-domain backend-and-documentation request into three dependent waves. Upstream results cross typed data edges into downstream tasks. Each wave closes with a checkpoint, and each task result passes its validator.

The captured run leaves 19 ledger entries and three checkpoints. The final checks verify the hash chain and the content-addressed payload bodies.

This workflow uses a disclosed deterministic offline model fixture. That makes the orchestration and evidence mechanics reproducible. It does not measure production-model quality, latency, or cost.

4. Crucible: hold the criterion still

Crucible 1.2.0 evaluates a three-claim artifact. The first run returns 1 MATCH / 2 DRIFT. The artifact is refined while the criterion stays fixed, and the second run returns 3 MATCH / 0 DRIFT.

Two cleanroom reviews pass. The final step re-derives the verdict from the artifacts on disk.

Keeping the criterion fixed matters. Without that constraint, a workflow can make a result look better simply by weakening the test after seeing the failure.

What these demos do not claim

The four tools have distinct jobs and distinct fixtures. The recordings do not pretend that they form one zero-touch production pipeline. They do not substitute fixture results for production-model benchmarks. They do not turn a three-repository map into a scale claim.

That honesty makes the useful connection clearer:

Context must be current enough to act on.
Research material must retain its acquisition and integrity record.
Dependent work must retain its causal structure.
Evaluation must hold its criterion still and expose failure.

When those properties survive a handoff, a completed run becomes part of the capability environment for the run that follows. A map can become onboarding material. A research record can become a test fixture. A dependency plan can become a benchmark. A failed evaluation can sharpen the criterion.

That is the practical meaning of capability compounding.

I am open to paid engineering, applied research, technical writing, contract, and collaborative work across developer tools, AI infrastructure, compilers, graphics, color systems, and technical products.

Open the workflow hub, choose one run, and tell me which boundary deserves the hardest test.

Five short papers on making AI-assisted work re-checkable

Zain Dana Harper — Tue, 07 Jul 2026 04:56:55 +0000

I have released five short papers on one idea: making AI-assisted work re-checkable. All five are archived on Zenodo with DOIs, and source and tests are public.

EMET — a byte-level integrity witness whose verdict {MATCH, DRIFT, UNVERIFIABLE} cannot, by construction, express "trusted." Four implementations, 44 conformance vectors. 10.5281/zenodo.21230267 · source
BuildLang — a compiler that puts ambient capabilities in the function type and seals re-derivable receipts verified by re-execution. 10.5281/zenodo.21231253 · source
Witnessed Independence — records whether a verifier graded its own work, and refuses to decide when independence is not positively witnessed. 10.5281/zenodo.21232206 · source
Proof Packets — an envelope for one agent action whose verdict is derived from checks, so a claim can never vouch for itself. 10.5281/zenodo.21231837
Re-Perceived Effects — replaces an actuator's self-report with a re-perceived effect: on-disk hash against intended hash, return code, witnessed bytes. 10.5281/zenodo.21231747

The common thread: a verdict should be a re-derivable function of its inputs, should say plainly what it does not claim, and should fail to UNVERIFIABLE rather than to trust.

More at harperz9.github.io.

Four short papers on making AI-assisted work re-checkable

Zain Dana Harper — Tue, 07 Jul 2026 01:12:23 +0000

I have released four short papers on one idea: making AI-assisted work re-checkable.

EMET — a byte-level integrity witness whose verdict {MATCH, DRIFT, UNVERIFIABLE} cannot, by construction, express "trusted." Four independent implementations, 44 conformance vectors.
BuildLang — a compiler that puts ambient capabilities in the function type and seals re-derivable receipts verified by re-execution.
Witnessed Independence — a mechanism that records whether a verifier graded its own work, and refuses to decide when independence is not witnessed.
Proof Packets — an envelope for one agent action whose verdict is derived from checks, so a claim can never vouch for itself.

Source and tests for all four are public.

Papers: https://harperz9.github.io/publications.html