Solution Overview

What Veil is, how a request flows from intake to release, and the safety principles behind every package that leaves the building.

What Veil is and the problem it solves

Veil is an AI-assisted disclosure workflow platform for official-information requests in New Zealand. It manages the whole lifecycle of a request under the Act: intake → automated detection → tiered human review → permanent redaction → export package → audit trail. It is not merely a redaction tool.

The problem it solves: releasing official information safely is slow, manual, and error-prone — one missed name can breach privacy. Reviewers must apply the correct statutory withholding ground to each piece of withheld content, and prove they did. A response is only defensible if there is an immutable record of who decided what, and when. Veil makes disclosures faster, safer, and auditable — and blocks an external release that cannot be verified clean.

AI detection is an optional cloud feature your administrator configures — pattern detection still runs without it. OCR is also administrator-configured, but processing new uploads depends on it; the review, redaction, export, and audit workflow for already-processed documents always works.

Under LGOIMA your instance cites the Local Government Official Information and Meetings Act 1987; withholding sections are s 6 / s 7 / s 17. Under OIA your instance cites the Official Information Act 1982; withholding sections are s 6 / s 9 / s 18.
The Veil dashboard (Home) showing the statutory-deadline-health panel and the personal review queue
The dashboard — “Home” — with the deadline-health panel and your personal queue (shown on a council-branded demo instance)

The disclosure lifecycle — nine steps

Every request follows the same journey from intake to a closed case. Your role’s training module goes deep on the steps you own; here is the shape of the whole journey:

  1. Create the request The Lead uses “Log a new request”; Veil assigns the “Reference” and the “Statutory deadline” automatically.
  2. Upload documents On “Document Ingestion”, drag and drop your files. (An “Import from SharePoint” tab appears where Microsoft 365 is connected — in-app import is coming soon.)
  3. Automated processing Veil validates, extracts text (OCR where needed), and runs pattern and AI detection; the document reaches “Ready for Review”.
  4. Review detections Decide each one: “Redact” or “Don’t redact — keep visible”. Nothing is pre-redacted — a person makes every decision.
  5. Assign withholding grounds Every redacted detection gets a statutory ground via “Edit grounds”.
  6. Sign off and senior review The reviewer presses “Sign Off”; a senior reviewer can “Request Changes”“Send Back”.
  7. Final approval and attestation “Final Approval” freezes each document; the approver then completes the case-level “Final sign-off” and presses “Attest case complete”.
  8. Export the package On “Finalise & Close”, choose the package and press “Generate Export Package”; Veil burns in the redactions and verifies they are permanent.
  9. Release and close The Lead presses “Mark as released” (irreversible), then “Close & archive”.
Diagram of the nine-step disclosure lifecycle from creating the request through to release and close
The nine-step disclosure lifecycle at a glance
Under LGOIMA the statutory deadline is calculated per s 12 (20 working days). Under OIA the statutory deadline is calculated per s 15 (20 working days).
A case lifecycle row showing each stage of the request from intake to closed
The case lifecycle row tracks where a request sits in the journey (shown on a council-branded demo instance)

What happens to a document

When you upload a file, Veil processes it automatically before anyone reviews it:

  1. Validate The file type is checked — PDF, DOCX, XLSX, PPTX, email (EML/MSG), and TXT are accepted; ZIP archives and standalone images are rejected at upload.
  2. Extract text (OCR) The document is converted to a canonical PDF and read through the OCR service — scanned PDFs are read like any other.
  3. Pattern detection New Zealand personal identifiers — names, phone numbers, IRD numbers, addresses and similar — are flagged. This layer always runs.
  4. AI detection Where configured, the AI layer flags contextual content such as legal privilege and commercial sensitivity; custom rules your agency defines run alongside it.
  5. Ready for review Every flag becomes a pending detection for a person to decide — the document reaches “Ready for Review”.

From there, each document moves through a fixed set of review states:

Ready for Review In Review Reviewed (Initial) Signed Off frozen — detections locked Released sent back for changes
The document review states. A document showing “Reviewed (Initial)” can be sent back to “In Review”; a failed document shows “Error” with a plain-English reason.

A reviewer opening a “Ready for Review” document moves it to “In Review”; once all detections are decided it becomes “Reviewed (Initial)” automatically. A senior reviewer can send it back, and a final approver’s sign-off makes it “Signed Off” — frozen, with detections locked. Send a document back before final sign-off if anything is wrong.

The three export packages at a glance

Veil produces exactly three package types, each for a different audience:

Item“Requester Package”“Internal Package”“Ombudsman Package”
Redacted PDFs
Withholding schedule (with reasoning) (full reasoning)
Covering letter
Audit trail
Chain of custodyoptional
Verification report
Unredacted originals

The “Requester Package” is what you send to the person who made the request — it is screened, omitting the withheld-text column, reviewer reasoning, and the verification report, and anonymising filenames to Document_001, Document_002… The “Internal Package” (marked “Recommended”) is for your own records. The “Ombudsman Package” is the full disclosure file for an Ombudsman review — the only package containing the unredacted originals.

⚠ Warning: Only the “Requester Package” is screened for external release. The Ombudsman package contains the original, unredacted documents, and the Internal package contains withheld content — never send either to a requester.
The Select Export Package cards showing the Requester, Internal, and Ombudsman packages with their per-package Includes lists
The three package cards with their “Includes” lists (shown on a council-branded demo instance)

Safety by design

Five non-negotiables underpin every release. Learn these before you touch a live case:

Redaction is permanent

At export, accepted redactions are burned in and flattened — the underlying text is destroyed, not hidden. There is no undo. The in-app “Redacted” preview only covers content visually; permanent redaction happens at export.

The system fails closed

An external release (Requester or Ombudsman package) is blocked if the automated check finds a leak or cannot run. “Couldn’t verify” is not “clean”. Never override or work around a block.

If you hit this, see FAQ: an export is blocked.

Every artefact is a leak channel

Withheld content can escape through more than the PDFs — schedules, filenames, previews, and reports can all expose it. Every artefact is held to the same bar.

Originals never go to requesters

Original, unredacted documents are retained for the audit trail and the Ombudsman package. They must never be sent to the requester.

The Administrator has no case access

Configuration only — an Administrator cannot see cases, review documents, or generate packages. See Roles & Permissions.

← Home Roles & Permissions →