Artifact trust
Hashes, detached signatures, locks, provenance, and runtime verification boundaries.
AxiomCore separates artifact integrity from release provenance. A SHA-256 digest identifies exact bytes. A detached Ed25519 signature, verified with its paired public key, can prove that the digest was signed by the expected boundary.
.axiom bytes ──SHA-256──► digest ──Ed25519 signature
│ │ │
└──── lock hash ────────┘ retained public keyThe signature and public key are proof material associated with an artifact; they are not described as executable content embedded inside the contract. Both values must be present together.
Local and Cloud artifacts
| Artifact path | Expected trust posture |
|---|---|
Local axiom build | Exact-byte hash and lock validation; the artifact may be unsigned for development. |
| Axiom Cloud release | Immutable stored bytes, server-computed digest, Cloud signature, and durable validation evidence. |
| Pulled dependency | Pinned source/version plus retained proof and lock metadata used by the selected client workflow. |
| Acore UI production build | Rejects unsigned local contract dependencies; development mode records every unsigned dependency in the application manifest. |
Unsigned does not mean corrupted. It means provenance has not been established by the signing boundary. Keep unsigned artifacts inside explicitly marked local development workflows.
Verification sequence
Consumers should fail initialization or installation cleanly when any required step fails:
- load the exact artifact bytes;
- compare their SHA-256 digest with the committed lock or manifest;
- when proof is declared, require both Base64 signature and public key;
- verify the Ed25519 signature over the artifact digest; and
- only then expose contract endpoints to the runtime.
axiom contract verify --deps AxiomDeps.toml --lock axiom.ui.lock.jsonDo not catch an integrity failure and silently retry with an unpinned network copy. Surface it as a deployment or dependency error.
What verification does not prove
A valid signature proves byte provenance relative to a key. It does not prove that the backend enforces authorization, that an extracted handler matches its business intent, that a release is free of breaking changes, or that client storage is appropriate for sensitive data. Pair trust verification with semantic diff, security analysis, tests, code review, and environment-specific release gates.
Secret boundary
Private signing material belongs to the Cloud signing service or an explicitly controlled signing process. Applications receive only public verification material. Authentication tokens, database credentials, provider keys, and telemetry DSNs are operational secrets and must not be embedded in a contract to make them convenient for a client.