Skip to main content
Customer guide

Coverage and proof status

Read each surface by enforcement point, observed result and explicit gap.

For: Security policy owner, Evaluator, Procurement reviewer

Before you begin

Name the application, action, device or connector, direction of data flow and policy you intend to evaluate. Use synthetic data and obtain the owner’s permission for the test.

  1. Record the exact path you will exercise, including possible bypass routes.
  2. Read /coverage and /faq#disclosures before treating a product surface as pilot scope.

Supported scope and current status

The public /coverage table distinguishes inline decisions, post-event discovery and device-local controls. A visible administrative module says which controls are offered, not whether paid standing, capacity or actual enrolled protection was verified. A named integration is not evidence that every workflow is active.

  1. Identify the row and its enforcement tier.
  2. Check the guide for that surface and its current proof limit.

Compare this path with the published coverage table.

Set up the path

Agree a small test matrix with an allowed value, a synthetic sensitive value and an unavailable or bypassed path. Obtain the current release and configuration details from the authorized workspace owner.

  1. Mark which traffic is explicitly routed or enrolled.
  2. Separate a declared capability from a path your team has actually enabled.

Use the workflow

Exercise one action at a time on the named path. Observe both what the user sees and what the destination receives; use another test for any alternate route.

  1. Run the allowed case, then the sensitive case.
  2. Record the time, surface, policy version and destination outcome without storing real sensitive content.

Verify the result

Read administrative availability, commercial standing/capacity and enrolled protection separately. Then match the downstream effect to the decision record and its scope. For a discovery surface, verify a finding without calling it a pre-send block.

  1. Check whether the event, decision and destination observation agree.
  2. Use /verify for the limits of chain and package verification.

Coverage references: 19 requirements, 0 currently passed

This guide is bound to 19 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.

See the public verification overview and the documentation coverage guide.

Denials and recovery

A stale device, failed connector or unavailable event readback is an unknown state, not a clean result. Stop expansion and obtain a fresh authorized readback after repair.

  1. Note the exact path and failure state.
  2. Repeat the synthetic action after the supported recovery.

For customer-side next steps, read Recovery and support.

Billing and integration handoffs

Coverage depends on the configured integration and, for managed devices, admitted seat capacity. A proposed first pilot does not automatically include all surfaces on /coverage.

  1. Confirm the integration and device-management owner.
  2. Check /pricing for seat limits and the relevant integration page for proof status.

Limits to keep in view

The current public evidence projection for the market workflow graph has no passed rows. This guide provides a test method and map of claims; confirm each path with current release evidence before relying on it.

  1. Do not combine distinct surfaces into a universal protection claim.
  2. Request release-specific evidence before using a path with customer data.

Review the current Disclosures before relying on a capability.