Skip to main content

Understanding Policy Verdicts: Allow, Block, Redact, Escalate

In Keeptrusts, allow means the request or response continues, block means delivery stops, redact means the gateway continues through the shared redaction path, and escalate means normal delivery stops and the result is handed to human review. The important nuance is that not every policy can emit every verdict. Different policy kinds expose different outcomes depending on where they run and what the runtime actually implements today.

Use this page when​

  • You are reading kt policy test results and want to understand what each verdict means operationally.
  • You are designing a chain that mixes sanitization, hard blocking, and human review.
  • You need to explain to stakeholders why one policy returns redact while another returns block for similar-looking content.

Primary audience​

  • Primary: Technical Engineers and review operators
  • Secondary: Technical Leaders and compliance stakeholders

allow means the chain did not stop delivery​

allow is the normal pass-through verdict. The gateway continues processing or returns the result to the caller.

That sounds obvious, but two details matter.

First, allow does not mean every policy found the content perfect. Some policies still attach useful metadata while allowing the response.

For example, Citation Verifier blocks only when the output is unverified and output_action.unverified_action is set to block. Other values keep the verdict as allow while still surfacing verification details. That is useful when you want visibility without making groundedness a hard gate.

Second, allow can still happen after modification elsewhere in the chain. Some policies rewrite or replace output while the overall flow remains allowed.

So the right mental model is: allow means the platform kept going. It does not mean nothing noteworthy happened.

block is the hard stop​

block is the clearest verdict. The request or response fails the policy gate and should not continue in its current form.

Many Keeptrusts policies use block as their strict outcome.

  • Citation Verifier can block unverified outputs when output_action.unverified_action: block is configured.
  • Financial Compliance blocks output when a configured blocked_patterns substring appears.
  • Healthcare Compliance does the same for configured medical-output phrases.
  • DLP Filter can block request content that matches detect_patterns or blocked_terms.

Use block when the content should not move forward at all. It is the right verdict for strong compliance constraints, explicit data-loss rules, and request-boundary attacks where sanitizing or reviewing would create unnecessary risk.

redact is not the same as allow-with-a-warning​

redact is a distinct operational choice. It means the content can continue, but only after the gateway applies the shared redaction path.

This matters because redaction is a design choice, not a softer block.

With PII Detector, action: redact returns a redaction verdict on input and also enables buffered response redaction when the policy is present in the chain. With DLP Filter, action: redact returns a redact verdict so the gateway redaction pass can run instead of rejecting the request outright.

That is valuable when the business goal is to preserve workflow continuity while still removing sensitive content.

Use redact when the response or request is acceptable after sanitization. Do not use it when the presence of the content itself is disqualifying.

escalate turns the event into human work​

escalate means the chain decided automation should stop and a reviewer should take over.

Human Oversight is the cleanest example. When action: escalate is configured, the gateway marks the result as ESCALATE, returns successful completion metadata with null assistant content, and records a decision event with reason_code = "oversight.required".

This is not a block in disguise. A blocked result says the content is disallowed. An escalated result says the system is deferring the decision to a human.

That distinction matters operationally. Blocks reduce risk immediately. Escalations shift the work into a review queue, often with assignment hints from provider-level escalation_routing.

A compact example that shows all four outcomes​

You can see the verdict families by combining a few policies with deliberately different behaviors:

pack:
  name: verdict-examples
  version: 1.0.0
  enabled: true

policies:
  chain:
    - pii-detector
    - dlp-filter
    - citation-verifier
    - human-oversight

policy:
  pii-detector:
    action: redact
    detect_patterns:
      - 'EMP-\d{6}'

  dlp-filter:
    blocked_terms:
      - board-only forecast
    action: block

  citation-verifier:
    require_sources: true
    require_source_match: true
    output_action:
      unverified_action: block

  human-oversight:
    action: escalate

From a runtime perspective:

  • a normal safe request can allow until it reaches a later control
  • a request containing EMP-442871 can redact
  • a request containing board-only forecast can block
  • an output path governed by human-oversight can escalate

This example is intentionally compact, but it shows the important point: verdicts come from policy behavior, not from a single global switch.

How to choose the right verdict for the job​

The best choice depends on what you want the system to do next.

Choose allow when the content should continue and any attached metadata is informational.

Choose block when the content must not pass in its current form.

Choose redact when the content can still be useful after sanitization.

Choose escalate when the decision itself requires human accountability.

That is why Financial Compliance and Healthcare Compliance often sit before human review. If the content clearly violates a deterministic rule, block it. Do not turn obvious violations into queue work.

It is also why Quality Scorer is useful before escalation. A weak response should often fail automatically rather than occupy reviewer time.

How verdicts show up in testing​

One of the fastest ways to understand verdict semantics is to look at the pack test output.

kt policy test --json

The CLI docs are explicit that test expectations use verdicts such as allow, block, redact, and escalate. This makes the test runner more than a regression tool. It becomes a shared vocabulary for policy intent.

If a teammate says, "this route should redact employee IDs but block investor guidance phrases," that can become an executable contract.

That is better than arguing from memory after an incident.

Common misunderstandings​

One misunderstanding is treating redact as a weaker block. It is not weaker. It is different. It says the content can proceed after sanitization.

Another misunderstanding is treating escalate as equivalent to block. It is not. A block ends the automation path. An escalation opens a human path.

The third misunderstanding is assuming every policy supports every verdict. It does not. Citation Verifier is effectively allow or block. Human Oversight is a focused escalation control. PII Detector and DLP Filter are the common request-side redaction examples.

Key takeaways​

  • allow means the flow continues.
  • block means delivery stops.
  • redact means the gateway continues through sanitization.
  • escalate means the platform stops normal delivery and hands the case to human review.
  • The available verdicts depend on the policy kind and the current runtime implementation.

Next steps​