The Events page shows you the tape. Click any row and the full record opens — the panel you'd screen-share in a dispute, and the thing an auditor actually reads when they sample your trail. This post walks one event top to bottom: an agent issuing a refund, recorded.
First block: who
The record opens with identity. Which agent acted, on whose behalf it was acting, and which session the action belongs to — so one refund connects to the conversation and the run that produced it. No more stitching together "the agent id in this log matches the service name in that one, probably." The record states its actor, and the actor links onward: one click to the agent's own history, one click to the full session around this action. An investigation that starts on a single event never dead-ends there.
Second block: what
Then the action itself: the tool that was called, the parameters it was called with, and the response it returned, along with outcome, duration, and the model context behind the decision. For our refund, that means the order id, the amount, the customer reference, the gateway's response, and how long the round-trip took — the complete anatomy of one decision, kept at the moment it happened rather than reconstructed afterwards.
Two things are deliberately different from a debug log. Secrets are stripped before the event ever leaves your environment. And personal data in declared fields doesn't appear at all — in its place sits a token, which brings us to the part that surprises people.
The sealed fields
Where the customer's email should be, the record shows a token. That's not the display hiding the value — the token is all Wytness ever received, because sealing happens in your environment, with a key generated in your browser that we never see. When someone on your side with the key needs the real value, the reveal runs locally in their browser, against your key. The record stays complete about the action while the person stays sealed, which is exactly the combination an audit needs.
Notice what this does to everyday screen-sharing, too. The panel can be shown in a meeting, pasted into a ticket, or walked through with an auditor without anyone first checking whether a customer's details are on screen. The safe-by-default version of the record is the record.
Third block: the proof
The bottom of the record is what makes it evidence. Two checks, each shown with its verdict:
- The signature. Every event arrives wrapped in an envelope signed by your environment. The verdict here means this exact record — this action, this timestamp, this payload — verifies against the public key registered for your organisation. Not "the platform says it's fine": a cryptographic check anyone with the public key can repeat. Events that fail this check never make it into your trail at all — they're rejected at the door — so a record you're reading has already proved itself once.
- The chain link. Each event carries a hash tying it to the event before it. An intact link means nothing between this record and its neighbours has been altered or removed. A broken one is shown as exactly that — the recorder reports its own bad news.
The panel is also honest about how the event was captured. An event recorded by the SDK at the moment of action carries a stronger claim than one collected from a platform's logs afterwards, and the record names its capture path rather than letting you assume the stronger one. Reading the proof block the way an auditor does takes about ten seconds: who says so, what exactly, can it be checked, and by which standard. All four answers are on the screen.
Why this much detail exists
Most days, nobody opens this panel. Then a customer disputes a charge, a security review lands, or an auditor picks twenty events at random — and the difference between "here is the record, verify it yourself" and "let me pull some logs together" is the difference between a ten-minute meeting and a very long quarter. Auditors sample precisely because they can't read everything; what they're really testing is whether any random record you're forced to produce holds up. A trail where every record looks like this one passes that test by construction.
For how the record gets here — signing, ingest, verification, archive — see How Wytness works. Questions about what the record captures in your stack? Ask us.