AELITIUM EVIDENCE LAYER / v0.4.0

01 / Evidence for recorded AI interactions

WHEN AI RUNS,
CAN YOU CHECK
THE RECORD LATER?

AELITIUM turns recorded AI interactions into evidence you can check later. Verification works offline, under explicit verification and comparison rules.

Explore an evidence example Install AELITIUM
pip install aelitium

Tell us your use case

Review a recorded LLM run

Prepared example · AELITIUM v0.4.0

Your platform team is reviewing a saved LLM run. Inspect its request and response, then see what happens when a copy is edited.

Synthetic example. Recorded content is in English. Precomputed release results; no verifier runs in this browser. Provenance ↗

Example data not connected

01 Recorded interaction

Recorded request, response and context. Select a field.

02 Canonical evidence

ai_canonical.json · UTF-8

Select a recorded field to inspect its serialized bytes.

How this evidence is built

This matrix shows the complete canonical payload of record-a, excluding the final file newline. Highlighted ranges are exact UTF-8 offsets of serialized top-level values, not digest bytes.

Request selects /prompt, a JSON string containing recorded messages. No additional parameters were supplied in this example; that selection has no byte range.

Read the source object
03 Derived evidence

Hashes derived from defined recorded inputs.

What do these hashes cover?
ai_hash_sha256
Complete canonical payload; the payload integrity reference in ai_manifest.json.
request_hash
Selected recorded model and messages.
response_hash
Selected recorded response content and model.
invocation_identity_hash
Versioned format, surface, mode and selected request fields. This is not complete real-world invocation identity.
OPEN SOURCE / APACHE-2.0 / v0.4.0 RECORDED EVIDENCE / EXPLICIT ASSURANCE / EXPLICIT BOUNDARIES

02 / Checkable records

RECORDS ARE USEFUL.
CHECKABLE RECORDS ARE BETTER.

AELITIUM adds defined evidence checks to AI interaction records you retain.

Try a simple change

What happens if a retained value no longer matches?

Change the recorded response in this prepared example to see the recorded check result.

Stored evidence

Recorded response

The report identifies three operational risks.

Expected payload hash

—

Inspected payload

The report identifies three operational risks.

Recomputed payload hash

—

Payload integrity

Example data not connected

This result does not establish when, why or by whom a record changed. The expected manifest and stored hashes are held fixed.

03 / Assurance

DIFFERENT QUESTIONS.
DIFFERENT STATES.

AELITIUM reports separate properties instead of collapsing everything into a single authenticity claim.

Learn about the assurance model

Example data not connected

Evidence check: example

01 Payload integrity —
payload_integrity
02 Binding field consistency —
binding_field_consistency
03 Invocation identity consistency —
invocation_identity_consistency
04 Invocation binding consistency —
invocation_binding_consistency
05 Signature validity —
signature_validity
06 Trusted signer identity —
trusted_signer_identity
07 Freshness —
freshness
08 Authorization —
authorization
About these states
VALID
The defined check succeeded.
INVALID
The evaluated evidence is inconsistent with the defined check.
ABSENT
The relevant evidence is not present.
UNESTABLISHED
The available inputs do not establish the property.
NOT_EVALUATED
No evaluation of that property was performed.

04 / Compare

NOT EVERY DIFFERENCE SHOULD BECOME A CONCLUSION.

Compare validated records under an explicit basis. Sometimes refusing to compare is the more informative result.

Synthetic examples. Precomputed release results; no verifier runs in this browser.

A. Same selected comparison identity / different response

Example data not connected

B. Different selected comparison identity

Example data not connected
Explore two more prepared scenarios

Selected example

Example data not connected

CHANGED describes recorded evidence; it does not establish model drift, regression, provider fault or causation.

Learn more about comparison

05 / Verify offline

TAKE THE EVIDENCE WITH YOU.

Once the evidence bundle is available, verification can run offline.

  1. 01

    AI APPLICATION / PRODUCTION

    A supported capture path records interaction data.

  2. 02

    CAPTURED EVIDENCE (via AELITIUM)

    The captured material is stored in an evidence bundle.

    ai_canonical.json ai_manifest.json
  3. 03

    TRANSFER

    Copy the bundle to a different environment.

  4. 04

    OFFLINE REVIEW

    Check the available evidence offline.

aelitium verify-bundle ./bundle

No production access is required for this verification step once the bundle is available. The bundle carries the recorded evidence and supporting data used by AELITIUM’s verification and comparison contracts. Additional trust/policy inputs may be supplied locally; the bundle is not itself a trusted external trust store.

Learn more about offline verification

06 / Who uses this?

BUILT FOR THE PEOPLE WHO NEED THE EVIDENCE.

AELITIUM complements observability. It adds defined checks to retained evidence; it does not replace logging or tracing infrastructure.

01

BUILD AI

Keep checkable evidence from recorded AI interactions in your applications and workflows.

Developers · AI / Platform Engineering · Product & Infrastructure.

02

AUDIT AI

Review retained technical evidence offline once the bundle is available, without production access for the verification step.

Governance · Internal audit · Security · Risk teams.

03

INVESTIGATE

Inspect what was recorded after an incident or unexpected result. Compare validated records and see exactly which evidence relationship AELITIUM reports.

Incident response · Technical investigation · Quality & evaluation · Customer assurance.

07 / Boundaries

EVIDENCE HAS A BOUNDARY.
WE MAKE IT VISIBLE.

AELITIUM checks the recorded evidence. It does not establish that the AI’s answer is true or that every interaction was captured.

What AELITIUM can check

Consistency checks on the supplied evidence

  • Payload integrity
  • Binding field consistency
  • Invocation identity consistency
  • Invocation binding consistency

Absent evidence and unevaluated properties are reported separately.

Additional checks when the required evidence or policy inputs are supplied

Signature validity
When signature evidence and verification material are present.
Trusted signer identity
When a valid signature’s key matches an explicitly supplied external trust store.
Declared-time freshness
With an explicit maximum age and UTC reference time. Checks the declared canonical timestamp, not historical time.
What it does not establish

By itself, evidence verification does not establish:

  • Provider execution.
  • Response causation.
  • Capture completeness.
  • Output truth, correctness or safety.
  • Complete real-world invocation identity.
  • Historical occurrence.
  • Trusted historical time.
  • Authorization.
  • Legal compliance.

In v0.4.0, authorization is always NOT_EVALUATED.

EVIDENCE SHOULD SUPPORT A CONCLUSION.
IT SHOULD NOT SILENTLY BECOME A STRONGER ONE.

08 / Current release

AELITIUM
v0.4.0

OPEN SOURCE / APACHE-2.0

CAPTURE

OpenAI · Anthropic · LiteLLM.
Supported non-streaming capture paths.

VERIFY

8 separate assurance dimensions.
Offline bundle verification.

COMPARE

Explicit mode / basis / reason.

UNCHANGED
CHANGED
NOT_COMPARABLE
INVALID_BUNDLE

SCAN

Supported Python LLM call patterns. This is source-code analysis, not a claim of complete capture or bundle verification.

pip install aelitium

Python 3.10 or newer. Prerequisites & extras

Read the docs View GitHub

09 / Feedback

TELL US WHAT YOU’RE TRYING TO VERIFY.

Real use cases are more useful than assumptions about what teams need. They help shape what AELITIUM validates and builds next.

hello@aelitium.com

“Share your use case” and “Contact” open your email app with the subject prepared. You send the message there; this site does not send it.

Please do not include API keys, production prompts, responses, evidence bundles or confidential data.