Training › Module 00

Module 00 — Foundation: How Veil Works

All new users · 45–60 minutes (including the hands-on exercise) · no prerequisites

In a hurry? Jump to the quick-reference card or the knowledge check — or print the all-roles reference.

Learning objectives

By the end of this module you can:

• Explain what Veil is, the problem it solves, and why it is more than a redaction tool.
• Distinguish the two regimes (LGOIMA and OIA) and know which section references apply to your instance.
• Describe the three families of withholding grounds and when a public-interest test applies.
• Follow a detection from pending to a decision, and a document through its review states.
• Name the five roles, what each can do, and how visibility scope differs from role.
• List the supported upload formats and the format warnings that protect a release.
• Identify the three export packages and state which one may leave the building.
• Recite the non-negotiable safety essentials before touching a live case.

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: 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 (see Supported upload formats); the review, redaction, export, and audit workflow for already-processed documents always works.

The two regimes

Veil runs per organisation in exactly one regime, chosen at activation. It cannot be changed in Settings.

• LGOIMA instances cite the Local Government Official Information and Meetings Act 1987; OIA instances cite the Official Information Act 1982.
• The oversight body is the Ombudsman in both regimes — only the section of the complaint right differs.
• Everything else — the pipeline, review screens, and export packages — works the same way. What differs is the wording, the grounds list, and one LGOIMA-only feature: the s 48 public-excluded withhold-in-full workflow (covered in Module 03), which does not appear on OIA instances.

This training, like the user guide, calls the request manager “the Lead” and uses “the Act” for both regimes.

Withholding grounds

A withholding ground is the section of the Act that justifies keeping a piece of information back. There are three families:

• Section 6 — conclusive. If the ground applies, the information must be withheld. No public-interest balancing.
• The middle section — public-interest test. These grounds only justify withholding if they are not outweighed by the public interest in release.
• The refusal section — covers refusing a request outright (for example, information not held).

“Section 6 — Conclusive” is labelled the same in both — but the ground lists differ slightly: the OIA list additionally includes s 6(e) (the economy of New Zealand).

The most common grounds map directly across regimes:

Your instance always shows the grounds and citations for your regime — you never need to translate.

Detections and decisions

• A detection is one piece of potentially-withholdable content Veil has flagged — a name, a phone number, a privileged sentence.
• Every detection starts pending. Veil never decides for you; nothing is pre-redacted.
• You make a decision on each: “Redact” (withhold it) or “Don’t redact — keep visible”.
• The detection card shows the decision state as “to decide”, “redacted”, or “kept visible”.
• Every redacted detection needs a withholding ground before the case can be exported. Veil pre-fills a suggested ground for most types; you can change it with “Edit grounds”.

Detections come from three sources: pattern detection of NZ personal identifiers (always runs), the AI layer (a configured cloud feature — contextual content such as legal privilege and commercial sensitivity), and custom rules your agency defines. All three produce ordinary pending detections for a person to decide.

Document review states

Each document moves through a fixed set of states (the label you see is in bold):

• “Ready for Review” → a reviewer opens it → “In Review”.
• All detections decided → “Reviewed (Initial)” (set automatically).
• A senior reviewer can send it back → returns to “In Review”.
• A final approver signs off → “Signed Off” (now frozen); at release → “Released”.
• A failed document shows “Error” with a plain-English reason.

Once a document is “Signed Off” it is frozen: detections are locked and can no longer be changed. Send it back for changes before final sign-off if anything is wrong.

The five roles and visibility scope

Five roles exist:

• Reviewer — reviews and redacts the documents assigned to them.
• Senior Reviewer — reviews decisions, can request changes, and makes disclosure decisions; does not give final sign-off.
• Final Approver — reviews, redacts, and gives the final sign-off.
• The Lead — creates cases, assigns work, and can also review and sign off.
• Administrator — system configuration only; has no access to cases.

Key permission boundaries:

• Accept / reject / add detections, assign grounds — any assigned case participant (Reviewer and above).
• Request changes / send back — Senior Reviewer, Final Approver, Lead.
• Final sign-off on a document — Final Approver or Lead only.
• Create a case, set deadlines, configure the workflow, delete a document — the Lead only.
• Final case attestation — an assigned Final Approver (or an assigned Lead) attests; the Lead releases or closes.

Visibility is set by scope, separately from role:

• Department scope — you see only cases that include your department.
• Org-wide scope — you see every case (the Lead and Final Approver are org-wide).
• Within a shared multi-department case, documents are further scoped to the department that owns them.
• The Administrator has no case access at all.

Permissions are enforced by the server, not the screen. Some buttons you cannot use are hidden; others are visible but will be rejected by the server — never assume access from the UI alone; the system re-checks your role on every action.

Supported upload formats

Veil accepts these document types at upload (the dropzone lists them):

• PDF, DOCX, XLSX, PPTX
• Email: EML / MSG (each email’s attachments become their own child documents)
• TXT

Four warnings every user must know:

• .PST email archives and .ZIP folders are not supported. Veil does not expand them — a ZIP is rejected at upload. Export emails as EML or MSG, or unzip the folder, and upload the files individually.
• Standalone image files (PNG, JPG and similar) are not accepted — they are rejected at upload with “Unsupported file type — supported: PDF, Word, Excel, PowerPoint, email (.eml/.msg), text.” Scanned documents are fine as PDFs: a scanned PDF is read through OCR like any other.
• Audio and video files are not screened. They may upload via drag-and-drop, but in a standard deployment Veil does not transcribe, detect, or redact them — never treat a media file as reviewed or safe to release unless your administrator confirms media transcription is enabled.
• Every upload needs OCR, a cloud feature your administrator configures. Veil converts each document (including DOCX, XLSX, TXT, EML, and MSG) to a canonical PDF and reads it through the OCR service — so if OCR is unavailable, no document can be processed; uploads go to “Error” until the service recovers.

The disclosure lifecycle at a glance

Nine steps, from request to closed case. Your role 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 (or “Import from SharePoint”, where your organisation has enabled Microsoft 365 integration).
3. Automated processing validate, extract text (OCR where needed), pattern detection, AI detection; the document reaches “Ready for Review”.
4. Review detections decide each one: “Redact” or “Don’t redact — keep visible”.
5. Assign withholding grounds every redacted detection gets a 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”.

The three export packages at a glance

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

• “Requester Package” — what you send to the person who made the request. It is screened: it omits the withheld-text column, reviewer reasoning, and the verification report, and anonymises filenames to Document_001, Document_002…
• “Internal Package” (marked “Recommended”) — for your own records: adds the audit trail, chain of custody, and verification report.
• “Ombudsman Package” — the full disclosure file for an Ombudsman review. It is the only package containing the unredacted originals.

Who can produce each: Requester — Reviewer and above; Internal — Senior Reviewer and above; Ombudsman — Final Approver and Lead only. The Administrator cannot generate any package.

Safety essentials — non-negotiable

Learn these before you touch a live case. They are covered in depth in the Solution Overview — safety by design.

• Redaction is permanent and irreversible. 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 on verification. 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.
• Every artefact is a potential leak channel. Withheld content can escape through more than the PDFs — schedules, filenames, previews, and reports can all expose it.
• Only the Requester package is screened for external release. The Ombudsman package contains the unredacted originals; the Internal package contains withheld content. Never send either to a requester.
• The Administrator has no case access. Configuration only — they cannot see cases, review documents, or generate packages.

Hands-on exercise

A guided look around a demo instance. You are looking, not changing — do not press any decision, sign-off, or export buttons.

1. Log in to the demo instance with the credentials your trainer provided.
2. Check the dashboard on “Home”, find the “Statutory deadline health” panel. Note the three health states — “On track”, “Urgent”, “Overdue” — and check your personal queue below it.
3. Browse the cases open “Cases” and note each case’s status label (for example “In Review”, “Ready for Export”).
4. Read the badges open one case and look at its Documents tab. Identify each document’s status badge — you should be able to name where each document sits in the review journey (“Ready for Review”, “In Review”, “Reviewed (Initial)”, “Signed Off”).
5. Look at detections open one document in Document Review. Find the “Detections” panel on the right and locate one detection card in each decision state you can find: “to decide”, “redacted”, “kept visible”. Do not press “Redact” or “Don’t redact — keep visible”.
6. Relate the rail to your role check the navigation rail: which of “Home”, “Cases”, “My Queue” / “Approvals”, “New Case”, “Custom Rules”, “Governance”, “Reports”, “Settings” can you see? Relate that to your role and scope.

Quick-reference card