Docs · Understand · After the spec · The release layer
The release layer: Kosli, JFrog, Chainloop.
"Don't we already have Kosli?" — no, and it is more interesting than a no: custody of published artifacts is the layer runward sits under. Findings dated August 2026, from their own documentation.
If your chain already carries Kosli, JFrog AppTrust or Chainloop, the question comes up: does runward do the same thing? No — and the reason is mechanical, not commercial: those tools verify an artifact after the build; runward verifies a working tree before the merge. This page describes both mechanisms and how they plug into each other.
The whole map. This page covers the downstream. To place the entire neighbourhood at a glance — spec-driven, harnesses, custody, admission — and the square runward holds, see the perimeter.
Two stages, two objects
| What is governed | When | What is verified | |
|---|---|---|---|
| runward | the working tree | before the merge | the load-bearing decisions were made, traced, and backed by evidence that resolves |
| Kosli, JFrog Evidence, Chainloop | a published artifact | after the build, at promotion | the provenance, the custody, the compliance of the pipeline that produced it |
The release layer answers "does this artifact come from where it claims, and did it pass what it had to pass?". runward answers "were the choices that will keep this system alive actually made and proven, before the code went in?". Neither question replaces the other, and a system that answers the first without the second ships an impeccable chain of custody around a system whose architecture nobody arbitrated.
What these tools do, in their own words
Findings dated August 2026, taken from their own documentation, never from third-party summaries.
- Chainloop presents itself as an open-source evidence store and policy engine for the software supply chain: its CLI runs inside the CI pipeline, picks up what the build produced, uploads those files to content-addressable storage and references each one in a signed in-toto attestation. It checks that a pipeline meets its contract: one that stops emitting a bill of materials stops satisfying it. First-class support for 17 evidence types (SBOM, OpenVEX, CSAF, SARIF…).
- Kosli records changes "to prove compliance without slowing down", with an immutable, append-only Evidence Vault holding the evidence files (JUnit results, attachments) and their digests. It operates on flows and artifacts once produced.
- JFrog Evidence attaches signed attestations to artifacts, builds, packages and Release Bundles v2 (Artifactory 7.111+), with a partner ecosystem covering build and promotion stages.
The common thread, and it is the one that matters: all three take what the build emitted. None looks at a working tree before the merge, because that is not their job.
How the two plug together
All three accept external evidence. A runward verdict therefore becomes one more evidence type in their chain:
# Kosli — the verdict as generic evidence on the artifact's trail
kosli attest generic --name runward-gate --flow <flow> --trail <trail> \
--attachments verdict.dsse.json --compliant=true
# JFrog Evidence — external evidence attached to the package version
jf evd create --package-name <pkg> --package-version <v> \
--predicate verdict.intoto.json --predicate-type https://runward.dev/verdict/v1
The --compliant value comes from runward's exit code, never from a human retyping a verdict they did not re-derive. The full recipes (cosign signing, Archivista/Chainloop/OCI deposit, Kyverno admission on a VSA) are in the repository's docs/interop.md.
What runward produces that this layer cannot
An evidence store keeps what it is given. It cannot manufacture evidence nobody produced — and the architecture decision taken before the first commit is emitted by no pipeline. That is the material runward produces:
- a load-bearing decision traced and ratified (an ADR, with its re-evaluation trigger), not merely a timestamped artifact;
- evidence that resolves: a typed pointer that opens a file, finds a symbol at an identifier boundary, reads a test case recorded green, a scan with no open finding;
- a verdict re-derivable offline:
runward verifyrecomputes it from the tree alone — no network, no trust root, no key. An evidence store proves a file has not moved; runward recomputes the judgment itself.
What runward does not do, and will not
It does not publish, deposit, aggregate or watch. There is no runward push, no fleet view, no hosted store: those are runtimes, on the operator's side (ADR-0054). A tool that governs a fleet needs a service running; runward needs a directory and a filesystem. That is what lets it return the same verdict on your laptop, in your CI, and at your auditor's, months later.