Privacy-first AI event proofs
Correlated lifecycle events, local content fingerprints and publicly verifiable technical integrity proofs
Contents
- Summary
- Problem
- Interaction standard
- Evidence quality
- Tools and oversight
- Architecture
- Hashing
- Continuity
- Merkle and timestamps
- Verification
- Privacy
- AI Act
- Scope of claims
1. Summary
Azalee is a technical audit and integrity layer for AI systems, agents and workflows. The platform is not meant to be a second raw database for conversations. It stores cryptographic fingerprints, safe control metadata, ordering, continuity and anchoring proofs.
A real AI interaction is logged as a related sequence of events. Question and answer stay with the user. The customer system computes input_hash and output_hash locally. Azalee receives these fingerprints plus status, duration, versions and correlating IDs.
2. Problem
A single entry saying "response generated" is often not enough for later technical review. It stays unclear which input was meant, whether the output was delivered or blocked, whether a tool acted, whether an approval existed and whether a provable ordering was in place.
Full raw-data logging, by contrast, duplicates prompts, replies, transcripts, files and customer data and increases privacy, confidentiality and security risks. Azalee therefore separates content and proof.
3. Canonical interaction standard
Every normal input-to-output interaction uses a stable session_id for the conversation or run and a correlation_id for the individual turn.
| Sequence | Event | Expected evidence |
|---|---|---|
| 1 | interaction.started | input_hash, status started |
| 2 | model.response.completed or failed | input_hash, output_hash, duration_ms |
| 3 | output.delivered or blocked | output_hash, optional reason_code |
| 4 | interaction.completed or failed | input/output hash and total duration |
4. Evidence quality
For canonical event types, Azalee checks whether the expected fingerprint fields are present.
| Status | Meaning |
|---|---|
complete | All evidence fields expected for this event type are present. |
partial | At least one expected field is missing; the gap is visibly stated. |
| Legacy | Older or custom event without a quality marker; a valid record, but not a complete canonical interaction proof. |
5. Tools, policy and human oversight
External actions get their own tool event sequence: tool.call.started, completed, failed or blocked.
Human oversight is logged separately with human.approval.requested, granted, rejected and human.override. Policy, risk and change events explain technical state transitions.
6. Architecture
| Layer | Purpose | Result |
|---|---|---|
| Customer runtime | Builds content fingerprints locally and emits real state transitions. | Privacy-first events |
| Ingest | Authenticates, sanitises control metadata and builds the event envelope hash. | Stored event fingerprint |
| Continuity | Orders session, correlation, sequence and previous hash. | Verifiable event sequence |
| Batch | Combines event hashes into a Merkle root. | Publicly verifiable anchor |
| Export and Verify | Produces PDF, CSV, graph, manifest, inclusion path and auditor link. | Technical evidence package |
7. Hashing and canonicalisation
A cryptographic hash is a deterministic fingerprint. The same canonical input produces the same hash; a relevant change produces a different one. Azalee hashes with SHA-256 throughout. Anchors and events written before 2026-07-25 use SHA3-256; because both digests are 32 bytes and the value itself reveals nothing about the function, the algorithm is recorded per row in hash_algo and travels with every proof as hashAlgo. A verifier must use the algorithm the proof declares — recomputing with today's default would report a valid historical proof as tampered. Canonicalisation follows RFC 8785 (JCS).
Independent content verification requires that the original and the local canonicalisation rule are preserved by the user. Azalee cannot reconstruct hidden content from a hash.
8. Continuity and ordering
session_id groups a longer run. correlation_id groups a specific interaction. sequence describes logical order. Optionally every event references the previous hash. Removing, inserting or replacing thereby becomes detectable.
A sequence closes gaps in the middle of a session. It does not close the end: dropping the last events leaves no trace, the chain simply stops earlier. Two additional events cover that. session.sealed is sent exactly once at the end and declares total_events; if the declared and the present count differ, the session is visibly incomplete. system.heartbeat is sent regularly while a session is open and declares at_sequence; if a heartbeat reports a higher sequence than the last event on hand, the end was truncated. Only both together turn silence into an event.
Honest limit: completeness is proven relative to what the system declared. A session that never started exists nowhere and cannot be missed. What is guaranteed is that anything which did start is afterwards either gapless or visibly broken.
9. Merkle roots and timestamps
A Merkle tree condenses many event hashes into one root. An inclusion path shows that a specific fingerprint was part of the batch, without exposing other customer events.
Timestamping binds a batch root or a package hash to a point in time. Only an actually verified qualified trust service provider may be described as a qualified eIDAS timestamp.
10. Verification
A reviewer first evaluates event types, status, ordering, quality, tool/policy/approval context and version fields. Then the event fingerprint, Merkle inclusion, published root and timestamp are checked.
Without the customer original, Azalee confirms the existence and integrity of the stored commitment, but not the hidden content.
A proof travels as a proof bundle (azalee-proof-<event_id>.zip): manifest, leaf hash, Merkle path, root as raw bytes, RFC 3161 token, TSA chain, OpenTimestamps proof, the signed ingest receipt and a VERIFY.md with the commands to recompute everything. Verification uses azalee-verify, an MIT-licensed open-source CLI that makes no network calls at all. A proof that only works on azalee.garden would not be a proof: a third party must reach the same verdict with azalee.garden blocked. Every claim is reported separately, never as one aggregate light; absent evidence shows as unproven and never as a pass.
event.json is usually not in the bundle, because Azalee stores only hashes and control metadata, never content. The holder places their retained original alongside it; it must reproduce the leaf hash. Keep your originals — Azalee proves they are unchanged, it does not keep them for you.
Every root ever published is additionally available in a public, chained feed at /api/roots. Anyone who saves it once will see, on the next fetch, whether an older root was altered or removed. The feed contains roots and times only — no customer identifiers, no names, no volumes.
11. Security and privacy
Permitted plaintext metadata are event type, status, duration, opaque IDs, versions, tool/policy names, reason codes and hash fields. Person-related actors should only be transmitted as opaque references.
Not to be transmitted: raw prompts, replies, transcripts, recordings, files, tool arguments/results, customer records, email addresses, passwords, API keys, tokens or secrets.
12. Position on the EU AI Act
Article 12 of Regulation (EU) 2024/1689 requires automatic event recording for certain high-risk AI systems. Azalee supports technical patterns for recording, traceability, monitoring, risk events, human oversight and later verification.
Azalee does not determine whether a customer system is high-risk, replaces neither risk management nor technical documentation nor human oversight, and constitutes no automatic compliance certification.
13. Scope of claims
- A matching hash shows agreement with a fingerprint, not the truth of the content.
- A timestamp shows the existence of a cryptographic commitment at a point in time, not factual correctness.
- A Merkle proof shows batch inclusion, not the completeness of all actions that ever took place.
- Azalee can only prove events that were actually emitted at the real runtime point.
- Missing historical events must not be invented after the fact.
- A contract badge is not an official certification and no guarantee for every model reply.
- Between ingest and anchoring there is a window in which an event sits unanchored at Azalee. The signed receipt issued at ingest closes it: the customer holds an artifact Azalee can no longer change. Whoever keeps no receipt has no counter-evidence for that window.
client_timeis a claim by the customer system and never evidence; only the Azalee-measuredreceived_atis load-bearing.- Signed checkpoints in C2SP format allow cosigning by independent witnesses. As long as no witness is configured, Azalee is the only signer of its own checkpoints and split-view is not ruled out — a log signing its own checkpoint proves nothing about it. The verifier then reports this check as unproven, not as passed.
Technical foundations
Regulation (EU) 2024/1689. Regulation (EU) No 910/2014. Regulation (EU) 2024/1183. RFC 3161. NIST FIPS 202. RFC 8785. RFC 9162.