AI-ENG-AB — Verification Artifacts - Auditability, Reproducibility & Evidence Trails

Doctrinal Foundations: The Evidence Architecture Paradigm

In high-dimensional artificial intelligence systems, production reliability cannot be governed or monitored by traditional application performance monitoring (APM) paradigms.1 While legacy web architectures treat system health as a binary or scalar infrastructure state defined by hardware allocation, network latency, and HTTP status codes, modern multi-agent execution loops and probabilistic large language models (LLMs) break these assumptions.1 A system can return an infrastructure-level successful HTTP 200 payload that contains a complete structural schema failure, an unauthorized tool execution, a cross-tenant data leak, or an ungrounded factual confabulation.1 Conversely, optimal hardware utilization and high throughput can coexist with red behavioral and meaning-level system states.2 This discrepancy establishes the Green Dashboard Fallacy: the diagnostic error of assuming an AI system is operating correctly simply because its underlying servers and APIs are online and available.1

To resolve this visibility deficit, modern systems architectures isolate monitoring concerns across distinct operational layers.1 While strategic telemetry (AI-ENG-Z) functions as the sensor network capturing execution spans 1, and evaluation frameworks (AI-ENG-AA) act as the regression testing pipeline 1, this document defines the architecture of verification artifacts (AI-ENG-AB).1 Verification artifacts are the durable, privacy-governed, and tamper-evident evidence objects required to reconstruct, audit, and reproduce the behavior of probabilistic systems after the fact.3

This architecture is governed by the core doctrine: every consequential AI output or action must leave behind a replayable evidence trail.1 This trail must link the exact prompt template, model weights snapshot, retrieval context, tool payload, policy execution state, human modification, and final output in an unbroken, cryptographically signed chain of custody.1 The fundamental engineering question shifts from “did we record a log entry?” to “can the organization reconstruct the exact decision path from user input to final output or action, including the evidence, versions, state transitions, checks, edits, and approvals that shaped it?”.1 Without this capability, compliance becomes guesswork, debugging degrades into digital archaeology, and the system cannot be safely governed.1

Logs-Traces-Artifacts-Evidence Taxonomy

To establish a clear hierarchy, the following taxonomy contrasts these diagnostic layers across operational, technical, and evidentiary boundaries, proving why generic logs are insufficient for AI auditability:

Legacy logs are fundamentally insufficient for auditing probabilistic architectures.1 Recording that an API returned a response does not show the prompt template that generated it, the vector database coordinates that informed it, the safety policies that validated it, or the user edits that overrode it before execution.1 If an administrator cannot inspect these intermediate states, they cannot defend automated decisions to regulators, resolve disputes, or debug system drift.1

Replay and Reproducibility Typology

GPU Non-Determinism and the Concurrency Hypothesis

Achieving exact, bitwise reproducibility in large language model inference is exceptionally difficult.1 It is a common misconception that setting a fixed random number seed guarantees identical outputs across successive runs.18 In parallel computing environments, GPUs execute matrix multiplications and attention calculations across thousands of concurrent cores.19
Because floating-point addition is non-associative, the order of arithmetic reduction operations alters the least significant bits of the floating-point representations 18:
(a + b) + c is not equal to a + (b + c)
If the execution speed of concurrent GPU threads varies due to minor hardware latency fluctuations, the reduction order changes, introducing run-to-run non-determinism.19
However, technical analysis reveals that this “concurrency and floating-point” hypothesis is not the primary driver of non-determinism in production inference endpoints.18 Individual operations (kernels) inside the model’s forward pass are run-to-run deterministic when executed in isolation.20 The primary cause of output variance is dynamic batching.18 High-performance serving engines (such as vLLM) batch concurrent requests dynamically to maximize hardware utilization.20 Because system load changes constantly, an individual request is batched with varying sets of other user prompts.20
To optimize performance for different batch sizes, the engine dynamically selects different parallelization strategies, such as switching from a standard data-parallel matrix multiplication to a Split-K matmul, or modifying reduction trees in Split-Reduction RMSNorm.19 This batch-dependent kernel selection alters the reduction arithmetic, producing different outputs for the identical prompt.20

To enforce true bit-exact determinism, the model must be executed on an inference stack utilizing batch-invariant kernels.19 This strategy parallelizes operations entirely within individual tensor cores (data-parallel reductions) and avoids Split-K optimizations, preserving the arithmetic order regardless of batch changes.19 This exact reproducibility introduces a measurable performance tradeoff:

In empirical testing over a Qwen3-8B model, executing 1,000 runs under standard vLLM produced 80 unique completions, while forcing batch-invariant operations yielded a single, consistent completion across all runs, accompanied by a 61.5% execution latency penalty.18

The Replay and Reproducibility Typology

Because forcing bit-exact determinism across third-party cloud providers, variable GPU clusters, and dynamic databases is often impractical, systems must design for graded levels of verification 1:

Determinism Decay and Environment Drift

A primary engineering challenge is that reproducibility degrades over time due to external dependencies.1 Even with fixed seeds and invariant kernels, the surrounding execution environment shifts silently, causing “determinism decay”.1
The primary operational drivers of this decay are categorized below:

• Provider Model Updates: Third-party API model weights are modified without changing the public model identifier, causing divergent semantic outputs.1
• Kernel and Library Drift: Minor updates to deep learning frameworks (e.g., PyTorch, CUDA libraries) change internal mathematical approximations, mutating low-level floats.2
• Expired Caches and Rebuilt Indexes: Changes to vector database structures or the expiration of semantic caches alter the exact retrieved context.1
• Time-Dependent Inputs: System prompts injecting dynamic variables (e.g., current_time = “2026-06-11T23:19:00Z”) force models into divergent logical paths.1
• Feature Flag Modifications: Silent deployment updates change the active routing configurations or context limits mid-session.1

To address this, platforms must avoid false promises of bit-exact determinism, defining instead strict “reproducibility envelopes” that capture the complete state of the execution context.1

Verification Artifact Bundle Schema

The central evidence container of this architecture is the Verification Artifact Bundle. It is a structured, schema-validated evidence object that records the minimum sufficient information required to audit, replay, or explain a consequential AI output or action.

The bundle should support JSON or CBOR serialization depending on platform tooling. It may be wrapped in an in-toto / DSSE-style envelope or another signed attestation format when the artifact class requires cryptographic proof. The important architectural rule is not the file format fetish—tempting though that altar is—but the preservation of signed, versioned, replayable evidence.

Risk-Class Tiering Policy

The bundle should adapt to risk class:

High risk does not mean “store everything raw forever.” It means preserve enough evidence to audit and replay the decision while minimizing raw sensitive payloads, enforcing access controls, and recording when data was intentionally not captured.

Reproducibility Envelope Model

Every consequential AI execution should run inside a Reproducibility Envelope. The envelope records the system state needed to recompile, inspect, simulate, or replay the run. The reproducibility unit is not “the model” alone; it is the model route, prompt compiler, retrieval surface, policy bundle, tool contracts, feature flags, runtime configuration, and evidence state.

REPRODUCIBILITY ENVELOPE

+----------------------------------------------------------+
| Prompt Assembly                                          
| template id/version | compiler hash | context policy     
+----------------------------------------------------------+
| Inference Route                                          
| provider route | model ref | tokenizer | decoding config 
+----------------------------------------------------------+
| Retrieval Surface                                        
| corpus version | index hash | embedding model | filters  
+----------------------------------------------------------+
| Tool and Action Surface                                  
| tool schemas | mock mode | credential policy | idempotency
+----------------------------------------------------------+
| Policy and Governance                                    
| policy bundle | approval flow | safety filters | retention
+----------------------------------------------------------+
| Runtime Environment                                      
| container image | dependency lock | feature flags | region 
+----------------------------------------------------------+
| Replay Constraints                                       
| exact | constrained | semantic | counterfactual | forensic
+----------------------------------------------------------+

This envelope does not guarantee bit-exact reproduction in every environment. It defines what must be pinned, captured, or declared unknown so auditors can distinguish exact replay, constrained replay, semantic replay, counterfactual replay, forensic replay, and audit-only verification.30

Specialized Evidence Records

The Prompt Lineage Record

To determine whether behavior changed because of template edits, context assembly, memory inclusion, or dynamic variable injection, the system preserves a Prompt Lineage Record.

Saving only raw templates is insufficient because compiled prompts include dynamic variables, memories, retrieved evidence, tool schemas, policies, and message boundaries. The lineage record proves what was assembled without requiring every observer to see the full prompt text.

The Model and Route Manifest

Model route decisions are critical audit artifacts. A silent downgrade, fallback, cache hit, provider change, or safety-route change can alter quality, cost, latency, and policy behavior.

The Retrieval Evidence Snapshot

GRC verification requires proving the context available before generation. The retrieval snapshot should show what was searched, what was authorized, what was selected, what was omitted, and how citations map to evidence.

This snapshot provides bounded verifiability: it can distinguish retrieval failure, stale-source failure, citation failure, and generation failure when capture coverage, source versioning, and permission metadata are complete.

The Tool Execution Record

A generated statement claiming an action succeeded is not evidence of success. Auditing requires verification of tool authorization, payload integrity, idempotency, execution status, and post-action state.

The Intermediate State Ledger

To trace execution trajectories without exposing hidden reasoning or private chain-of-thought, the system preserves an Intermediate State Ledger. It records state transitions, decisions, validation failures, and observable progress—not the model’s private scratchpad.

The User Edit and Output Diff Record

The final answer displayed or submitted is the last artifact in a chain of transformations. The system should record hashes, diffs, edit metadata, and secure references while avoiding uncontrolled raw output storage.

Output lineage should capture transformation hashes for each stage:

1. output.raw_model_hash
2. output.post_processed_hash
3. output.policy_filtered_hash
4. output.redacted_hash
5. output.citation_injected_hash
6. output.rendered_ui_hash
7. output.human_edited_hash
8. output.final_submitted_hash

Raw text for any stage should be stored only according to capture class and retention policy.

The Policy Check Record

Policy checks must function as executable verification artifacts, not passive annotations. Deterministic rules, classifiers, human approvals, and override paths should be recorded separately so auditors can tell what kind of control actually fired.

Replay Package Model and Execution Safety

To audit, debug, or evaluate a transaction safely, the system compiles a Replay Package. A Replay Package is not merely a folder of logs; it is a controlled reconstruction environment designed to reproduce or simulate behavior without mutating production systems.

A replay package contains:

• Trace Graph: Parent-child spans and timing relationships.
• Verification Bundle: Signed evidence record for the run.
• Reproducibility Envelope: Prompt, model, retrieval, policy, tool, and runtime state.
• Dependency Manifest: Container digests, package locks, runtime versions, and feature flags.
• Tool Mocks: Signed, recorded responses or deterministic simulators.
• Payload Vault References: Secure references to redacted or raw payloads where permitted.
• Policy Bundle: Exact rules, thresholds, and approval requirements.
• Evaluation Rubric: Scoring rules for semantic or counterfactual replay.

REPLAY PACKAGE CONTAINER

+----------------------------------------------------------+
| Replay Orchestrator                                      
|  loads trace graph, bundle, envelope, policy, rubric      
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Network and Credential Controls                          
|  no production credentials                                
|  egress blocked or allowlisted                            
|  production endpoints denied                              
|  secrets replaced with inert references                   
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Mocked / Simulated Dependencies                           
|  recorded LLM outputs                                     
|  signed tool responses                                    
|  retrieval snapshot                                       
|  sandbox database                                         
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Replay Result                                             
|  exact replay, constrained replay, semantic comparison,    
|  counterfactual analysis, or forensic timeline             
+----------------------------------------------------------+

These execution bounds are mapped across six replay modes:

Evidence Chain and Tamper-Evidence Infrastructure

To detect silent modification or deletion of verification artifacts, the platform should implement tamper-evident evidence chains. Each Verification Artifact Bundle is canonicalized, hashed, signed when required, and linked to prior artifacts or workflow checkpoints.

The hash-chain relation can be expressed as:

where H is a collision-resistant hash function, canonical(bundle_i) is a deterministic serialization of the bundle, and h_(i-1) is the previous chain hash. This does not make evidence indestructible or magically true. It makes later alteration detectable when verification is performed.

The platform may use several signing and provenance mechanisms depending on artifact type:

1. Signed Attestation Envelope: Verification bundles, model manifests, tool manifests, and replay packages can be wrapped in DSSE / in-toto-style signed envelopes.
2. Sigstore / Fulcio / Rekor: CI/CD artifacts, container images, model bundles, and build outputs can use keyless signing and transparency logging where appropriate.
3. C2PA Manifests: Images, charts, video, generated media, or datasets may carry embedded or sidecar C2PA manifests. Text-only or binary artifacts may bind to C2PA through sidecar manifests and asset references.
4. Internal WORM / Append-Only Ledger: Regulated systems may store chain checkpoints in WORM object storage or append-only audit databases.
5. External Anchoring: High-assurance systems may periodically anchor evidence-chain checkpoints externally to improve tamper detection.

TAMPER-EVIDENT EVIDENCE CHAIN

+----------------------------------------------------------+
| Artifact Created                                         
|  bundle, replay package, manifest, snapshot, or diff     
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Canonicalize and Hash                                    
|  deterministic serialization                             
|  content hash                                            
|  parent hash                                             
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Sign / Attest When Required                              
|  DSSE / in-toto envelope                                  
|  Sigstore or internal signing                             
|  policy-defined signer identity                           
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Store Evidence                                           
|  content-addressed storage                                
|  retention class                                          
|  access policy                                            
|  redaction status                                         
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Verify Chain                                             
|  validate hashes                                          
|  validate signatures                                      
|  validate timestamps                                      
|  detect missing or altered records                        
+----------------------------------------------------------+

If a historical record is altered, hash-chain verification fails and the system can trigger investigation, containment, and recovery workflows. That is the sober version. The cartoon version where cryptography tackles the attacker through a window is, regrettably, not in scope.

Artifact Privacy, Redaction, and Retention Model

Verification artifacts contain sensitive operational data: proprietary documents, customer records, payment details, credentials, policy decisions, reviewer comments, tool payloads, and source-of-record state. Evidence trails must therefore follow a data-minimization model. Auditability is not permission to build a beautifully indexed breach warehouse.

Redaction should be layered. Regex and NER scans are useful but insufficient alone. The system should combine structured field suppression, secret scanning, policy-aware capture classes, secure payload references, access logging, retention limits, and legal-hold rules.

PRIVACY REDACTION WORKFLOW

+----------------------------------------------------------+
| Artifact Capture Point                                   
|  prompt, retrieval, tool, output, review, policy, state   
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Capture-Class Decision                                   
|  never capture                                             
|  hash only                                                 
|  metadata only                                             
|  redacted snippet                                          
|  reference only                                            
|  restricted full payload                                   
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Redaction and Secret Controls                            
|  structured denylist                                       
|  regex / NER / classifier scan                             
|  source-aware policy                                       
|  credential stripping                                      
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Storage and Access Policy                                
|  content-addressed storage                                 
|  secure payload vault                                      
|  WORM archive when needed                                  
|  access logs and retention                                 
+----------------------------------------------------------+

Metadata can itself be sensitive. Tenant hashes, source IDs, route choices, policy decisions, and timing records can reveal business activity. Access rules should therefore apply to both payloads and metadata.

GRC Audit Query Playbook

To support audits, investigations, dispute resolution, and regulatory inspections, the verification framework should map common audit questions to the artifacts and replay modes required to answer them.

Artifact Lifecycle and Storage Architecture

Verification artifacts must be retained according to risk, regulatory obligations, incident status, tenant contract, and operational debugging value. Storage architecture should therefore be policy-based rather than hardcoded to one fixed age ladder. A low-risk FAQ trace, a failed high-impact payment action, a legal hold, and an active security incident should not share the same retention path just because the calendar was feeling democratic.

EVIDENCE STORAGE LIFECYCLE

+----------------------------------------------------------+
| Artifact Created                                         
|  bundle, trace, snapshot, manifest, diff, replay package  
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Classification                                            
|  risk class                                               
|  capture class                                            
|  retention class                                          
|  legal hold                                               
|  tenant / regulatory policy                               
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Hot Operational Store                                     
|  short debugging window                                   
|  fast lookup                                              
|  redacted or reference-first payloads                     
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Warm Audit Store                                          
|  content-addressed objects                                
|  signed manifests                                         
|  scoped metadata indexes                                  
|  access logging                                           
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Cold Compliance / Legal Hold                              
|  WORM or immutable archive where required                 
|  slower retrieval                                         
|  legal-hold controls                                      
|  deletion review                                          
+--------------------------+-------------------------------+
                           |
                           v
+----------------------------------------------------------+
| Expiry / Deletion / Preservation Decision                 
|  purge                                                    
|  retain under legal hold                                  
|  anonymize / aggregate                                    
|  preserve hash-only evidence                              
+----------------------------------------------------------+

The operational profiles, retrieval expectations, and redundancy targets of these storage tiers are specified below:

Evidence indexes should be searchable through authorized metadata views across keys such as trace_id, artifact_id, workflow_id, prompt_version, model_route, document_id, tool_call_id, approval_request_id, and final_output_hash. Raw tenant_id, session_id, and user identifiers should be avoided in broad indexes; use scoped hashes or access-controlled identity joins.

Storage policy must also support:

Cross-Canon Handoff Map

The Verification Artifacts architecture integrates across the entire AI Systems Engineering Canon because every major subsystem eventually needs evidence for audit, replay, incident response, evaluation, governance, and dispute resolution.

Durable Principles of Verification Artifacts

1. Logs Are Not Evidence Trails
   Logs show that something happened somewhere. Verification artifacts preserve enough structured evidence to reconstruct what happened, why it happened, what data shaped it, and what state resulted.

2. Auditability Requires Scope, Not Hoarding
   More raw data is not automatically better auditability. Better auditability comes from scoped hashes, secure references, source versions, policy decisions, state checks, and signed manifests.

3. Tamper-Evident Does Not Mean True
   A signed artifact proves integrity of the recorded evidence. It does not prove the underlying decision was correct unless the evidence, checks, and policies were also adequate.

4. Replay Has Levels
   Exact replay, constrained replay, semantic replay, counterfactual replay, forensic replay, and audit-only verification serve different purposes. Do not promise bit-exact reproduction when the environment cannot support it.

5. The Reproducibility Unit Is the Whole Runtime
   Model ID alone is not enough. Prompt compiler, retrieval index, policy bundle, route manifest, tool schema, feature flags, cache state, and deployment environment all shape behavior.

6. Hidden Reasoning Is Not an Audit Primitive
   Preserve decisions, state transitions, prompts, evidence, policy checks, tool calls, and outputs. Do not require private chain-of-thought capture to explain system behavior.

7. Tool Claims Require State Evidence
   “The model said it sent the invoice” proves nothing. Tool records must preserve authorization, payload hash, idempotency, execution status, and post-action verification.

8. Sensitive Payloads Need Capture Classes
   Never-capture, hash-only, metadata-only, redacted snippet, reference-only, restricted full payload, and incident-mode capture should be explicit policy states.

9. Evidence Storage Must Follow Risk and Law
   Retention windows should be driven by risk class, contract, regulation, incident state, legal hold, and operational need—not by vibes or one universal timer.

10. Every Artifact Needs Ownership
    Prompt records, route manifests, retrieval snapshots, policy checks, approval records, and replay packages need owners, version history, and access rules.

11. Evidence Must Support Dispute Resolution
    A user correction, reviewer override, citation dispute, model downgrade, or failed action should be traceable through artifacts rather than reconstructed from memory and regret.

12. Verification Infrastructure Is Governance Infrastructure
    If the system cannot prove what happened, it cannot be governed. If it cannot be governed, it should not be trusted with consequential autonomy.

Works cited

1. AI-ENG-AA — Evals Architecture: Ground Truth, Golden Sets & Regression Tests
2. AI-ENG-Z — Strategic Telemetry - Traces, Tokens, Latency & Semantic Drift
3. Recon.AI — Trust Accounting Platform for AI systems, accessed June 11, 2026, https://reconai.net/
4. Content-Addressed Evidence Storage & Preservation … - SEC.gov, accessed June 11, 2026, https://www.sec.gov/files/ctf-written-fcck-pilot-evidence-02-16-2026.pdf
5. [KNOWLEDGE] - AI Engineering - Volume 8. W-Y Resilience, Degraded Modes, and Human Trust
6. Provenance only gets attention after a messy document case : r/AI_Agents - Reddit, accessed June 11, 2026, https://www.reddit.com/r/AI_Agents/comments/1sco94r/provenance_only_gets_attention_after_a_messy/
7. Model Lineage and Reproducibility: Tracking Provenance Across the ML Lifecycle, accessed June 11, 2026, https://agility-at-scale.com/ai/governance/model-lineage-and-reproducibility/

8. Trace concepts - Azure Databricks

   Microsoft Learn, accessed June 11, 2026, https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/tracing/tracing-101

9. OpenInference Specification - GitHub Pages, accessed June 11, 2026, https://arize-ai.github.io/openinference/spec/

10. Trace Concepts

    MLflow AI Platform, accessed June 11, 2026, https://mlflow.org/docs/latest/genai/concepts/trace/

11. Propagation - Python - OpenTelemetry, accessed June 11, 2026, https://opentelemetry.io/docs/languages/python/propagation/
12. What is a C2PA Manifest? Structure, Assertions, and Verification, accessed June 11, 2026, https://c2paviewer.com/articles/what-is-c2pa-manifest
13. In-toto Attestations in Secure Pipelines - Emergent Mind, accessed June 11, 2026, https://www.emergentmind.com/topics/in-toto-attestations
14. Provenance Driven Identity Trust Architecture, accessed June 11, 2026, https://identitymanagementinstitute.org/provenance-driven-identity-trust-architecture/
15. Technology - Ar.io, accessed June 11, 2026, https://ar.io/technology/
16. C2PA Implementation Guidance, accessed June 11, 2026, https://spec.c2pa.org/specifications/specifications/2.4/guidance/Guidance.html
17. Blockchain-enforced data lineage architectures with formal verification workflows, accessed June 11, 2026, https://ijsra.net/sites/default/files/fulltext_pdf/IJSRA-2023-0559.pdf
18. Defeating Nondeterminism in LLM Inference - Simon Willison’s Weblog, accessed June 11, 2026, https://simonwillison.net/2025/Sep/11/defeating-nondeterminism/
19. Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, accessed June 11, 2026, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
20. Defeating Nondeterminism in LLM Inference - OpenAI Developer Community, accessed June 11, 2026, https://community.openai.com/t/defeating-nondeterminism-in-llm-inference/1358623
21. Openinference Semantic Conventions - Arize AX Docs, accessed June 11, 2026, https://arize.com/docs/ax/observe/tracing-concepts/openinference-semantic-conventions
22. Poisoning Attacks in Federated Learning: An Accountability-Oriented Survey with Centralized Learning as Baseline - Preprints.org, accessed June 11, 2026, https://www.preprints.org/manuscript/202605.1674
23. C2PA for Developers: Implementation Guide, accessed June 11, 2026, https://c2pa.ai/for-developers
24. An 84-Format Numeric Catalog with Bit-Exact Conformance Vectors: A Vendor-Neutral Reference for FP8, BF16, MXFP4, and Microscaling Formats - arXiv, accessed June 11, 2026, https://arxiv.org/html/2606.09686v1
25. Fighting Misinformation with Authenticated C2PA Provenance Metadata - IPTC, accessed June 11, 2026, https://iptc.org/std/MediaProvenance/Documents/NAB%20Paper%20-%20Formatted%20Version.pdf
26. envelope.md - in-toto/attestation - GitHub, accessed June 11, 2026, https://github.com/in-toto/attestation/blob/main/spec/v1/envelope.md
27. mlflow.tracing, accessed June 11, 2026, https://mlflow.org/docs/latest/api_reference/python_api/mlflow.tracing.html

28. Attribute Mapping Reference

    MLflow AI Platform, accessed June 11, 2026, https://mlflow.org/docs/latest/genai/tracing/opentelemetry/attribute-mapping/

29. Agent Trace Evaluation with TruLens Scorers in MLflow, accessed June 11, 2026, https://mlflow.org/blog/mlflow-trulens-evaluation/
30. From Attack Simulation to SIEM Rule: Deterministic Detection-as-Code Synthesis with Probe-Level Traceability - arXiv, accessed June 11, 2026, https://arxiv.org/pdf/2606.05252
31. [KNOWLEDGE] - AI Engineering - Volume 7. S-V Failure, Security, and Hostile Environments
32. What do you use for tamper-evident audit logs? Looking for approaches beyond “ship to S3”, accessed June 11, 2026, https://www.reddit.com/r/Observability/comments/1rwm9vh/what_do_you_use_for_tamperevident_audit_logs/
33. QCIVET: A Quantum–Classical Pipeline Integrity Framework with Contract-Based Subtype Verification and Hash-Chained Audit Traces - arXiv, accessed June 11, 2026, https://arxiv.org/html/2605.13109v1
34. Cosign Projects - AI Tinkerers - Bogotá, accessed June 11, 2026, https://bogota.aitinkerers.org/technologies/cosign
35. What Is Sigstore? Keyless Signing for the Software Supply Chain - Sbomify, accessed June 11, 2026, https://sbomify.com/2024/08/12/what-is-sigstore/
36. New SIG proposal: E2E Model Provenance · Issue #40 · ossf/ai-ml-security - GitHub, accessed June 11, 2026, https://github.com/ossf/ai-ml-security/issues/40
37. Docker Image signing and attestation with Cosign - AugmentedMind.de, accessed June 11, 2026, https://www.augmentedmind.de/2025/03/02/docker-image-signing-with-cosign/
38. Guidance for Artificial Intelligence and Machine Learning - C2PA Specifications, accessed June 11, 2026, https://spec.c2pa.org/specifications/specifications/2.4/ai-ml/ai_ml.html
39. A Study on Broker-Assisted Blockchain Trust Chains for Provenance and Integrity Verification of Generative Media Using Watermarking, Semantic Fingerprinting, and C2PA - MDPI, accessed June 11, 2026, https://www.mdpi.com/2076-3417/16/7/3391
40. Evidentia™ T1 — Institutional Evidence Infrastructure, accessed June 11, 2026, https://evidentiat1.com/
41. (PDF) From Policy to Pipeline: A Governance Framework for AI Development and Operations Pipelines - ResearchGate, accessed June 11, 2026, https://www.researchgate.net/publication/399025393_From_Policy_to_Pipeline_A_Governance_Framework_for_AI_Development_and_Operations_Pipelines

Attribution

Part of Stunspot’s Guide to AI Systems — The AI Engineering Systems Canon.

Created by Sam “stunspot” Walker / Collaborative Dynamics.

Repository: https://github.com/Stunspot/stunspots-guide-to-ai-systems
Stunspot: https://stunspot.com
Collaborative Dynamics: https://www.collaborative-dynamics.com
Discord: https://discord.gg/stunspot

Licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Commercial use, resale, paid redistribution, inclusion in commercial training products, or incorporation into paid knowledge-base products requires prior written permission.

← Back to Canon Map