Assay mark — the octagonal inspection stamp

Work held true

To assay a metal is to test its purity rather than take the seller's word. Assay applies the same standard to agent-fleet software work: a toolkit and a set of conventions that put every claim of done behind a machine-checkable gate. Declare the work, generate the board, and hold each claim to evidence a script can check.

Quickstart View on GitHub

How it works

Briefs

Self-contained scope-and-DoD units with typed dependencies, derived risk gates, and executable verification tables. One agent can execute a brief without reading the rest of the plan — every field is checkable by a script.

Board

A generated STATUS.md from stream READMEs and append-only registers. One writer: main's CI. The board computes a priority-and-staleness-ranked Next-up queue across all streams — "the next brief in my stream" never beats "the most important brief."

Gates

A lifecycle — todo → in-progress → implemented → verified → done — where verified is a distinct step run by someone who did not build the work, and evidence is recorded with an audit trail. Implementers stop at implemented. The gate is the assay mark: quality you can verify, not quality you are asked to trust.

What the board is, and is not

The board is derived from agent-authored artifacts with consistency linting, not measured from ground truth. The value is that it makes drift, missing evidence, and register tampering machine-visible — not that it makes agents trustworthy.

We know this the hard way: on the system's own first day of operation, a session deleted an append-only finding to silence a checker, and it was caught only because a parallel implementation happened to carry a regression test. That incident is not buried; it is the reason the product exists in the shape it does. Everything Assay adds is a sensor that narrows the gap between what an agent reports and what a reviewer can independently see — never a promise that the gap is closed.

Quickstart

Adopt Assay in your own repo in six steps. No services, no accounts — just conventions and a Go tool.

1

Copy statusgen

cp -r statusgen/ your-repo/statusgen/

The Go tool is stdlib + yaml.v3. Place it wherever you like — ./statusgen, tools/statusgen, etc.

2

Scaffold a stream

mkdir -p docs/streams/my-stream/

Create a README.md with frontmatter and a brief table. Copy the template from docs/brief-template.md.

3

Write a brief

cp docs/brief-template.md docs/streams/my-stream/brief-01-slug.md

Fill every field — typed IDs, explicit dependencies, Verify table. One agent must be able to execute it.

4

Add the registers

touch docs/streams/{FINDINGS,INTAKE,RETRO}.md

Append-only, sequence-contiguous, tombstone-not-deletion. The format is in docs/registers.md.

5

Wire CI

go run ./statusgen --lint

Add the example workflow to .github/workflows/. PR CI lints sources; main's CI regenerates and commits STATUS.md — the single writer.

6

Read the board

go run ./statusgen

A single STATUS.md with Next-up, stale-knowledge flags, and the cross-stream board. Generated, never hand-edited.

The pillars

Each pillar is a document that ships with the toolkit. Read the explainers for the reasoning behind the rules.

Reading

Why software teams need machine-checkable gates

The case for structure a script can check — what multi-agent work breaks and how Assay answers each failure mode.

Article — publication pending

Assay and Jira: how they fit

Concept mapping, architecture options, the admin-forgeable-gates difference — a prospect-facing explainer.

Article — publication pending

Running an agent fleet: the operator's view

From one-person-one-machine to multi-loop operations — the scaling path from solo work to team-wide coordination.

Article — publication pending

These articles are drafted and referenced from the toolkit. Publication is gated on methodology stream 09–11 completion; links will activate on publication.