The stages of supply-chain-release and automated-release are named after the evidence they demand, never after a level in a framework. That is deliberate. tik checks that a trusted attester said a thing; it never reads an SBOM or a provenance document and forms no opinion about their contents. A stage called slsa-l3 would put that overclaim into the derivation itself, where every badge, lens and consumer assertion would faithfully repeat it.

What supply-chain-release demands maps onto SLSA’s build requirements like this — and the table is a claim about the definition, never about any ticket that pins it. automated-release demands the same, minus the two-person row:

A build’s SLSA level is a property of the build platform, and no ticket system can confer one. What this gives you instead is the thing an auditor actually asks for months later: which rules judged this release, what evidence was supplied, who signed it, and how to recompute the answer without trusting anybody’s word.

Carrying the publication signature into your bundles

Adopting a definition preserves its identity — the address is over the parsed definition, so the pretty-printed copy in your store hashes to the same value. It does not bring the signature, so a bundle you produce carries the rules but not our word for them.

To carry that too, copy the signed archive alongside:

cp processes/by-hash/<hash>.edn      <your-store>/processes/by-hash/
cp processes/by-hash/<hash>.sig.*    <your-store>/processes/by-hash/
cat actors >> <your-store>/actors     # so the signature has a key to check against

tik leaves an archive that already exists alone, and tik bundle ships every file whose name starts with the pinned hash. So your evidence bundles then carry our signature over the rules that judged your release, and the recipient’s verify.sh checks it with ssh-keygen and nothing else:

ok    sha256-c1cffcb2….sig.e8290a63236755f2 verifies as seb
bundle: PASS