Reviewing Alerts and Evidence

Use this workflow to turn a policy signal, unusual request, or human-review item into a reviewable operational record. Start with the smallest available request or time-window scope, then expand only when the evidence requires it.

Outcome

By the end of the review, you should have:

• The request, escalation, or audit identifier that anchors the investigation.
• The decisive outcome and the policy, routing rule, or workflow that caused it.
• The configuration and time context needed to interpret the result.
• A clear next action and owner.
• An export or durable evidence reference when the work needs a handoff.

Choose the right surface

Need	Surface
Inspect one request and its policy results	kt events tail or GET /v1/events with required since, using the request ID
Add retained prompt/response session context	History, when capture is enabled
Review or complete a human-review item	Inbox
Reconstruct audit chronology or request an evidence export	Trail
Compare the result with a rollout	Configurations
Watch a reproduction while it happens	kt events tail

Investigation loop

1. Capture the reported time, environment, gateway or agent, and request ID when available.
2. Find the decision Event by request ID with kt events tail --since <window> --json or GET /v1/events?since=<window>, or search the narrowest time window that covers the report. Confirm the final outcome, decisive policy result, provider/model context, and applicable configuration version.
3. Open History only when the flow has capture enabled and the retained prompt, response, or session context is necessary for the review.
4. Open Inbox only when the request created a human-review item. Claim or complete that item after reviewing the underlying request.
5. Use Trail when you need chronology or exportable evidence. Review nearby activity only as far as the investigation requires.
6. Record the conclusion, next action, owner, and evidence reference.

Questions to answer

• Is the decision expected under the current policy?
• Did a recent rollout change behavior?
• Does the activity indicate misuse, drift, or a configuration gap?
• Which stakeholder needs the evidence next: security, compliance, or product?

Build a useful evidence packet

Preserve enough context for another reviewer to retrace the decision:

• Request or escalation IDs.
• Environment, gateway or agent, and time window.
• Final outcome and decisive policy or routing result.
• Configuration version or rollout context when available.
• Export filename or Trail reference.
• Your interpretation, known limitation, and next owner.

Do not copy provider credentials, client tokens, or unnecessary request content into the handoff.

When evidence is missing

An absent History or Trail record is not proof that the request never occurred. History can be disabled, delivery is fire-and-forget, standalone gateways may have no control-plane sink, and request families do not all produce the same policy-evidence path.

When you cannot find the record:

1. Confirm that the application used the expected gateway and request family.
2. Check gateway connectivity and history or event-delivery configuration.
3. Reproduce the issue with kt events tail --follow when it is safe to do so.
4. Record the evidence gap explicitly instead of inventing a conclusion.

Close the review

The review is complete when the evidence supports one of these outcomes:

• Expected enforcement: document the decisive rule and share the reference.
• Narrow policy issue: preserve evidence before proposing a config change.
• High-impact regression: engage the rollout or rollback owner.
• Human decision required: use the supported Inbox claim and resolution flow.
• Provider or application issue: hand off with the request context intact.

Next steps

• Resolve an Escalation
• Investigate a Blocked Request
• Export Evidence for a Review
• Trail and Audit Evidence
• Troubleshooting