Skip to main content
Redaction in Nvisy is deliberately two-phase. A run first analyzes a document and records what it found; nothing is modified until you apply redactions. That separation is what makes the process reviewable and auditable.

The Phases

1

Upload

Add a file to a workspace. It is stored with its metadata and versioned.
2

Analyze

Start a run against a pipeline. Recognition produces entities, each with a label, confidence, and location.
3

Review

Inspect the run’s audit. Accept the policy’s default treatment, or override individual entities.
4

Redact

Apply redactions. The engine writes a new output file and finalizes the audit.

Run Status

A run’s status tells you which phase it is in:
A run stops at analyzed and stays there. It only reaches completed after redaction is explicitly applied, so an unreviewed document is never silently modified.
Poll the run, or subscribe to its event stream for live progress:

Pipelines and Policies

A pipeline carries the detection and governance intent: a default scope and the policies to apply. A policy defines how recognized entities are treated. Both are workspace resources, created once and reused across runs. Recognition itself is server-wide — the built-in pattern set plus the recognizers available in the catalog:

The Audit

GET /workspaces/{workspaceSlug}/runs/{runId}/detections/ returns the run’s audit, which has three parts: Container formats expose their internal parts. A DOCX, for example, keys embedded media by its zip entry name, such as word/media/image1.png, so an image inside a document is analyzed in its own right.

Entities

Each entity group is tagged by modality — text, image, audio, or tabular — and holds records with a consistent shape: Alongside each entity is an optional review — a reviewer-supplied override. When absent, the matching policy rule applies.

Redaction Operators

What actually happens to an entity depends on its modality. A single policy rule can name an operator per modality:
erase, keep, mask, replace, hash, hmac_hash, fake, pseudonymize, encrypt, truncate, clamp, generalize_date
keep is an operator like any other — it records that an entity was recognized and deliberately left intact, which is often exactly what an auditor needs to see.
Reversible operators such as pseudonymize and encrypt resolve against the per-policy vault and key provider, so the policy that authorized an override also governs how it can be undone.

Scope

A run’s scope carries per-document recognition settings — languages, jurisdictions, and OCR mode. Pipelines supply a default scope; a run can override it:
OCR modes are auto, force, and never.
auto is intended to extract the text layer and render only pages that lack one, but the text-layer parser that drives that decision is not in place yet — today only force actually renders.

Exporting the Audit

Once a run completes, export its audit for archiving:

Next Steps

Quickstart

Run the workflow end to end

Audit Trails

What the audit records

API Reference

Every endpoint

TypeScript SDK

Full API coverage