Enterprise First-Model Release Evidence, Supply Chain, Deployment, and Living Documentation

Full report

On this page

Executive Release-Control Recommendation

The deployment and public availability of the TinyRustLM SLM2 model represent a critical operational threshold that demands absolute cryptographic certainty, reproducible build pipelines, and transparent public evidence graphs. The fundamental architecture of this release designates the TinyRustLM project as a single, unversioned prelaunch product. Consequently, there exists no product V2, no legacy-user population to support, no backward-compatibility duty, no migration paths, and no acceptable technical debt. The pipeline explicitly forbids hidden retries, response repair loops, alias implementations, or fallback runtimes. Technical classifications such as SLM2 and Tokenizer2 are treated strictly as format identities rather than iterative version numbers. The exclusive objective of this deployment architecture is to deliver one genuine, provenance-bound, production-quality Qwen3-0.6B SLM2 composition. This delivery spans across scalar native formats, optimized native execution, browser-WebAssembly (WASM) environments, peer-to-peer (P2P) or conversion acquisition pathways, and genuine multi-turn browser-local chat. Prior attempts to instantiate this release, specifically the operation designated as /10, encountered immutable terminal-failure during managed receipt inspection. Although this execution emitted candidate files, the strict zero-trust parameters of this architecture dictate that this operation cannot be repaired, retried, adopted, published, or retrospectively categorized as a success. A complete source-level contract correction serves as the mandatory, primary input to an entirely new registration pipeline. To preserve repository integrity and security, large model weights, raw output data, and private cryptographic evidence bytes must strictly remain outside of the Git source control system. Git is reserved exclusively for bounded public schemas, test vectors, documentation, technical identities, terminal statuses, and release records. Furthermore, the architecture explicitly dictates that MemoryEndpoints remain unauthorized and completely outside the scope of this release. Campaign counters are firmly locked at their zero-state (0/20 qualified models, 0/50 clean browser rounds, 0/25 live memory rounds, 0/40 externally proven P2P lanes, and 0/20 catalog announcements) until exact, cryptographically signed, live evidence is generated by the production system. No site, documentation, or public log may imply unproven model capabilities or network reachability.

End-to-End Phase and Invalidation Graph

The release process is structured as a strictly enforced Directed Acyclic Graph (DAG) of verification phases. The progression from source code to public availability requires the successful execution, cryptographic signing, and terminal success state recording of every sequential node. A failure at any specific node cascades into an invalidation edge, requiring a localized or complete pipeline rollback depending on the nature of the dependency. Table 1 defines the end-to-end phase graph, prerequisites, and invalidation triggers.

The pipeline strictly governs selective rerunning. If an orthogonal input changes—such as a modification to the HTML layout of the public site—the system is permitted to rerun starting from the Package/Site Release phase. This selective rerun leverages the cached, cryptographically signed receipts of the upstream Model Qualification phase, avoiding the computational expense of re-executing valid tensor conversions. Conversely, any modification to the Rust inference engine, memory allocation logic, or mathematical parameters necessitates a complete rerun originating from the Toolchain/Build Custody phase. The failed /10 attempt represents an immutable failure state and can never act as a cached input or partial success for any phase in the DAG.

Receipt Schema Family and Immutable History

The release architecture mandates the generation of content-addressed cryptographic receipts for every phase defined in the DAG. These receipts establish an unbroken chain of custody from source code to deployed artifact, leveraging the in-toto attestation framework and the Supply chain Levels for Software Artifacts (SLSA) v1.0 specifications4.

The in-toto Statement Layer

Every generated receipt is enveloped within an in-toto Statement, providing the secure cryptographic transport layer. The envelope binds the metadata to the specific software artifact through cryptographic hashing. The payload type is strictly formatted as application/vnd.in-toto+json6. This structure explicitly maps the subject (the compiled binary, package, or raw weight file) to the predicate (the specific metadata regarding the action performed on that subject)6.

SLSA 1.0 Provenance Predicate

For the Toolchain/Build Custody and subsequent compilation phases, the system utilizes the SLSA 1.0 provenance predicate. The schema identifier is explicitly defined as https://slsa.dev/provenance/v15. This predicate fulfills SLSA Level 3 requirements by ensuring the provenance is non-falsifiable and generated securely by the control plane9. The SLSA 1.0 predicate divides the metadata into buildDefinition and runDetails. The buildDefinition explicitly binds the Git commit, external parameters, and pinned toolchain dependencies, while runDetails binds the exact environment, CI runner identity, and temporal execution data5. Raw, private evidence files (e.g., massive log dumps or proprietary intermediate weights) are not embedded in the JSON; instead, their SHA-256 hashes are recorded within the externalParameters or resolvedDependencies blocks, linking the immutable evidence without bloating the public repository.

CycloneDX 1.6 Machine Learning Bill of Materials

During the Output-Free Registration and Independent Composition Inspection phases, the architecture requires the generation of an AI Bill of Materials (AIBOM) adhering to the CycloneDX 1.6 standard13. CycloneDX 1.6 introduces dedicated support for machine learning models, allowing the precise declaration of architectural parameters16. The CycloneDX predicate defines the Qwen3-0.6B SLM2 composition. It explicitly records the foundational architecture constraints, including a decoder-only transformer setup utilizing Rotary Position Embeddings (RoPE), SwiGLU activations, and RMSNorm, configured with exactly 24 layers, 14 query heads, and 2 key-value heads1. This cryptographic receipt serves as the immutable proof that the converted model structurally matches the intended target before expensive test matrices are initiated.

Immutable Supersession

The system maintains a strictly append-only ledger for immutable evidence. Failed receipts, such as the output from the /10 operation, and obsolete receipts from prior builds are permanently retained in the designated evidence bucket and are never overwritten. Production readers and verification scripts evaluate only the sole current clean-slate contract. Historical public records remain interpretable through offline audit tooling, ensuring forensic traceability without embedding dangerous fallback or backward-compatibility logic within the active shipping path.

Multi-Repository Source-Control Discipline

The TinyRustLM ecosystem encompasses multiple distinct components—core inference engines, WebAssembly wrappers, native .NET bindings, documentation schemas, and public site repositories. A rigorous, synchronized source-control discipline is enforced across all interconnected repositories to prevent state divergence. The automated deployment runner enforces a strict git status \--porcelain check upon bootstrapping the workspace. If any untracked, modified, or staged files exist in the worktree, the build immediately aborts. This mechanism prevents unrelated user changes, localized debugging artifacts, or stray configuration files from contaminating the release context. All commits must be highly focused; a commit targeting core tensor mathematics must never be bundled with an update to the marketing site's CSS unless they are intrinsically coupled to the same atomic release gate. Branch protection is enforced cryptographically across all repositories. Direct pushes to the deployment branch are prohibited. The pipeline mandates equality between the local build context and the remote origin. Before executing the release commit, the build system performs a git ls-remote validation to guarantee that the local commit being evaluated perfectly matches the HEAD of the protected remote branch. If a deployment fails during live verification, the system executes an automated, explicit rollback commit. This commit reverts the configuration to the last-known-good state, preserving the linear history of the repository. Destructive operations, such as git push \--force or history rewriting, are strictly prohibited. Deploying uncommitted source code is viewed as a critical supply-chain breach and immediately triggers a full quarantine of the affected sites.

Build, Package, and Supply-Chain Matrix

The build architecture must securely orchestrate the compilation of Rust native binaries, WebAssembly modules, C ABI targets, and .NET/NuGet companions.

Rust and Cargo Determinism

The core inference engine relies on Rust. To ensure reproducible builds, the Cargo.lock file must be strictly version-controlled, pinning all dependency hashes. Build runners must execute in a hermetic environment utilizing cargo build \--offline to prevent dynamic resolution vulnerabilities and unverified downloads during compilation18. Furthermore, the cargo-vet and cargo-audit toolchains are executed sequentially to ensure dependency security and generate a comprehensive software bill of materials (SBOM) prior to binary generation18.

.NET, NuGet, and Native Interoperability

The .NET companion package provides the wrapper for the native C ABI. To prevent runtime PlatformNotSupportedException errors, native assets must be packaged dynamically according to the .NET Runtime Identifier (RID) graph19. The .nupkg archive structure is strictly governed. Native dependencies must never be placed in the standard lib/ directory, as the NuGet packaging system treats files in this directory as managed assemblies, which leads to runtime failures20. Instead, native binaries are injected into the following paths:

• runtimes/win-x64/native/tinyrustlm.dll
• runtimes/linux-x64/native/libtinyrustlm.so
• runtimes/linux-arm64/native/libtinyrustlm.so

By adhering to this structure, the .NET SDK automatically selects the most compatible native asset based on the host RID and flattens it into the output directory during the build and publish phases20. This eliminates the need for volatile, custom MSBuild targets. Supply-chain transparency for the NuGet ecosystem requires the implementation of SourceLink. The project's .csproj files must explicitly define \<PublishRepositoryUrl\>true\</PublishRepositoryUrl\> and \<EmbedUntrackedSources\>true\</EmbedUntrackedSources\>24. The symbol package format must be configured to generate .snupkg files or embed the debug types directly, enabling precise forensic debugging of the compiled managed code against the exact immutable Git commit24.

WebAssembly and Malware Boundaries

WebAssembly compilation is executed utilizing aggressive optimization profiles to minimize the binary footprint for browser delivery. Source maps and portable symbols must be generated synchronously but deployed to a restricted, access-controlled directory. This prevents intellectual property leakage while allowing error telemetry systems to resolve minified stack traces. At the boundary between compilation and packaging, an automated malware scanning protocol is enforced. Tools such as gitleaks interrogate the repository for inadvertently committed secrets. Subsequently, the packed .nupkg, .tgz, and raw WASM assets are submitted to endpoint detection signatures and antivirus engines.

Test Gates by Component, Platform, and Evidence Class

To assert functional accuracy and security, a multi-dimensional test matrix must be satisfied. The testing philosophy draws a strict boundary between binary inspection, software emulation, and real-hardware execution. Table 2 defines the critical test gates required for release authorization.

Testing malformed artifacts is mandatory. Fuzzing the WebAssembly interface and native C ABI with corrupted tensor dimensions or garbage byte arrays must result in graceful, predictable error handling, not catastrophic process termination or undefined behavior. Any test failure immediately generates an immutable receipt with a failure predicate, halting the deployment DAG and triggering an invalidation edge back to the Source Review phase.

Atomic Site Deployment and Service-Worker Release

The public site serves as the critical execution environment for the WASM-based browser-local chat. The deployment mechanics must guarantee absolute atomicity to prevent race conditions where a client successfully downloads a new index.html structure but executes a stale Service Worker or an outdated WebAssembly binary.

Immutable Hashed Assets and Service Worker Coordination

All static assets, including JavaScript bundles, CSS stylesheets, and the compiled WebAssembly binary, must be emitted with cryptographic content hashes seamlessly integrated into their filenames (e.g., tinyrustlm.\[contenthash\].wasm). The main index.html file acts as the primary dependency graph, directly referencing these hashed assets. Subresource Integrity (SRI) attributes (integrity="sha384-...") are injected into all executable tags to defend against CDN compromise. The Service Worker (sw.js) coordinates the local cache environment. To ensure atomic updates, both index.html and sw.js must be explicitly excluded from the Service Worker's internal cache directives30. Furthermore, the HTTP response headers originating from the CDN for these specific files must mandate Cache-Control: no-cache, no-store, must-revalidate. When a deployment is executed, the browser fetches the un-cached sw.js, detects a byte-level differential, installs the new worker, and immediately invokes clients.claim(). This forces the execution environment to seamlessly transition to the new hashed assets while aggressively purging obsolete runtime paths.

Cross-Origin Isolation and CSP Headers

Multi-threaded WebAssembly execution relies fundamentally on the SharedArrayBuffer API to manage concurrent tensor math. However, modern browser security models restrict the instantiation of SharedArrayBuffer to cross-origin isolated environments to mitigate speculative execution vulnerabilities such as Spectre and Meltdown32. To unlock the WASM threads, the deployment infrastructure must enforce the following HTTP headers on the main document response:

\[cite: 32, 33, 35\]

\[cite: 32, 33, 35\]

• Cross-Origin-Embedder-Policy: require-corp
• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Resource-Policy: same-origin (for all subresources)33

In hosting environments where the injection of arbitrary HTTP response headers is restricted, a Service Worker intercept pattern (e.g., utilizing libraries similar to coi-serviceworker) must be implemented to synthetically attach the COOP and COEP headers to incoming network responses, bootstrapping the browser into an isolated state upon reload36. Additionally, a strict Content Security Policy (CSP) must be deployed:Content-Security-Policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; worker-src 'self'; connect-src 'self' \<authorized-p2p-nodes\>; This policy ensures the model cannot exfiltrate context data, restricting P2P or conversion acquisition pathways strictly to authorized endpoints.

Edge Invalidation Logistics

The deployment strategy must account for the physical realities of the Content Delivery Network (CDN). Considering the current location in Cicero, Illinois, United States, the deployment runner must explicitly trigger edge invalidation protocols (/\*) across the North American routing nodes and await programmatic confirmation of cache clearance before initiating the live readback phase, ensuring that stale-client behavior is mitigated.

Consistent Publication-Log Specification

A transparent, immutable publication log must be exposed by every affected site, establishing public proof of the deployment graph. No site, documentation, or log may imply unproven model capabilities or network reachability. The machine-readable log must reside at /.well-known/release-log.json and strictly conform to the following JSON schema:

JSON { "siteIdentity": "chat.tinyrustlm.dev", "publishId": "\<uuid\>", "technicalVersion": "1.0.0-prelaunch", "sourceCommit": "\<git-commit-hash\>", "releaseDate": "2026-08-25T11:28:45Z", "changedComponents": \[ "wasm-inference-engine", "service-worker", "ui-components" \], "migrationsExplicitlyAbsent": true, "testEvidenceLinks": \[ "https://github.com/organization/tinyrustlm/actions/runs/\<id\>/attestations" \], "knownLimitations": \[ "Campaign counters remain 0/20 qualified models.", "MemoryEndpoints is unauthorized and disabled." \], "lastVerifiedHttpsReadback": "2026-08-25T11:29:10Z", "rollbackReference": null }

The human-readable changelog must dynamically parse this JSON and render it clearly within the user interface. It must explicitly articulate the technical version, display the release date with explicit time zone annotations, and provide direct hyperlinks to the SLSA provenance receipts and in-toto layout signatures.

Documentation and Marketing Drift Controls

Documentation governance is treated with the exact same rigor as application source code. Architecture references, user instructions, API/model-format specifications, operator runbooks, security claims, marketing pages, and accessibility guidance must reside within the same source repository as the software they describe. To enforce absolute coherence, documentation must be committed and changed in the exact same atomic release as the behavioral modification. Automated drift checks evaluate the Abstract Syntax Tree (AST) of the Markdown documentation against the codebase. For example, if a native C-ABI struct parameter is modified in the Rust source, a structural AST parser ensures the corresponding API reference in the documentation has been symmetrically updated. If the documentation lags behind the behavior, the build is flagged as terminal-failure. Contradictory documentation—such as marketing copy claiming "MemoryEndpoints are active" while the source code lacks authorization—is identified via static analysis regex assertions and halted immediately.

Honest Claim Taxonomy and Progress Dashboard

The project necessitates strict adherence to an honest claim taxonomy to maintain public trust and technical integrity. Table 3 details the allowed and prohibited vernacular regarding the state of the product.

A progress dashboard embedded in the repository README and public site must dynamically query the release-log.json and strict zero-state counters, providing unvarnished transparency into the exact verification state of the product.

HTTPS Readback, Rollback, and Incident Procedure

Deployment verification extends beyond the act of pushing files to a CDN; it requires absolute, real-world proof that the deployed bytes perfectly match the release commit from an external vantage point. Immediately following a CDN upload, a geographically isolated verification runner initiates a live HTTPS readback sequence.

1. DNS/TLS Verification: Asserts that the domain resolves correctly and the TLS certificate is valid, strictly matching pinned authorities.

2. Asset Hashing: Downloads index.html, parses the DOM, extracts the WASM and Service Worker URLs, fetches them, and computes their SHA-256 hashes. These hashes are strictly compared against the SLSA provenance receipts generated during the Package/Site Release phase.

3. Header Verification: Validates the presence of Cross-Origin-Embedder-Policy: require-corp, Cross-Origin-Opener-Policy: same-origin, and CSP directives in the live HTTP response32.

4. Critical User Flow: Executes a headless Playwright script against the live site, validating the Service Worker installation state, capturing the absence of unexpected network requests (zero prompt telemetry), and successfully completing a two-turn local chat execution.

5. Log Equality: Verifies that the deployed /.well-known/release-log.json perfectly matches the schema generated during the release commit.

If the HTTPS readback fails any check, the deployment is marked as severely degraded, triggering an automated incident procedure. An automated rollback authorization is generated, identifying the last-known-good release commit. The CI pipeline executes a strict rollback commit, pushing historical asset hashes back to the CDN. CDN invalidation paths are executed, and a post-rollback readback is enforced to assert that the Service Worker correctly purged the broken cache and restored the last-known-good configuration.

First-Model Acceptance Checklist and Prioritized Runbook

The vertical slice of the first real model deployment requires a methodical, prioritized runbook. The campaign counters (20 models, 50 rounds) remain unequivocally incomplete even after this singular one-model vertical slice succeeds. Objective Final Checklist:

• \[ \] 1\. Terminal failure of /10 operation acknowledged and superseded by a clean-slate contract correction.
• \[ \] 2\. git status \--porcelain is perfectly clean across all interconnected repositories.
• \[ \] 3\. Cryptographic signatures validated for all commits merged into the target branch.
• \[ \] 4\. Immutable acquisition of Qwen3-0.6B weights verified against upstream cryptographic hashes.
• \[ \] 5\. SLSA 1.0 provenance generated for Rust native, .nupkg, and WASM binaries5.
• \[ \] 6\. CycloneDX 1.6 Machine Learning BOM generated defining exactly 24 layers, 14 Q heads, and 2 KV heads1.
• \[ \] 7\. .nupkg structured with runtimes/win-x64/native/, runtimes/linux-x64/native/, and runtimes/linux-arm64/native/20.
• \[ \] 8\. SourceLink enabled with PublishRepositoryUrl=true and embedded debug symbols24.
• \[ \] 9\. Execution tests passed on physical linux-arm64 hardware.
• \[ \] 10\. axe-core accessibility checks passed with zero severe/critical violations via Playwright integration27.
• \[ \] 11\. Atomic site deployment executed; index.html configured for Cache-Control: no-cache cache-busting30.
• \[ \] 12\. COOP/COEP HTTP headers verified to enable isolated SharedArrayBuffer execution32.
• \[ \] 13\. Documentation AST drift tests passed.
• \[ \] 14\. Publication log (release-log.json) updated, committed, and externally accessible.
• \[ \] 15\. Live HTTPS readback confirms hashes, security headers, and functional Service Worker chat execution.

Remaining Risks and External Blockers:

• CDN Propagation Lag: Edge nodes in Cicero, Illinois, may experience asynchronous invalidation delays, causing transient cache misses during the readback window.
• WASM Memory Limits: Browsers impose strict upper limits on contiguous WASM memory allocations. Extensive multi-turn contexts may trigger out-of-bounds constraints, requiring robust tensor paging mechanisms.
• Third-Party P2P Interruption: Unreliable external WebRTC signaling servers could artificially fail the P2P lane proofs despite local application health.

Unknowns Requiring Local or Authorized Production Access

Several elements of this architecture cannot be fully specified without elevated authorization or direct access to production environments. The following unknowns must be resolved by authorized personnel prior to the initiation of the runbook:

1. Cryptographic Root of Trust: The specific Key Management Service (KMS) or hardware security module holding the private keys for the in-toto layout signatures and Sigstore identities.

2. Deployment Service Accounts: The exact OAuth tokens or IAM roles required to authenticate pushes to the CDN edge nodes and the NuGet galleries.

3. DNS Zone Controls: The administrative credentials required to update or verify DNS records and provision TLS certificates for the primary HTTPS readback URL.

4. Malware Scanning Baselines: The specific vendor signatures and heuristic configurations required to validate the .nupkg and WASM binaries in the dual-scan boundary prior to release.

Annotated Primary-Source Bibliography

1. in-toto-golang: Go implementation of the in-toto framework, defining SLSA provenance statement formats.40

2. Cleanstart Image Provenance: Details SLSA Build Provenance specification, attestations, and cryptographic verifiability of origin.41

3. GitLab SLSA 1.0 Support: Details architectural decisions regarding control plane generation for SLSA Level 3 compliance.9

4. SLSA End-to-End With AMPEL: Practical implementation guide using VSA receipts to capture step integrity.10

5. CycloneDX 1.6 vs SPDX 3.0: OWASP emphasis on application security, vulnerability tracking, and AI components.13

6. Securing Rust Dependencies: Guide on utilizing Cargo.lock, cargo-audit, and cargo-vet for offline build security.18

7. MDN Web Docs \- Cross-Origin-Embedder-Policy (COEP): Defines the requirement of COEP (require-corp) to enable SharedArrayBuffer for WebAssembly threads.32

8. web.dev \- Make your website cross-origin isolated: Google guide on deploying COOP and COEP to mitigate Spectre vulnerabilities.34

9. Publisher Collective \- COOP, COEP, CORP, and CORS: Explains HTTP-header based mechanisms to protect cross-origin resources.33

10. Cinevva \- COOP/COEP/SharedArrayBuffer Tutorial: Practical debugging checklist for WASM threads and subresource opt-in policies.35

11. Tomayac \- Setting COOP/COEP on Static Hosting: Demonstrates utilizing Service Workers (coi-serviceworker) to synthetically inject headers.36

12. StackOverflow \- SharedArrayBuffer on GitHub Pages: Solutions for Service Worker intercept patterns for static sites.37

13. Wasmer \- COOP & COEP Headers: SDK guide for patching headers in web-based WASM environments.38

14. StackOverflow \- Service Worker Cache-Busting: Best practices for explicitly serving index.html and sw.js with HTTP caching disabled.30

15. Preact-CLI \- Service Worker exclusions: Documentation on excluding index.html from the service worker cache to prevent atomic deployment failure.31

16. in-toto and SLSA: Explains the in-toto Attestation Framework's lightweight Statement and context-specific schemas.4

17. in-toto Statement Specification v1: Defines the JSON object fields, including \_type, subject, and predicateType.8

18. SLSA Provenance v1.0 Specification: Defines the buildDefinition and runDetails JSON structures for non-falsifiable provenance.5

19. Trustification \- in-toto Attestations: Details DSSE Envelopes and payload base64 encoding.7

20. Medium \- SLSA Provenance: Deep dive into the metadata components of SLSA Level 1 through Level 3\.11

21. ALOHA \- AIBOM Generator: Tool for generating CycloneDX 1.6 Machine Learning Model Cards from Hugging Face data.14

22. Hugging Face \- Qwen2.5-0.5B Model Card: Architectural specifications defining 24 layers, 14 Q heads, 2 KV heads, and a 151,936 token vocabulary.2

23. APXML \- Qwen2.5-0.5B Specs: Details Rotary Position Embedding (RoPE), SwiGLU, and Grouped-Query Attention (GQA).1

24. Qwen2.5 Technical Report (Arxiv): Outlines the open-weight configurations, tokenizer expansions, and baseline metrics.3

25. Deque Systems \- CI/CD Accessibility: Integrating axe-core configurations into automated deployment pipelines.42

26. Playwright Accessibility Testing: Examples utilizing @axe-core/playwright to catch WCAG violations on PRs.29

27. Legit Security \- Software Attestations: Breakdown of the DSSE Envelope layout, Payload, and Signatures.6

28. CycloneDX bom-1.6.schema.json: Official GitHub repository defining the JSON schema for machine learning models.16

29. CycloneDX AI Models Use Case: Example XML/JSON showcasing model lineage and training dataset transparency.39

30. Microsoft Learn \- .NET RID Catalog: Defines Runtime Identifiers (win-x64, linux-x64, linux-arm64) used by NuGet packages for native dependencies.19

31. Microsoft Learn \- Native files in .NET packages: Explains that NuGet selects runtime assets from runtimes/{rid}/native/ to prevent packages.config failures.20

32. StackOverflow \- Native files in NuGet: Practical solutions proving runtimes\\win-x64\\native allows seamless DllImport without relative paths.21

33. Nethereum \- Native Library Packaging: Demonstrates local NuGet package structure for cross-platform native distribution.22

34. Christian Findlay \- SourceLink & Azure Pipelines: Defines .csproj configurations for PublishRepositoryUrl and embedded DebugType.24

35. Kaylumah \- NuGet Metadata via MSBuild: XML examples for embedding SourceLink references and untracked sources into .nupkg.25

Works cited

1. Qwen2.5-0.5B: Specifications and GPU VRAM Requirements, https://apxml.com/models/qwen2-5-0-5b

2. Qwen/Qwen2.5-0.5B \- Hugging Face, https://huggingface.co/Qwen/Qwen2.5-0.5B

3. Qwen2.5 Technical Report \- arXiv, https://arxiv.org/html/2412.15115v2

4. in-toto and SLSA, https://slsa.dev/blog/2023/05/in-toto-and-slsa

5. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance

6. SLSA Provenance Blog Series, Part 1: What Is Software Attestation, https://www.legitsecurity.com/blog/slsa-provenance-blog-series-part-1-what-is-software-attestation

7. in-toto attestations \- Trustification, https://trustification.io/blog/2023/03/13/in-toto-attestations/

8. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md

9. Architectural Decision: Where do we generate SLSA provenance?, https://gitlab.com/gitlab-org/gitlab/-/issues/537049

10. SLSA End-to-End With AMPEL & Friends, https://slsa.dev/blog/2025/10/slsa-e2e-with-ampel

11. SLSA, it's all about provenance attestation | by Rémi Rey \- Medium, https://medium.com/@rrey94/slsa-its-all-about-provenance-attestation-09a83b7b9de7

12. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance

13. CycloneDX vs SPDX 2026: Which SBOM Format Wins \- Safeguard, https://safeguard.sh/resources/blog/cyclonedx-vs-spdx-which-format-for-your-program

14. MSR4SBOM/ALOHA \- GitHub, https://github.com/MSR4SBOM/ALOHA

15. specification/schema/bom-1.5.schema.json at master \- GitHub, https://github.com/CycloneDX/specification/blob/master/schema/bom-1.5.schema.json

16. specification/schema/bom-1.6.schema.json at master · CycloneDX, https://github.com/CycloneDX/specification/blob/master/schema/bom-1.6.schema.json

17. Leading SBOM Standard CycloneDX Now Incorporates Machine, https://cloudwars.com/cybersecurity/leading-sbom-standard-cyclonedx-now-incorporates-machine-learning/

18. Rust Cargo Dependency Security Guide \- Safeguard, https://safeguard.sh/resources/blog/rust-cargo-dependency-security-guide

19. NET Runtime Identifier (RID) catalog \- Microsoft Learn, https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

20. Including native libraries in .NET packages \- NuGet \- Microsoft Learn, https://learn.microsoft.com/en-us/nuget/create-packages/native-files-in-net-packages

21. Add native files from NuGet package to .NET application output, https://stackoverflow.com/questions/78856188/add-native-files-from-nuget-package-to-net-application-output-directory

22. Nethereum.Signer.Bls.Herumi 5.8.0 \- NuGet, https://www.nuget.org/packages/Nethereum.Signer.Bls.Herumi/5.8.0

23. MaxRev.Gdal.LinuxRuntime.Minimal.x64 3.13.1.534 \- NuGet, https://www.nuget.org/packages/MaxRev.Gdal.LinuxRuntime.Minimal.x64

24. Publish Source Link NuGet Packages with Azure Pipelines, https://www.christianfindlay.com/blog/source-link-nuget-azure-pipelines

25. Set NuGet metadata via MSBuild \- Kaylumah, https://kaylumah.nl/2021/03/27/set-nuget-metadata-via-msbuild.html

26. Create end to end documentation for Sourcelink with Azure Devops, https://github.com/dotnet/sourcelink/issues/943

27. Automating Accessibility Testing in Your CI/CD Pipelines with Axe, https://blog.magicpod.com/automating-accessibility-testing-in-your-ci/cd-pipelines-with-axe

28. Playwright Accessibility Testing: Fast CI Automation Guide \- TestDino, https://testdino.com/blog/playwright-accessibility

29. Accessibility testing \- Playwright, https://playwright.dev/docs/accessibility-testing

30. Problems cache busting serviceworker index.html file \- Stack Overflow, https://stackoverflow.com/questions/43329942/problems-cache-busting-serviceworker-index-html-file

31. index.html should be excluded from service worker cache · Issue \#474, https://github.com/preactjs/preact-cli/issues/474

32. Cross-Origin-Embedder-Policy (COEP) header \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Embedder-Policy

33. A Simple Guide to COOP, COEP, CORP, and CORS, https://www.publisher-collective.com/blog/a-simple-guide-to-coop-coep-corp-and-cors

34. Make your website "cross-origin isolated" using COOP and COEP, https://web.dev/articles/coop-coep

35. Enable Wasm threads (SharedArrayBuffer) with COOP/COEP, https://app.cinevva.com/tutorials/coop-coep-sharedarraybuffer

36. Setting the COOP and COEP headers on static hosting like GitHub, https://blog.tomayac.com/2025/03/08/setting-coop-coep-headers-on-static-hosting-like-github-pages/

37. Is there any way to use SharedArrayBuffer on GitHub Pages?, https://stackoverflow.com/questions/68609682/is-there-any-way-to-use-sharedarraybuffer-on-github-pages

38. Patching COOP & COEP headers for GitHub Pages Deployment, https://docs.wasmer.io/sdk/wasmer-js/how-to/coop-coep-headers/

39. Inventory Management Use Case: AI Models and Model Cards, https://cyclonedx.org/use-cases/ai-models-and-model-cards/

40. in\_toto \- Go Packages, https://pkg.go.dev/github.com/in-toto/in-toto-golang/in\_toto

41. Understanding Image Provenance for Containers \- CleanStart, https://www.cleanstart.com/blogs/understanding-image-provenance

42. CI/CD integration \- Deque Systems, https://www.deque.com/accessible-development/ci-cd/