Observability and evidence

A trace is not evidence, and was never meant to be.

LLM observability answers “is the model behaving”, for engineers, on storage built to be cheap and short-lived. That is a good product. It is not the artefact you hand a regulator.

The same ninety seconds

Two tools, two questions.

Both watch the same agent do the same thing. They are built to answer different people, and it shows in every design decision underneath.

Who is it for?
LLM observabilityEngineers, debugging why an answer was wrong.
A system of recordWhoever has to answer a regulator, an auditor, or a customer's security review.
How long does it keep?
LLM observabilityDays to weeks. Traces are expensive to store and cheap to lose.
A system of recordAs long as the obligation. Years, because that is what the duty runs to.
Can it be edited?
LLM observabilityYes, and nothing in the trace would show it. Nobody built them to be evidence.
A system of recordEach entry carries a fingerprint of the one before it. An edit breaks every link after it.
Who approved the action?
LLM observabilityUsually the service account that called the API.
A system of recordThe named person, taken from the authenticated session on the server.
Can it stop anything?
LLM observabilityNo. A trace is written after the call returns.
A system of recordThe rule runs before the action executes, and the refusal is recorded beside it.
Can an outsider check it?
LLM observabilityThey read what you export, and take your word for it.
A system of recordThey run the verifier offline — no account, and nothing from us.

The shortest-lived trace store in a typical stack keeps roughly seventy times less than the shortest obligation it would have to satisfy.

Where we actually sit

Downstream, not opposite.

If you already emit traces, you have done most of the instrumentation work. We read the same spans.

You already trace

OpenTelemetry spans, or the OpenInference instrumentors for OpenAI, Anthropic and LangChain.

We read the same spans

Model calls become recorded actions, tool executions become tool calls, and payloads become fingerprints.

One record comes out

Sealed, countersigned, and checkable by someone who has never heard of your stack.

What this does not replace
Debugging. If you need to know why a model returned a bad answer, you want traces with full payloads and a good UI for reading them. We hold fingerprints by default and are the wrong tool for that question.
Before you switch anything

The four that matter.

Including the one where the answer is that you may not need us yet.

The wider category →
01Do we need both?
Usually. They answer different questions and neither substitutes for the other. If nobody is going to ask you to prove what an agent did — no regulator, no auditor, no enterprise customer with a security review — you probably need observability and not this.
02Can we not just keep our traces for longer?
Retention is the easy half. The hard half is that a stored trace can be edited and nothing about it would show, and that the actor on it is usually a service account rather than the person who authorised the action. Longer retention gives you more of a record that was never built to be evidence.
03Does Auditant replace Langfuse or Phoenix?
No, and we would rather say so. Those tools are good at the job they do, and we read the same OpenTelemetry spans they do — if you already emit traces, we capture from them. We sit downstream, turning what happened into something a third party can verify.
04What does it cost to record everything?
Nothing extra. Pricing is a flat band by agent count, never per event — metering events would pay you to record less, and an incomplete record is the one failure this category cannot survive.
Start

Keep the traces. Add the record.

Two lines in one agent, free while you evaluate — and it reads the spans you already emit.

Start freeSee it live
  • No card to start
  • Nothing is blocked until you say so
  • Your proof stays yours if you leave