Watch one check happen.
Our framework observed our agent re-run nine of our published safety benchmark results. Below, one sub-second check before a tool call is slowed down to show each part. Every step was observed. Every number shown comes from the record.
incoming
Each action is scored for fidelity to the declared purpose, each measure on its own yardstick; higher is closer to the declared job. Below the declared threshold a departure is recorded and surfaced. Instrument reads, not production-calibrated grades. In passive mode they inform human review, never control execution.
- metered external APIs
- push, deploy, publish
- engine, scoring, keys
- writes outside run dirs
- samples as full results
- raw harmful content
Sub-second in real time. Thirty of these in this internal run, hash-linked into one record.
Observation only: TELOS watches and records at this hook. It does not block, and it cannot.
TWO WAYS TO READ THIS
Get the result in two minutes, or inspect the whole record step by step.
First, the job was written down.
A person wrote and fixed the purpose before the run. Every step is measured against it as the conversation changes.
THE DECLARED PURPOSE, VERBATIM FROM THE RECORD
frozen manifest
"signed" in this quote means the record's own demonstration key, not a production signature. Production signing is not claimed.
The job came with hard lines.
Six of them, declared up front, quoted here as written:
TELOS ran in passive observation only. It could read every step. It could not touch one. That is the design, not a limitation: the agent does the work, TELOS shows the work.
Before real work started, the run tested its own watcher. Step 1 exercised the purpose check against one allowed action and a set of forbidden test fixtures, a fake push and a fake production key among them, and confirmed the reads came back. Then the work began.
Then the agent worked. TELOS watched.
Thirty steps: loading the frozen job, fetching public datasets, hashing them, running nine benchmarks, reading the results, assembling the record. Every step got the same treatment you watched above. Step through the real record here.
Click a link in the chain, or use the arrow keys.
How one check works.
Each check is sub-second, and simple to say. The declared purpose sits at a fixed point in a space of meaning. Every action lands somewhere in that same space. How close it lands to the purpose is the read. Slow that down and it looks like this:
The anchor never moves. The actions land where they land. The distance is the read, and every read is written into the record.
For the reader who wants the math
The purpose is embedded once, at declaration, into a fixed vector. Each action is embedded into the same space as it happens. The read is the cosine between the two: the dot product of the vectors over the product of their lengths. A fixed anchor, a moving action, one angle.
Seven reproduced. One drift. One boundary held.
Nine benchmark rows, the published numbers next to what this run measured. Seven matched. One drifted under a different scorer. One hit a declared hard line and could not run. The record keeps all three, differences and all.
A record that can admit a drift and a boundary is the point.
| Benchmark | Items | Published | This run | Disposition |
|---|
The drift and the boundary are in the table above, not footnoted away. Each row traces back to its raw record in the run explorer.
Check the record. Right here.
Your browser checks all thirty steps and their links against the pinned head, with no server. Then alter the record to see the check fail.
The record is loaded. Thirty steps, untouched.
A record keeper for your agentic work.
That was a real run. Want this for your agents? Talk to the team that built it.
telos-receipt is the open unsigned receipt contract and SDK. telos-mcp 0.1.1 is the MCP governance server interface for scoring, receipts, audit-chain queries and counterfactual replay (CCRS). Both are on PyPI under Apache-2.0. The MCP release is observation-only: scoring, audit, and replay use synthetic stubs; no live governance engine is wired. Its receipts use the same unsigned payload-hash contract; a hash match does not prove issuer identity. Read the MCP server source or the standalone verifier source.