Writing · proof surface All writingSummary Is Not The Record

Essay · AI agents · verification

The Summary Is Not The Record

Proof-surface tooling for AI-assisted work: claims, evidence, checks, action state, and honest unverifiable outcomes.

Zain Dana Harper / 2026 / Public review draft

The summary is not the record.

That is the sentence I keep coming back to.

A model can produce a useful answer. An agent can edit files, call tools, read pages, hand work to another agent, or change something outside the local machine. Then, at the end, all of that gets compressed into a few clean paragraphs.

Those paragraphs can be useful.

They should not be the thing we trust.

The gap

I am building Project Telos around that gap: not the model weights, not a grand promise that the system is safe, but the work surface around the agent.

There is a larger private backend behind the work. I am not releasing that machinery. What I am trying to bring into public view are the bounded pieces that should be safe and useful to inspect: verifier components, evidence formats, conformance examples, and review packets.

  • What did it claim?
  • What did it read?
  • What did it change?
  • What checks ran?
  • What evidence still supports the claim?
  • What drifted?
  • What was never verifiable in the first place?

That is the proof-surface problem.

A lot of current AI-safety work is happening at the model level. My question is narrower and less glamorous: after an agent acts, can we open the work?

Not the weights. The work.

The packet

That distinction matters because I do not want to ask anyone to trust the tool because I say so. If a public artifact is useful, it should be useful because another person can reopen it, run the check, find the missing edge, and argue with the result.

For me, the useful packet has three honest outcomes:

  • MATCH: the available evidence supports the claim.
  • DRIFT: the evidence no longer supports the claim.
  • UNVERIFIABLE: the system cannot honestly check the claim.

That last one matters.

Unsupported claims should not sound the same as checked claims. If the system cannot prove something, I want it to say so plainly. Not as an apology. As a useful result.

What it is not

This is not a safety certification.

It is not a compliance claim.

It is not an audit.

It is not an affiliation claim with Anthropic or AE Studio.

It is early infrastructure for review.

The public test

The practical version is modest:

  1. Collect the claims.
  2. Attach the evidence.
  3. Run the checks that can be run.
  4. Preserve route and action state.
  5. Mark MATCH, DRIFT, or UNVERIFIABLE.
  6. Produce a packet another person can inspect.

The goal is not to make the work look clean.

The goal is to make it reopenable.

A small cleanroom example is public here: Crucible Cleanroom Verdict Packet Demo. It is intentionally narrow: one verifier packet, one downloadable bundle, and one visible line between evidence-supported claims and claims the system must refuse to overstate.

What I am looking for

The larger architecture may be ambitious, but the public test should not be grand. It should be small enough to audit, strict enough to refuse overclaiming, and boring enough that a critic can say exactly where it breaks.

I care about this because AI-assisted work is starting to touch real surfaces: repos, releases, benchmark claims, security reviews, customer demos, governance packets, internal tools, public pages. The more capable the agent becomes, the less acceptable it is for the final summary to become the only durable story.

Before trust is requested, the evidence should be inspectable.

That is the line I am trying to walk: small enough to audit, strict enough to refuse overclaiming, reproducible enough that another person can re-check the claim.

I am looking for failure cases, not applause.

If you build agent tools, I want to see a workflow where the trace exists but the review story is still weak.

If you maintain OSS projects, I want a release claim, benchmark claim, issue, or AI-generated patch where someone should be able to ask: what exactly was checked?

If you work near provenance, security, GRC, or standards, I want criticism on the verifier boundary: what belongs in the packet, what should stay outside it, and where the trust boundary needs to stay visible.

I need examples outside myself. Months of internal testing can prepare the idea, but it cannot prove the idea survives contact with someone else's repo, workflow, or release claim.

I wrote a short public intake note for that: send a small proof-surface test case. Keep it public, keep it narrow, and do not send secrets or private data.

Build with a model. Take nothing on faith.

References

Public-safe: no secrets, no client data, no private backend material. Back to Writing.