Agent Trust & Assurance · Evidence
The other stories make each thing an agent uses trustworthy. This one starts from an answer and asks what made it: which agent, which model, which ontology, which skills, and whether each one was signed and unchanged at the moment it answered. Then it lets anyone check the answer, without Uderia.
Trust & Assurance · visual story · companion architecture: Evidence · the tool: Evidence Verifier
On 9 October 2026 at 10:26 UTC, the policing demo's estate analyst @PXPROD on the hosted instance was asked "How many robberies are there in the data?" It answered: "There are 179,193 robberies recorded in the data, according to the Policing_Core.v_Offence table (where offence_code is '120')."
Everything below is read from that answer's record. Its evidence was exported from the hosted instance, and the panel in Act V verifies the file in your browser.
When a turn starts, the platform records every signed part the agent will use: the agent itself, the deployment it runs on (model, tool catalog, connectors), and what it is made of (its ontology, any extension of it, its skills, its knowledge and planner repositories). For each part it keeps the content hash at that moment and the signature that matched it. This list is the answer's bill of materials.
The answer's own Evidence row reads 8 parts · all signed when answered. Had a part been unsigned or edited after signing, the row would name it — the exception is the only thing that is marked.
The list comes from the same composition the trust badge resolves, so it holds exactly what the agent's signature covers. The data products an answer read and the writes it performed appear beside it too, each from its own sealed receipt.
Which provider, which model, how many tools and which connectors the agent could reach are the deployment part. A model swapped since the deployment was attested reads as changed, so an answer always says what it actually ran on.
Every Uderia answer already leaves a hash-chained, Ed25519-signed record of its steps. The bill of materials becomes its last step. The question and the answer are hashed into the first and fifth. Change any of them afterwards, in the database or in an exported file, and the chain stops verifying.
The hashes are this answer's own, abbreviated. A step's content hash covers what the step recorded; the chain hash links it to the step before; the Ed25519 signature binds both to the deployment's key.
The chain hashes the first 4,096 characters of the question and of the answer. A verifier re-hashes the text it is given and compares; an answer edited in an exported file reads "the answer text does not match what was sealed".
The last step's content hash is the digest of the bill of materials. Claiming afterwards that the answer ran on a different model, or without a part it used, breaks the tip — and with it every check that depends on the chain.
A signature is not a status that gets replaced. Re-signing an agent or an ontology adds a record; the earlier signature stays. So an answer's evidence always names the exact version it was made with — the teradata-sql-expert skill as signed on 7 October, the ontology as signed on 21 September — even after both have moved on.
A new record is appended. Answers given before it keep pointing at the version they used; answers after it point at the new one.
Every key that has signed here is kept. A signature made with a retired key still verifies, and the estate lists it as made with a retired key.
The answer's text goes; a content-free record of which parts, which hashes and which signatures stays, and reads session deleted — content not retained.
The trust badge of each skill, ontology or agent now says Used by N answers · M with this version. When a flaw is found in an artefact, the operator sees at once which answers it touched, and how many of them used the version that has the flaw.
Each part carries two readings in a fixed order: its state when the answer was given, and its state now. A part signed then and edited since reads changed since; the answer itself is untouched, and the evidence still names the version it used. The same question, asked a few minutes apart on the same day, shows why both readings matter.
Both answers were correct: 179,193. Evidence does not grade the answer — it says what the answer was made with. On the publisher's working copy that included an agent whose configuration had moved since its signature, and every answer it gives says so until someone re-signs it.
Trust → Evidence lists every signature the operator may see, worst first: changed since signed, made with a retired key, recorded without a signature. On the hosted instance's publisher account, on the day this was written: 67 signatures · 17 changed since signed. Filters narrow the list; they never change the summary.
A part that changed since, or was never signed, offers Open trust record, where it can be re-signed. An intact part offers nothing — there is nothing to do.
Export evidence puts one answer in one file: the question, the answer, its trust checks, its sealed chain, every signature it was made with, the public key, and a signed checkpoint of the evidence ledger. The file is checked by a small script or by a web page, with no Uderia server involved — an auditor does not have to trust Uderia's interface to check Uderia's records.
Try it — this is the answer above, exported from the hosted instance
The deployment's public-key fingerprint, which an auditor gets from the operator, not from the file:a6c5cf5c09865269e3d3b660837435aff471e602b840fb31a08777a7a0549a57
Choose one. The check runs here, in your browser (WebCrypto Ed25519 and SHA-256); nothing is sent anywhere.
The same file: download it and drop it on the Evidence Verifier, or run python scripts/verify_evidence.py evidence-answer-sample.json --fingerprint a6c5cf5c09865269e3d3b660837435aff471e602b840fb31a08777a7a0549a57 (needs only pip install cryptography).
The script and the page check the same things — each signature with the carried key, the key's fingerprint, each answer's chain, its bill of materials, its question and answer text, the ledger proof — and a gate runs both on the same files, tampered or not, and requires the same verdict.
A full export carries the exact bytes each signature binds, up to a size limit, so the content itself can be re-hashed offline. The full export of this answer re-hashes all 8 signed parts. The sample on this page omits the content: some of it is internal skill text.
Signatures protect each record. The evidence ledger protects the history around them: every signing event and every answer's record is entered in one hash chain, in the same transaction that writes it. Editing, inserting or removing a record afterwards breaks the chain, and the Evidence tab says so.
On the hosted instance the ledger reads ledger intact: 158 entries at the checkpoint this answer carries, no breaks, no edits. Its signatures entered the history the first time the release started, with their original signing dates.
By default the key is a file on the server, and every export and the ledger chip say so. Switched to an external signer, the server can ask for a signature but never read the key; every signature it returns is checked before use, and older answers keep verifying against the key that signed them.
The external signer was run with a key held in SoftHSM over PKCS#11; checkpoints were published to a real webhook and to freetsa.org. The time-stamp receipt passes openssl ts -verify and fails when one byte of the checkpoint is changed.
From the answer on this page, the hosted instance it came from, and the gates every increment had to pass.
A signature proves what was recorded and that it has not changed — not that the answer is right. Whether it is right is the job of grounding, guardrails and the judges. With the default setting — the one the hosted instance runs — the signing key lives on the server, so its administrator could rewrite and re-sign history; what they cannot do is make it contain a checkpoint someone exported earlier. External custody and anchoring close the rest. An answer given before evidence recording existed can never show its parts, and says so. Signed content travels up to 256 KB per part; a larger part travels as its hash.
Trust in an agent is a claim about the past: what it was made of when it answered. Evidence turns that claim into a record — inventoried at the start of the turn, sealed at the end, kept as history, and checkable by anyone with a file and a fingerprint. The other stories make each part trustworthy. This one shows, for any single answer, that it was.