Evidence integrity
- Deterministic canonical hashing
- Stored request/response binding checks
- Fail-closed offline bundle verification
AELITIUM / release v0.3.0 / Apache-2.0
Evidence for recorded LLM interactions, checked offline.
An open-source Python library and CLI that produces evidence bundles and checks their internal consistency under a governed schema and canonicalization contract.
Same request hash. Different response hash. One concrete use case within a broader assurance model.
Supported capture
OpenAI / Anthropic / LiteLLM
AELITIUM evidence
canonical payload + manifest
Offline verifier
separate assurance states
Core consistency
- payload_integrity
- VALID
- binding_field_consistency
- VALID
- invocation_identity_consistency
- VALID
- invocation_binding_consistency
- VALID
Optional / policy-dependent
- signature_validity
- ABSENT
- trusted_signer_identity
- UNESTABLISHED
- freshness
- NOT_EVALUATED
- authorization
- NOT_EVALUATED
Illustrative state mix. Optional and policy-dependent dimensions vary with bundle evidence and explicitly supplied verifier inputs.
Engineering proof
v0.3.0
Published release
529
Tests per Python version
3.10 to 3.12
Python CI
OpenAI · Anthropic · LiteLLM
Supported capture integrations
release audit + public-claims guardrail
Public release checks
Current release
What v0.3.0 adds
v0.3.0 adds separate assurance checks beyond the core hash flow.
Invocation assurance
- Versioned invocation identity
- Invocation identity hash consistency
- Stored invocation-identity-to-response binding consistency
Trust & policy
- Ed25519 signature validity
- Explicit external trust-store matching
- Declared-time freshness under explicit policy inputs
Provider coverage
- OpenAI, Anthropic and LiteLLM capture paths
- Static scanning for potential uncaptured Python LLM call sites
Assurance model
Eight dimensions, reported separately.
Each dimension is reported separately. Depending on the dimension, evidence and verifier inputs, a state can be valid, invalid, absent, unestablished or not evaluated.
Core consistency checks
Stored evidence contract
Evaluated independently when their prerequisites are present.
payload_integrity
bundle check
Payload, schema, canonical bytes, manifest and payload-hash consistency.
binding_field_consistency
when present
Consistency among stored v1 request, response and binding hash fields.
invocation_identity_consistency
when present
Stored versioned invocation identity structure and hash consistency.
invocation_binding_consistency
when present
Stored invocation identity hash-to-response hash link consistency.
Optional / policy-dependent
Explicit evidence and inputs
These checks depend on explicit evidence or verifier inputs.
signature_validity
when present
Checks Ed25519 signature validity when signature material is present. The dimension can be ABSENT unless a signature is required.
trusted_signer_identity
external input
Exact key-fingerprint match against an explicitly supplied external trust store; otherwise UNESTABLISHED.
freshness
explicit policy
Freshness uses an explicit maximum age and UTC reference time. No implicit clock is used.
authorization
not evaluated
No authorization decision is implemented; this dimension is always NOT_EVALUATED in v0.3.0.
Where it fits
Practical uses
Four concrete developer workflows supported by v0.3.0.
Compare recorded runs
REQUEST_HASH
SAME
RESPONSE_HASH
DIFFERENT
Compare evidence from two runs and detect when the same recorded request hash is associated with different recorded response hashes. AELITIUM reports the difference without attributing a cause.
Check evidence offline
evidence bundle
aelitium verify-bundle
assurance states
Check the internal consistency of a governed evidence bundle offline before using it in a review, investigation or downstream workflow.
Find potential capture gaps
Python source
aelitium scan
potential call sites
Scan Python source for potential LLM call sites that may not use a supported AELITIUM capture path.
Check coverage in CI
pull request
aelitium scan ./src --ci
CI result
Run the AELITIUM scanner in CI to surface potential Python LLM call sites without supported capture instrumentation.
Concrete use case
Same request hash. Different recorded response hash.
Two bundles can have the same stored request hash and different recorded response hashes. The comparison does not attribute a cause.
A Run A
“Summarise the key risks of deploying LLMs in production in one sentence.”
Key risks include non-deterministic outputs, prompt injection vulnerabilities, hallucinated facts, and the absence of inspectable evidence records.
response_hash: 2f1563cc8c0b7b71…
B Run B
“Summarise the key risks of deploying LLMs in production in one sentence.”
Primary risks are hallucination, data leakage, adversarial prompt injection, and unpredictable behaviour changes following silent model updates.
response_hash: c41d8e3b5f9a2201…
REQUEST_HASH=SAME
RESPONSE_HASH=DIFFERENT
The selected recorded request fields have the same v1 request hash. The recorded response hashes differ. AELITIUM reports the compared fields without attributing a cause.
Interactive demo
Inspect a response-text hash change.
Edit either recorded response. This browser demo compares response-text SHA-256 values; it does not perform bundle verification.
LOCAL BROWSER DEMO
No text leaves the page. The request hash shown below is a fixed demo assumption and is not computed here.
Mechanism
Capture → Hash → Bind → Verify
AELITIUM creates evidence bundles for recorded LLM interactions and checks payload integrity plus stored binding and invocation consistency offline, with separate results for optional signatures, explicit external trust-store matching and declared-time freshness.
Capture
Records selected request and response fields on supported adapter paths.
from aelitium import capture_openai
Hash
Computes deterministic request_hash and response_hash values.
request_hash
response_hash
Bind
Links the stored request and recorded response hashes with binding_hash.
request_hash + response_hash
→ binding_hash
Verify
Checks governed bundle consistency offline and fails closed on invalid evidence.
aelitium verify-bundle ./evidence
binding_hash = SHA256(canonical({request_hash, response_hash}))
Explicit boundary
What AELITIUM verifies and what it does not claim.
Internal consistency is deliberately separate from claims about provider execution or historical non-modification.
What AELITIUM verifies
- Governed payload, canonical representation, manifest and payload-hash consistency.
- Stored v1 request, response and binding-field consistency when binding evidence is present.
- Stored versioned invocation identity and invocation-identity-to-response binding consistency when present.
- Mathematical signature validity when material is present, plus external trust-store matching and declared-time freshness when explicit inputs are supplied.
What AELITIUM does not claim
- Provider authenticity, provider execution or response causation.
- Output truth, safety or semantic correctness.
- Trusted historical time or historical non-modification from the bundle alone.
- Authorization, legal compliance or complete capture of real-world events.
Get started
Inspect one evidence bundle yourself.
Install the Python package, capture a supported call path and check the resulting bundle offline.
$ pip install aelitium · also on PyPI