A score with no explanation is a black box, and a black box is the fastest way to lose a publisher's trust. The Request Inspector is the answer: a forensic drawer that opens on any single request and shows the complete decision trace behind its verdict — the IVT score, every signal that fired, the weighted reasons that drove it, the full request context, any ad-policy findings, and a chain-of-custody footer. It is the explainability spine of the product. When PubSentry blocks something, you can see exactly why; when it lets something through, you can see exactly why it held.
Make sure the tag is live before any of this has data to inspect:
<script async src="https://pubsentry.com/t.js" data-site="st_xxxx"></script>Opening the Inspector
Every list of requests in the dashboard is a door into the Inspector. Click any row in the Live Feed, any entry in Invalid Traffic, or any item on the Overview verdict tape, and the drawer slides in over a scrim. In the Live Feed you can also arrow through rows and press Enter to open the selected one, or paste an event ID into the command palette (⌘K) to jump straight to it. Escape or a click on the scrim closes it.
The drawer loads one request by its event ID from the read API (/v1/event?site=…&id=…), which pulls the stored row straight out of ClickHouse. It is the exact record PubSentry persisted at decision time — not a re-simulation — so what you read is what actually happened on the hot path.
The verdict hero — the spine
The drawer opens with the verdict itself, because the verdict is the spine everything else hangs off. A large monospaced IVT score (0–100) counts up on mount — a small, deliberate touch that signals the number is measured, not asserted. Beside it sits the action (block, monitor, or allow) and the class in PubSentry's taxonomy, each with a plain-English gloss:
givt— Confirmed invalid (general invalid traffic: the obvious, declared-bot, datacenter-tell cases)sivt— Suspected invalid (sophisticated invalid traffic that shows softer tells)policy_risk— Ad policy riskclean— Validated human
The hero also shows the gate latency in milliseconds — how long the decision took — and a one-line narrated summary of the single heaviest reason. A block gets a red left rim and an inset alarm tint; a monitor or allow verdict is intentionally not dressed as an alarm. Instead it carries a reassurance line — "Verdict held — 0 humans wrongly blocked" — because under our first principle (FPR = 0), not blocking a real human is a win, and the UI says so plainly.
Why this was flagged — the decision trace
Below the hero is the trace: the ordered list of reasons that produced the score, heaviest first. Each reason is a triple of { signal, weight, note } — the machine-readable signal name, the numeric weight it contributed, and a human-readable note. The single heaviest one is pulled out as a Top driver callout so the lede of the story is unmissable, then the full weighted list follows underneath.
This is the honest core of the explanation. The score is not a vibe — it is the sum of these weighted signals, and you can audit every term. If a request was blocked, the trace tells you which tells fired and how much each one mattered. If it cleared, the trace is empty and the drawer says so: "No firing signals recorded — this request cleared every check."
Request context — the forensic fact sheet
Next is the context grid, a key/value fact sheet of everything PubSentry knew about the request. This is server-enriched data, derived from the request at ingest:
- Geo — country, region, city
- Network — IP type, ASN, and ASN org (e.g. a datacenter ASN is a strong tell)
- Device — device type, OS and version, browser and version
- Screen — resolution, device-pixel-ratio, hardware concurrency, device memory
- Source — entry source and referrer domain
- UTM — source / medium / campaign
- Page, Fingerprint, Session
A note on privacy, because it matters here: the network and geo fields are derived server-side from the request IP using the offline iptoasn dataset (datacenter / ASN / geo — no residential-proxy, VPN, or Tor classification), and the raw IP and User-Agent are hashed with HMAC-SHA256 and then dropped. The Inspector shows you the device fingerprint and the ua_hash, never the raw IP or UA — because we never store them. You are looking at a forensic record that is already privacy-safe.
Ad-policy findings
If the request triggered the ad-policy scanner (ASPV), the Inspector renders each finding as a designed card — name, category, severity (tinted by the alarm grammar), a detail line, and the DOM locator that pins the finding to the exact place on the page. These are the same policy_findings stored on the event, surfaced as a readable list rather than raw JSON, so an ad-ops person can act on them.
Signals collected — the full vector
Detection runs many collectors, so the Inspector shows the full signal vector without drowning you. The heaviest, fired signals (truthy booleans or positive numbers) surface first as an inline preview; a "View all N signals" affordance expands into a live search-and-filter view with a Fired only toggle, so you can grep the entire vector for one tell. Fired signals are tinted brighter and dotted so they stand out from the quiet ones.
Audit — chain of custody
The footer closes the loop with provenance, so a verdict can be defended after the fact: decided-at timestamp, gate latency, model version, ruleset version, received date/time, and consent state. Together with the trace above, this is a complete chain of custody for the decision — what fired, what weighted it, which ruleset and model version were live, and when.
What the Inspector is not (yet)
The Inspector is read-only forensics. It explains a decision; it does not let you act on one from inside the drawer. To turn an observation into a control — block an IP, write a rule, change protection mode — you use the Rules & IP Management and Protection Mode screens. Programmatic access to single-event detail outside the dashboard (a public events API and webhooks for streaming verdicts) is on the roadmap and coming — today the Inspector is dashboard-only, served same-origin at app.pubsentry.com behind your account session.
The Inspector is where "block-before-serve" stops being a claim and becomes a receipt. Every verdict carries its own explanation, and you can read it.