Skip to main content

Events Stream: Real-Time Policy Decision Monitoring

The Events page is where policy execution becomes operational evidence. It is not just a log dump. In Keeptrusts, the page combines verdict tabs, time-range selection, free-text search, provider and model filters, gateway and reason-code filters, quality filtering, and row-level event detail so you can answer a concrete question quickly: what is the platform doing right now, and is that behavior expected?

Use this page when​

  • You need to watch live decision traffic after a policy rollout or provider change.
  • You are investigating blocks, redactions, rewrites, or escalations and need request-level evidence.
  • You want to separate a true policy regression from a team-specific, gateway-specific, or model-specific anomaly.

Primary audience​

  • Primary: Technical Engineers and Platform Operators
  • Secondary: Technical Leaders and Governance reviewers

The problem​

Aggregate dashboards are useful until you need to explain a specific change. A chart can tell you that blocks increased, but it cannot tell you whether the increase came from one gateway, one model, one team, or one recent configuration version. At that point you need event-level monitoring.

Many teams try to bridge that gap with ad hoc API queries or external logging tools. Those are useful, but they are often too far from the daily operating workflow. By the time you open a SIEM query or stitch together raw JSON, you have already lost time.

The harder problem is that policy behavior is multi-dimensional. A spike in blocked traffic might actually be normal if a new high-risk workflow launched. A rise in escalations might be a false-positive problem or just a review routing issue. A drop in quality may happen even while most requests are technically allowed.

If you cannot slice the event stream by verdict, provider, model, gateway, reason code, and quality at the same time, you will keep guessing.

The solution​

Keeptrusts solves that by making the Events page a first-line operational surface instead of a secondary audit screen.

The page refreshes on a regular interval, keeps a visible “last updated” indicator, and detects when new events have arrived. That is enough for near-real-time monitoring without turning every investigation into a manual refresh loop.

The top of the page gives you a compact summary of what is currently in scope:

  • Total event volume.
  • Average quality when quality scores are present.
  • Verdict counts for allowed, flagged, blocked, redacted, and rewritten traffic.
  • A distribution bar so you can see the mix at a glance.

From there, the page branches into filters that matter operationally.

The verdict tabs let you jump directly between all, allow, block, escalate, redact, and rewrite. The time-range filter narrows the monitoring window. The search box helps when you already know part of an event ID, reason code, or metadata value.

When that is not enough, the secondary filters become the real workhorses. You can narrow by event type, provider, model, gateway, reason code, and quality band. That turns a noisy stream into a very small evidence set.

If your organization is team-scoped, the page also surfaces access boundaries directly. Instead of silently hiding data, it can show which teams are accessible and which are restricted. That is a small detail, but it prevents a common mistake: assuming an empty result means no events exist.

Implementation​

The most reliable way to use the page is to treat it as an investigation funnel.

  1. Open /events with the shortest time window that still covers the suspected behavior.
  2. Choose the verdict tab that matches the question you are asking.
  3. If you still have too much noise, expand the additional filters and narrow by provider, model, gateway, reason code, or quality.
  4. Open individual event rows to inspect the underlying request context.
  5. Correlate what you find with the active configuration version and recent rollout history.

This matters after configuration changes. Suppose you deploy a tighter prompt-injection rule and want to know whether it behaved as intended.

Start with a short time window in Events. Switch to the blocked or escalated verdict tab. Filter to the target gateway or model if the rollout was partial. Then scan reason codes and open a sample of event details.

If the reasons line up with the expected threat class, the change may be working as intended. If the events look like ordinary user prompts, you likely have a false-positive problem and should pivot into configuration tuning.

The CLI is useful when you want the same evidence outside the browser. The user docs already expose the direct companion command:

kt events tail --since 1h --verdict blocked --json

That command is especially useful for two cases.

The first is post-rollout verification. You can compare what the page shows against raw recent JSON and confirm that the verdicts, providers, models, and config versions line up.

The second is handoff. If another engineer is helping with the investigation, a short CLI query gives them the same slice of evidence without requiring them to reproduce your exact filter state in the browser.

One practical workflow is “monitor after deploy.”

  1. Save and deploy a new configuration version.
  2. Open Events immediately with a short time range.
  3. Watch the overall verdict mix and average quality.
  4. Filter to the affected provider or gateway.
  5. Open a representative sample of changed events.
  6. If you see a meaningful rise in escalations, move into the escalation queue while the policy owner reviews the change.

Another practical workflow is “find the scope of a problem.”

  1. A dashboard or alert suggests blocked traffic has increased.
  2. Open Events and switch to blocked verdicts.
  3. Filter by gateway. If the problem is isolated, you now know it is not platform-wide.
  4. Filter further by model or reason code.
  5. Open several event details and record the configuration version.
  6. Decide whether to change policy, routing, or reviewer process.

The page is also useful for quieter work. You can filter by low quality, not just by strict enforcement verdicts. That helps when the system is technically allowing traffic but the output quality trend is degrading. In practice, that often points to prompt design, provider choice, or knowledge grounding issues rather than policy overreach.

Results and impact​

Teams that use the Events page well stop treating governance as a black box. They can explain why a verdict changed, where the traffic came from, which provider handled it, and whether the behavior aligns with the intended configuration.

That changes incident handling. Instead of saying “blocks are up,” you can say “blocks increased only on one gateway after version 1.4.2, almost entirely on a single reason code.” That is actionable. It tells the next owner where to look.

It also improves change safety. Every rollout should have a monitoring phase. Events is the fastest place to do that because it sits directly on top of the governed request stream rather than a delayed reporting layer.

Key takeaways​

  • The Events page is most useful when you start with a narrow question and filter aggressively.
  • Use verdict tabs first, then time range, then provider/model/gateway/reason-code and quality filters.
  • The page’s refresh cycle and freshness indicator make it practical for near-real-time monitoring.
  • Team access summaries help distinguish “no events” from “no permission to see those events.”
  • Pair the page with kt events tail when you need raw evidence or a quick handoff to another operator.

Next steps​