Inspect manifests, lock files, SBOMs, build provenance, attestations, signatures, model cards, dataset records, and dependency graphs as machine-readable evidence.
Supply-chain artifacts make composition and lineage inspectable, but they provide value only when generated at the correct stage, bound to the exact artifact, verified against policy, and understood as evidence rather than proof that software or a model is safe.
The submitted report remains byte-identical. This separate review, checked 2026-08-26, narrows implementation claims and gives visitors a decision path before they generalize from a local result.
Output produced deterministically by the local runtime.
Useful model or subset that must not be mistaken for full conformance.
Conclusion that needs an exact implementation, trust system, model, parser, or human review.
| Question | What the local page can answer | What it does not establish | Next evidence step |
|---|---|---|---|
| What components, references, digests, and claims are declared? | The bounded structural inventory reports selected fields. | Schema conformance, completeness, or truth. | Validate with the exact specification schema and compare to the artifact. |
| Is the attestation or signature valid? | No cryptographic verification occurs. | Identity, certificate, transparency, builder, or subject binding. | Use an approved verifier and expected-identity policy. |
| Is the artifact safe to deploy? | No safety or deployment decision is made. | Vulnerabilities, malicious behavior, license, or organizational policy. | Combine verification, scanning, review, and admission policy. |
Separates component graphs, provenance claims, digest syntax, and cryptographic verification.
Expected boundary: Both fixtures parse deterministically without resolving any external artifact.
Open prepared laboratoryNo single view is automatically authoritative. Preserve the source, identify each parser or receiver, and compare their outputs before authorizing a consequential decision.
Requested dependencies, versions, sources, or model configuration.
Exact components and transitive relationships used by a build.
Composition, services, identifiers, licenses, hashes, and completeness.
Subjects, materials, builder, parameters, and workflow claims.
Cryptographic authorization requiring certificate and policy verification.
What was actually deployed or loaded, compared with published metadata.
The workflow preserves evidence before transformation and keeps structural inspection separate from execution, remote verification, or model behavior.
These controls are contextual. They reduce a defined risk; they do not guarantee safety, truth, attribution, or resistance to every adaptive attack.
Pin dependencies and verify lock-file hashes.
Declare BOM completeness and unresolved relationships explicitly.
Keep structural inspection separate from cryptographic verification.
Treat model weights, tokenizers, adapters, and datasets as separate signed subjects.
Enforce consumer-side admission policy rather than merely publishing metadata.
Definitions are linked into the site-wide glossary and back to the full report.
A machine-readable inventory of software components and relationships.
Verifiable metadata describing how an artifact was built.
An authenticated statement about an artifact or process.
An output artifact to which an attestation applies, usually identified by digest.
An input consumed by the process described in an attestation.
An append-only log making signing events auditable.
A bill of materials describing models, datasets, configurations, and AI relationships.
A deterministic record of resolved dependency versions and often hashes.
A directed graph of direct and transitive component relationships.
These links are provided for visitors who want the governing specification, paper, framework, or implementation documentation. Links open in a new tab; the site does not fetch them during runtime analysis.
Build provenance levels, tracks, and verification.
Normative or first-party specification material.Software, build, licensing, security, AI, and dataset models.
Normative or first-party specification material.Components, services, dependencies, vulnerabilities, and formulation.
Normative or first-party specification material.Secure software development practices.
Normative or first-party specification material.AI model development community profile.
Normative or first-party specification material.Secure-by-design principles.
First-party guidance, framework, registry, or standards-program material.Model and dataset transparency capabilities.
Tool, vendor, or implementation documentation; behavior is version-specific.Keyless signing and transparency concepts.
Tool, vendor, or implementation documentation; behavior is version-specific.Signing and verification workflow.
Tool, vendor, or implementation documentation; behavior is version-specific.Automated open-source security posture signals.
Tool, vendor, or implementation documentation; behavior is version-specific.The full submitted report is preserved byte-for-byte in the governed research library and in durable repository documentation. The laboratory turns selected concepts into deterministic local output without external calls or hidden persistence.
A structural analysis of manifests, lock files, SPDX, CycloneDX, SLSA, in-toto attestations, Sigstore, model and dataset artifacts, tampering risks, secure release controls, verification, and metadata limits.
Read governed reportInspect bounded CycloneDX, SPDX, in-toto, SLSA-like, lock-file, or model-card JSON/XML/text as inert structure without resolving dependencies or verifying remote signatures.
Open bounded laboratory