Provenance
Establish the source
Record where an artifact came from, how it was produced and which dependencies it includes. A version label supplied by the workload is insufficient evidence.
Model integrity
Know which model is running.
Model files, configurations and dependencies can change between development and deployment. We are investigating how to establish provenance, verify approved artifacts and make changes reviewable.
The work
Integrity begins before deployment.
An authentic artifact can still behave unsafely. Provenance, tamper checks and behavioral evaluation answer different questions.
Verification
Compare the approved artifact
Bind deployment to a reviewed model and configuration. Signatures and hashes can establish authenticity and change; they cannot establish freedom from backdoors or adversarial vulnerabilities.
Change
Review what changed
Preserve the relationship between an update, its authorization and the evidence used to evaluate it. Model weights, preprocessing and runtime configuration all affect behavior.
Deployment context
The artifact is part of a running system.
A verified model file does not establish which workload has loaded it or whether the surrounding software is intact. Runtime identity and trustworthy measurements need a defined source and integration.
Model integrity is a development priority. We do not offer a deployed attestation service, universal model scanner or verified support for specific edge hardware.
What comes next
Test the integrity boundary.
Define the model format, runtime and threat before choosing the verification mechanism.
Baseline
Identify the reviewed configuration
Name the artifact, preprocessing, dependencies and intended environment. Document what the available evidence can authenticate.
Evaluation
Exercise unauthorized changes
Use controlled tests to check altered artifacts, mismatched configurations and invalid provenance. Record which changes remain outside coverage.
Operations
Preserve independent recovery
Integrate update and recovery procedures with the system owner. Verification failures need a system-specific response that respects existing operating controls.