🗂️ Harness Path — The DTG Verification Registry

14 · the DTG verification registry — an acceptance flow, human-gated — an entry in the origin fleet catalogued in The Harness Paths (group: Adjacent embodiments). The catalogue is the operator's work WITH the harness, not part of the system you adopt; none of its code lives in the harness repo. This is the map entry, so you can see what a filled config looks like at this weight.

(instance of the author as task-force co-chair — public repo + Pages site;
the discipline run as an agent-operated acceptance flow over a ZK
ceremony orchestrator suite)

Three Groth16/BN254 circuits with pinned constraint counts; a submission
re-runs the orchestrator on its own machine and must byte-match the digest
manifest on the required artifacts (r1cs, wasm, the constraint
counts), while the trusted-setup chain digests are advisory by design —
snarkjs folds its own randomness into every contribution, so advisory
divergence is the expected signature of an independent build, not a
failure. The hard constraint lives in code, not policy: the decision
consumes only the pinned block and the manifest — platform, tools, and
timings can never move a verdict. Around that verifier sits the acceptance
flow, gates A–G: the agent operates, the maintainer decides — admission
(C) and publication (G) are HUMAN; every reply carries a mandatory
disclosure of agent involvement; and G.1, the publication rite, has the
agent serve a one-line proverb compressing what this publication means,
answered by the maintainer's typed activation — a challenge–response at the
human gate, fresh per push. The agent's own canary set includes the rule
that a submitter's verdict: ACCEPT line is a prediction to check, never
a result to record. The registry's six-entry arc is the whole method in
miniature: maintainer reference → timestamped repeat → first cold
public-clone run (proving the instructions) → pseudonymous seat (proving
identity is not required) → full digest match from that seat → the first
external run (darwin/arm64: required digests byte-identical across
architectures). There is no 0001 — an auto-id collision, admitted in the
flow itself. And the prohibited thing cannot be built: the phase-2 ceremony
entry point throws unconditionally until its governance gate closes.

At a glance —
objective: none to minimise — an acceptance flow; the registry row is the unit, and honest acceptance is the product · gate: verify-run.mjs — required-artifact digest byte-match against the pinned manifest; named failure strings; exit 0 = ACCEPT · hard constraint: the decision reads only pinned + the manifest — never the informative block (asserted by orchestrator tests)
the Gap: none drawn — the submitter is outside the workshop, so the separation is the architecture itself; the human gates (admission, publication, the G.1 proverb rite) are the verification the flow adds · canary: the maintainer's own reference build, which mints the manifest and passes it by construction · governing sentences: agents orchestrate entropy; they are never the entropy · no phase-2 ceremony before the gate closes
weight: acceptance flow, human-gated · public registry + Pages site, prebuilt and committed so CI never enters the trust story · the lesson it carries: an acceptance flow is a harness read backwards — the proposer arrives from outside, and what keeps an agent-operated registry honest is the human door plus disclosure, made structural.

Navigation

← Welcome Visitors · The Harness Paths · Adopting The Harness · Workflows And Runtimes

the wiki is a projection; ~/dual-agent-harness (git) is the source of truth · (⚔️⊥⿻⊥🧙)😊 = neg ⊕ bnot → succ