Compare

SLSA v1.0 vs SCITT: how they differ, side by side

How SLSA v1.0 and SCITT differ: what each is, who owes it, when it applies and who enforces it.

SLSA v1.0Voluntary framework

SCITTVoluntary standard

Checked21 Oct 2026

01 / Side by side

SLSA v1.0 and SCITT, side by side

	SLSA v1.0	SCITT
What it is	technical specification	technical specification
Jurisdiction	International	International
Legal force	Voluntary framework	Voluntary standard
Status	Superseded	Published standard
Applies from	19 Apr 2023	June 2026
Who owes it	Software producers and build platform operators that want to show build integrity, and consumers verifying artifacts.	Issuers of supply chain statements (e.g. software producers, auditors), operators of transparency services, and relying parties that verify them.
Enforcement	None; voluntary.	None; voluntary.

02 / SLSA v1.0

What SLSA v1.0 requires

Build provenance can apply to model training or packaging pipelines that produce AI artifacts, but SLSA does not address models or data specifically.

01Build L1: follow a consistent build process and generate and distribute provenance describing platform, process and top-level inputs.
02Build L2: run builds on a hosted build platform that signs the provenance.
03Build L3: use a hardened platform that isolates runs and keeps signing secrets from user-defined build steps.
04Consumers verify provenance against expected builder, source and parameters before use.

03 / SCITT

What SCITT requires

Any statement about an AI artifact, such as a model card, evaluation result or dataset hash, can be registered and receipted. The RFC targets software supply chains and does not address AI specifically.

01Issuers sign statements as COSE_Sign1 messages about a specific artifact.
02Transparency services keep an append-only, non-equivocating log that cannot modify, delete or reorder entries.
03Transparency services publish and apply a registration policy, itself recorded on the log.
04Transparency services register a statement before releasing its COSE receipt (RFC 9942).
05Relying parties and auditors verify receipts and log consistency rather than trusting the operator.

Optional evidence · where Planisphere fits

Keep a record anyone can check

When your team meets a duty, Planisphere can seal the event it reports as a receipt.

01 · Your teamRecord the event

A disclosure shown, a review signed, a model change approved: the event your system reports.

02 · PlanisphereSeal it

The event becomes a sealed receipt, dated and attributed to whoever is signed in.

03 · AnyoneCheck it

Paste the receipt into Verify. No account or key.

A record supports your compliance evidence process. It is not a legal finding or a certification. Systems that call Planisphere's gate API can also hold or refuse an action before it runs.

SOURCES