DEV Community: Zain Dana Harper

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