Attestations
An attestation is a signed statement about something that happened in your pipeline.
Attestors
An attestor is a plugin that asserts facts about a system and stores those facts in a versioned schema. Each attestor has a Name, Type (a versioned URL identifier like https://aflock.ai/attestations/git/v0.1), and a RunType that determines which lifecycle phase it runs in.
DSSE & in-toto
DSSE (Dead Simple Signing Envelope) and in-toto are the standardized envelope and provenance formats that make CI/lock evidence interoperable with the wider supply-chain tooling ecosystem.
Signing & identity
A signer is the cryptographic identity used to sign an attestation. In policy, the signer is what gets evaluated against a functionary: the policy's declaration of who is allowed to sign for a given step.
Timestamping
A timestamp authority (TSA) adds trusted time information to a signature.
How CI/lock captures files (walk, ptrace, fanotify)
CI/lock determines a step's materials (inputs) and products (outputs) by directory walk, syscall tracing (ptrace+seccomp, or eBPF where available), and fanotify content hashing — this page explains each, how to select it, and the tradeoffs.
Auto-detection and default attestors
CI/lock auto-detects which attestors to attach by inspecting the workspace and the wrapped command — but only when you don't pass -a. This page explains the default set, the --workload modes, and how to dry-run with --validate-only.
Step categories and --step inference
CI/lock names each pipeline step with a category from a closed lexicon (19 core + 26 specialized + namespaced extensions). When you don't pass --step, CI/lock infers it from the wrapped command. This page explains the lexicon and the inference rules.
Merkle trees
A Merkle tree is a binary tree where every leaf is a hash of some data and every interior node is a hash of its two children. The single hash at the top — the root — commits to every leaf simultaneously. If a single byte changes anywhere in the input set, the root changes.
Inclusion proofs
An inclusion proof is a short list of hashes that lets a verifier confirm "this leaf is in this tree" without seeing the whole tree. It is the primitive that makes Merkle trees useful as a public, queryable evidence structure: a producer publishes a signed root over millions of entries, and a consumer who only cares about one entry pays the cost of a single proof — O(log n) hashes — rather than re-downloading every leaf.
The spine of the graph
CI/lock's verifier walks a subject-digest graph. The walk is BFS… or -f path/to/artifact), find every attestation whose subject set contains that digest, expand the seed set with the back-references those attestations declare, and iterate until the frontier stops growing.
Evidence storage
A signed attestation is only useful if you can find it again. CI/lock supports several places to put the evidence after signing.
Policy verification
A CI/lock policy is a signed document that encodes the requirements for an artifact to be validated. It includes trusted public keys (or X.509 roots), the steps that must appear in the supply chain, the functionaries trusted to sign each step, and embedded OPA Rego rules to evaluate against attestation contents.
Trust model
This page is the deliberately honest version of "what does CI/lock actually protect against?" It's worth being precise here, because supply-chain tooling is easy to overpromise.
SCITT relationship
SCITT — Supply Chain Integrity, Transparency, and Trust — is an IETF working group standardizing how supply-chain attestations get registered in transparency services. CI/lock is not a SCITT implementation today. This page explains what SCITT is, where CI/lock's v0.3 design overlaps with the underlying primitives, and what would need to happen to bridge the two.
Dogfooding CI/lock releases
If our policy or our attestor logic were unsound, our own release would