runward

RW™ · V0.36.1

Docs · Understand · The perimeter

The perimeter: runward and its neighbourhood.

One map, two axes: which moment of the delivery arc each tool governs, and who authors the verdict. Spec-driven, harnesses, artifact custody, admission — and the square runward holds alone. Findings dated August 2026.

This page places runward among its neighbours — upstream, downstream, and in the harnesses — on the only two questions that separate them mechanically: which moment of the delivery arc each governs, and who authors the verdict. Findings dated August 2026, taken from each tool's own documentation.

The perimeter: at which moment of the arc, and who authors the verdictTwo axes, and they are enough to place the whole neighbourhood. Horizontally, the moment governed: from intent (the spec) to running in production, through construction, build, artifact custody and promotion. Vertically, who authors the verdict: a model that judges (advisory, non-blocking), a human who reviews, or deterministic code. The spec-driven tools (Spec Kit, OpenSpec, BMAD) occupy the intent moment with a model verdict; the harnesses (Bugbot, Copilot review) judge code at review time, still by model; Chainloop, Kosli and JFrog govern the published artifact, its custody and promotion, by code; Kyverno and OPA admit at runtime. runward sits alone on its point: the construction moment, before the merge, with a deterministic code verdict. Nobody disputes that square, and that is what the map shows — not a superiority, a position. intentruntimeMoment governed → a model judgesdeterministic codeWho authors the verdict → Spec KitOpenSpecBMADSpec KittyBugbot · Copilot reviewhuman reviewrunwardChainloopKosliJFrog EvidenceKyverno · OPA
The perimeter: at which moment of the arc, and who authors the verdict

What the map says

Three clusters, and one square held by a single tool.

Bottom left: intent, judged by a model. Spec Kit, OpenSpec, BMAD and the review harnesses occupy the start of the arc. They frame intent, they produce code, and when they render a verdict a model rendered it — their own docs say so: "advisory … provides recommendations, not blocking", "does not block archiving".

On the right: the published artifact, governed by code. Chainloop, Kosli, JFrog Evidence, then Kyverno and OPA at admission. Deterministic verdicts, but about an already-built object: its provenance, its custody, its promotion, its admission.

Between the two, a square nobody else occupies: the construction moment — after intent, before the merge — with a verdict rendered by code. That is where runward stands. Not a superiority, a position: the others are not there because it is not their job.

The table, tool by tool

Tool Object governed Moment Verdict rendered by Ingests Emits
Spec Kit the specification and its coherence intent a model (/analyze produces a Markdown report) spec artifacts
OpenSpec the spec delta intent deterministic for structure (openspec validate), a model for the substance (/opsx:verify, "does not block") archived proposals
BMAD the persona-driven cycle intent → code a model (a "Quality Gate Decision" its docs call advisory) PRD, stories
Spec Kitty review and code intake code deterministic e2e gates, plus an AI review for acceptance bespoke YAML
Harnesses (Bugbot, Copilot review, Codex) the proposed code review a model the diff comments
runward construction decisions before the merge deterministic code committed reports (JUnit, SARIF, coverage, lint, SBOM) an attested verdict, re-derivable offline (in-toto, VSA, SARIF)
Chainloop what the build produced build code (a pipeline contract) 17 evidence types (SBOM, VEX, SARIF…) signed in-toto attestations, stored
Kosli the artifact and its trail build → release code evidence files, including external ones an immutable Evidence Vault
JFrog Evidence the artifact, the build, the Release Bundle build → promotion code signed external evidence attestations attached to the artifact
Kyverno · OPA the admitted workload runtime code signed attestations an admission, or a refusal

The two questions to ask

Faced with a neighbouring tool, two questions are enough to know whether it overlaps runward:

  1. Does it govern the working tree before the merge, or an artifact after the build? If the second, there is no overlap: runward's verdict becomes one more piece of evidence in its chain (the release layer has the recipes).
  2. Who renders its verdict? If a model does, the verdict is an opinion: it does not re-derive, two runs may diverge, and the agent that produced the code takes part in judging it. That is not a criticism, it is a property — but it decides what the verdict can be used to prove.

What the map does not say

It does not rank by quality, maturity or adoption: those are real axes, and they do not belong on a technical page. Nor does it say that occupying a free square is an advantage — a square can be free because nobody wants it. What it says is narrower and checkable: for an agentic system the load-bearing decisions are taken before the merge, and no other tool on this map renders a deterministic verdict at that moment.

← Docs