# 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.

> **Diagram.** Two 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.

## 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](https://runward.dev/docs/en/compare/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.**

## See also

- [After the spec: the comparison](https://runward.dev/docs/en/compare/)
- [The release layer: Kosli, JFrog, Chainloop](https://runward.dev/docs/en/compare/release-layer/)
- [Concepts: the deterministic gate](https://runward.dev/docs/en/concepts/the-gate/)
- [Evidence & integrity](https://runward.dev/docs/en/concepts/evidence/)