Evidence, Provenance, and Supply Chain
Evidence lets an institution explain why work started, who approved it, what made each artifact, and what happened after deployment. Sovereign Source AI links these records into one provenance chain that lasts. Software dependencies, model choices, approvals, and measured outcomes are part of that chain. Each of them can change trust, portability, and the ability of the institution to operate alone.
The provenance chain
The chain has 13 steps, from the source to the outcome:
- source material
- observation
- interpretation
- intent
- requirement
- decision
- work order
- execution
- artifact
- verification
- approval
- deployment
- outcome
Each link answers a different question. Intent provenance explains why the work existed. Execution provenance identifies the actors, models, capabilities, environments, and dependencies that took part. Release provenance links the approved artifact to its verification and deployment. Outcome provenance records what happened after the change went into use.
Keep observations, interpretations, hypotheses, and decisions as separate records. An observation is not automatically evidence for each claim. With separate records, later reviewers can examine how the team got to each conclusion. They do not have to accept one story that someone wrote after the event.
AI-BOM and Inspector
An AI Bill of Materials (AI-BOM) shows the components of an AI application. An AI-BOM can list the models, data, code, tools, and infrastructure that the application uses. The full scope can include:
- models
- providers
- datasets
- weights
- licenses
- libraries
- prompts
- agents
- tools
- APIs
- infrastructure
- jurisdictions
- operators
- policies
- vulnerabilities
- attestations
The proposed Sovereign Source Inspector finds these components and shows how they relate. Its outputs include an AI-BOM, the relationships between dependencies and tools, policy findings, provenance records, and portability risks.
This inventory helps with procurement, governance, security review, and plans to replace components. It shows what the application depends on and where you need more evidence. The inventory does not prove that each dependency is acceptable or that each observed action had approval.
Software supply-chain evidence
The target software chain links intent and source to the build, the tests, the signatures, and the deployment. The full chain has these parts:
- dependency resolution
- reproducible builds
- component inventories
- tests
- policy checks
- provenance attestations
- signatures
- artifacts
- deployment evidence
Each component has one purpose. Dependency records show the inputs. Build provenance describes how the build made the artifact. Verification records support claims that the artifact is acceptable. Signatures link an artifact to the authority that signed it. Deployment evidence shows what went into operation.
A signed artifact also needs evidence. The authorities that sign and release artifacts stay separate from disposable workers. Thus, an execution environment cannot approve its own output.
Licenses are also part of this record. Code licenses, source-available commercial modules, hosted services, support, and trademarks are different things. Each needs its own record. The proposed Sovereign Source License is only a concept in the research. Its name does not make it a recognized open-source license. Clear license boundaries help institutions know what they can inspect, change, distribute, and operate alone.
Outcome provenance
Software genealogy explains where an artifact came from. Outcome provenance follows the artifact further, through release, user experience, and results for the institution.
A release can link to feature exposure, experiments, observed behavior, and measured outcomes. With these links, you can see what happened after deployment and check the evidence for each claimed benefit. These links also keep an observed change separate from an interpretation of its cause.
Reference build
A reference build has these parts:
- a provenance graph
- storage for artifacts and raw evidence
- component inventories
- verification records
- approval records
- a trusted process that signs artifacts
Current operational views give quick access. Historical records keep the context of past decisions.
Evidence goes into the next plan. A new intent can cite past outcomes, failed acceptance conditions, or dependencies that the team found. Thus, the institution keeps the source of each thing that it learned.
From the research
- “No dependency without provenance. No release without evidence.” Manifesto
- Outcome provenance asks, “What happened because we deployed it?” Four-plane architecture notes
- The research proposes Inspector as an initial product. Inspector makes an AI-BOM and shows sovereignty and portability findings. Master summary