# A witness should not become a ruler

An expanded editorial essay prepared with Codex for Zain Dana Harper. The author requested the expansion and approved this website essay for publication. It explains a program of work. The related manuscript remains in preparation; this website essay has not undergone journal peer review.

A record can be intact and the decision made from it can still be wrong.

I want someone opening my work to have enough information to decide what deserves their time. A researcher should be able to find the source behind a result and attempt the check. Someone choosing a tool needs to understand what it takes in, what it produces, and where it stops working. A person affected by an automated action needs a way to question its basis.

Flywheel is the application through which I am trying to connect that work. Its surrounding tools deal with finding material, keeping context, running tasks and examining what happened. Each has a specific job. The connection between those jobs matters because information changes as it moves: a source becomes an excerpt, an excerpt supports a proposal, and a recorded success may later influence another action.

The boundaries have to remain visible through that movement.

In [Pick The Lock for Everyone](https://harperz9.github.io/pick-the-lock-for-everyone.html), I wrote: “Nothing I build gets to inherit authority from the fact that I hate authority.” That sentence governs my own software. A person can find a real institutional failure and still build a bad replacement. The people using my tools need practical ways to inspect them, disagree with a result, preserve their work and leave.

## Entering research from outside academia

I am an independent builder without an academic background. I am trying to contribute through software, writing and inspectable work. My portfolio lets someone see what I have attempted. The evidence for a particular contribution belongs with that contribution, where another person can examine it.

That distinction gives me a route into the work and a responsibility. I need to read the earlier literature, learn the terms other people use, and discover which parts of my argument have already been established. An unfamiliar name for a familiar idea adds work for the reader. When I borrow a method, I should credit it and explain the part I changed. If I misunderstand an established result, the correction needs to remain attached to the public record.

Academic training provides sustained contact with methods and with people who can identify errors that a beginner cannot yet see. I want access to that criticism. Working outside the institution means I have to seek it deliberately and make the request manageable. A reviewer should receive a clear question, a bounded artifact and enough context to determine whether the claim survives examination.

The same standard can help other contributors whose route into a field looks different from the expected one. A useful bug reproduction, a carefully documented negative result or an accessible implementation can give a research team something it needs. The contribution still needs an appropriate check. For software, that may include reproduction on another machine and review of failure cases. A mathematical claim requires its assumptions and argument to withstand mathematical scrutiny. A claim about people learning requires evidence about people learning.

An [ORCID record](https://info.orcid.org/documentation/collecting-and-sharing-orcid-ids/) helps identify and connect a person's work. Publishing on my own website makes the material available. The status of a paper must separately say whether it is a draft, a preprint, submitted work or an accepted publication. The accompanying research manuscript for this program remains in preparation. Before I present it as new research, I need to state the contribution more sharply against the existing literature.

I expect AI to let more people attempt work across those boundaries. Review effort will remain a scarce resource. Someone has to determine whether a convincing explanation matches the underlying system, whether a citation supports the sentence, and whether the experiment tests the stated question. Part of my job is to reduce the work I pass to that person.

## What the byte witness can say

[EMET](https://harperz9.github.io/emet.html) compares material against an explicitly chosen byte-level anchor. Its core specification permits the integrity results `MATCH`, `DRIFT` and `UNVERIFIABLE`. These results describe what that check established. A match says that the comparison agreed under its declared procedure; accuracy of the source and permission to act require further evidence. The [specification](https://github.com/HarperZ9/emet/blob/main/SPEC.md) defines the boundary, and the [rationale](https://github.com/HarperZ9/emet/blob/main/RATIONALE.md) explains the argument behind it.

The phrase *byte-witness incapable of authority* describes the role I give this component. EMET's integrity output cannot grant permission. Another component can check a signed authorization against an accepted policy, provided the relevant scope and current state are available. The people who choose that policy still owe an account of their choice to those it affects.

Consider a document that an agent has prepared for one recipient. The reviewer approves a particular attachment. Before the send, the application needs to check that attachment, the destination and the permitted action against the approval. Afterward, a delivery observation can establish what the service reported. If the connection fails at an uncertain moment, the record must preserve that uncertainty so a retry does not quietly become a second send.

The document's digest answers one part of that sequence. It carries no account of whether the recipient was appropriate or the document's advice was sound. Those questions have to remain available to the person reviewing the action.

A restricted vocabulary also needs careful treatment in the interface. A downstream component could turn a narrow match into a broad green badge. A memory system might retain the word “success” while discarding the conditions under which it was recorded. The controls need tests at those connections, where an accurate result can take on an unsupported meaning.

## What a reviewer should be able to see

A citation to an entire repository leaves too much reconstruction to the reader. For a specific claim, I want the source version and the part that supports it. A code reference can give a commit, file and line range with the relevant excerpt. A structured record can give a JSON pointer such as `/actions/2/destination`, together with the value at that pointer. Text offsets need a declared convention, including whether they count bytes or characters.

The excerpt also needs enough surrounding context to preserve its meaning. A line that says a check passed might belong to a deliberately failing control or a skipped branch. A source hash helps detect later changes; the reader still has to determine whether the selected material supports the claim.

For actions, that source reference belongs with the purpose of the task, the identity acting under its permission, the exact target and the supplied inputs. The record should distinguish an intended action from an attempted one. An observed response needs its own location, with the time or sequence needed to connect it to the request. If output was truncated or a source withheld, the reviewer should see the omission beside the result.

Privacy affects how much context can be shared. A public report can carry a scrubbed example and describe the private evidence needed for a fuller review. An authorized reviewer may receive more through a controlled route. The public should never be invited to treat an undisclosed source value as though it had already inspected it.

These are requirements for the review experience. The toolkit contains pieces of this work at different stages. Completing a schema or producing a valid receipt does not establish that every action supplies this context today.