kira-project-site/posts/2026-07-evidence-architecture.md at main · thekiraproject/kira-project-site · GitHub

//blob/show" data-turbo-transient="true" />

Skip to content

Search or jump to...

Search code, repositories, users, issues, pull requests...

-->

Search

Clear

Search syntax tips

Provide feedback

--><br>We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

-->

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

//blob/show;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up

Appearance settings

Resetting focus

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

thekiraproject

kira-project-site

Public

Notifications<br>You must be signed in to change notification settings

Fork

Star

FilesExpand file tree

main

/2026-07-evidence-architecture.md

Copy path

Blame<br>More file actions

Blame<br>More file actions

Latest commit

History<br>History<br>History

69 lines (37 loc) · 10.3 KB

main

/2026-07-evidence-architecture.md

Copy path

Top

File metadata and controls<br>Preview

Code

Blame

69 lines (37 loc) · 10.3 KB

Raw<br>Copy raw file<br>Download raw file

OutlineEdit and raw actions

Your AI's logs can be edited. Its evidence shouldn't be.

A tamper-evident, two-layer evidence architecture for a local AI pipeline — and why it records what the system couldn't see, not just what it did. The Kira Project, July 2026. Patent pending (U.S. provisional 64/106,848).

Every AI observability tool answers the same question: what did the model do? Spans, token counts, tool calls, traces. Useful, and not enough — because all of them share three properties that fail exactly when the answer matters most.

They run on mutable stores: a log you can edit after the fact is a log an attacker, an operator, or the model's own error can quietly rewrite. They collapse three different things into one artifact — the raw record of what happened, a human-readable report about it, and an implied compliance claim — so a post-hoc summary gets mistaken for the original, and a "we logged it" gets mistaken for "we proved it." And they record only actions — they are silent on the negative space: the moment the system couldn't see something, chose not to act, or was nudged by untrusted input into acting wrong.

For a system that acts on your behalf, the negative space is where the important failures live. This is how we built the evidence layer to close all three gaps, on a local pipeline, with the receipts.

The setup

Kira is a local compound-AI assistant: one 9-billion-parameter model serving every pipeline role — routing, tool-using reasoning, examination, synthesis — on an Apple M4 Pro with 24 GB of unified memory, no cloud calls. A single query touches many stages, each the same model under a different prompt, several of them reaching out to live tools. When it answers you, a lot happened between your question and its response, and the entire point of an evidence layer is to make all of it inspectable and none of it deniable.

Two layers, cryptographically bound

The design splits evidence into two layers with a hash binding between them, and the split is the whole idea.

Layer 1 is a canonical execution log. As each pipeline stage starts, completes, fails, or times out, an event is appended — stage identity, event type, payload, and two hash fields: a hash of the previous event and a hash of this one. That chaining makes the log tamper-evident: change any past event and every hash after it breaks. Critically, the log is written progressively , as the run happens — so if the pipeline crashes before it produces an answer, the evidence of everything up to the crash is already persisted. The most interesting runs to audit are the ones that failed, and those are exactly the ones a write-at-the-end logger loses.

Layer 2 is a derived reasoning view — the human-readable account, assembled after the run from the canonical events plus telemetry. It carries the stage-by-stage story, an environment attestation, and an evidence-coverage map. And it stores an events-hash computed from the hashes of the source events it was built from . That binding is the load-bearing move: the readable summary can never silently drift from the canonical record, because it carries a cryptographic fingerprint of exactly the events it claims to summarize. The report is provably a function of the record, not a story told alongside it.

This directly answers the "collapse" failure. The canonical log is the record. The reasoning view is the report, bound to the record. And the coverage map reports which evidence fields are present against...