FIELD NOTES / GOVERNED EXECUTION

A small, real Runx receipt workflow

I used Runx to wrap one narrow validation step around an AI-assisted open-source contribution. The useful part was not “an agent ran a command.” It was that the command, input contract, outcome, and receipt boundary were explicit.

Disclosure: this note supports the Runx project and was prepared with AI assistance. It describes a real local run. The receipt used a local-development signature, so I do not present it as production notarization or upstream acceptance.

The actual task

The work target was a generated llms.txt for ModelFuzz. The artifact had six source-linked entries and a fixed SHA-256. Before publishing anything, I wanted a deterministic check that would reject the wrong bytes, the wrong entry count, stale source assumptions, and unsupported security claims.

The validation skill had two small files:

This separation matches Runx’s own model: a skill carries the operating judgment, while the execution profile carries machine-checkable inputs and runtime behavior. The upstream project describes Runx as a governed runtime for portable agent skills and sealed receipts; its current source and quickstart are public at github.com/runxhq/runx.

The run

./node_modules/.bin/runx --version
# runx-cli 0.8.2

./node_modules/.bin/runx skill ./runx-skill \
  -i expected_sha256=bc2bcdd6a6327f5caacb608d77198cd63598447ec01e675aaa57a43e191d5662 \
  --receipts /tmp/runx-goodwill-receipts \
  --json

The projected result was deliberately small:

{
  "status": "sealed",
  "skill_name": "modelfuzz-llms-validation",
  "result": {
    "validation": {
      "status": "pass",
      "artifact": "llms.txt",
      "entries": 6,
      "sha256": "bc2bcdd6a...1d5662"
    }
  }
}

Verification, with the caveat left in

./node_modules/.bin/runx verify \
  sha256:19eb3db88f43b5b71d43cca4234be0492a6e01c4324f293f049f7b7a458b635f \
  --receipt-dir /tmp/runx-goodwill-receipts \
  --allow-local-development-signatures \
  --json
Verificationvalid: true
Receipt tree1 receipt
Findings0
Signature modelocal-development

The flag matters. A local-development signature is useful for reproducible local evidence, but it is not a production trust anchor. Keeping that distinction visible is more valuable than turning a green JSON field into a larger claim.

What Runx added — and what it did not

It added: a typed input boundary, a named runner, a compact sealed outcome, a receipt tree, and a separate verification command. That made the validation step easier to inspect and repeat.

It did not add: maintainer approval, CI, deployment, factual correctness of every source, or bounty payment. Those remained separate external gates. The associated upstream pull request is still evidence of work in progress, not evidence of income.

That is the use case I find credible: use Runx to make one act narrower and more inspectable, then keep external acceptance and settlement outside the receipt’s claims.

Useful starting points