Feature request: Trust scores alongside checkpoint context

The Problem

Checkpoints capture amazing context — prompts, transcripts, reasoning, tool calls. This answers "why was this code written?"

But there's a gap: when reviewing checkpointed code, there's no structured way to know "how trustworthy is this code?" — what sources the agent used, whether it was verified, what the confidence level was.

Right now a reviewer sees the transcript and has to mentally assess trust. As agents generate more code at scale, this doesn't scale.

Idea

What if each checkpoint also carried a lightweight trust signal per file?

Something like:

• Trust score (0-1) — based on what sources the agent used
• Verification status — was the output human-reviewed or raw agent output?
• Source tier — SEC filing (high trust) vs. unverified inference (low trust)

This would let reviewers quickly triage: focus review time on low-trust files, fast-track high-trust ones.

One approach: AKF

We've been working on AKF (Agent Knowledge Format) — an open metadata format that embeds exactly this into files. It's ~15 tokens of JSON.

{"v":"1.0","claims":[{"c":"Revenue $4.2B","t":0.98,"src":"SEC 10-Q"}],"agent":"claude","at":"2026-03-27T10:00:00Z"}

It could plug into Checkpoints as:

1. A post-commit hook that stamps files alongside Entire's context capture
2. Additional metadata on the entire/checkpoints/v1 branch
3. An optional flag: entire enable --trust-metadata

pip install akf — MIT licensed, open spec.

But honestly curious if the Entire team has thought about trust signals in a different way. Would love to hear your approach.

Links

• https://akf.dev
• https://github.com/HMAKT99/AKF
• Demo

The issue names no repository files or tests. Start by reviewing how checkpoint context is stored on the entire/checkpoints/v1 branch and how the proposed post-commit hook would interact with capture. Done would require an agreed trust-signal design, metadata location, and opt-in behavior, none of which is specified yet.