Video Series

Welcome to Veil. If your job involves releasing official information — under the Official Information Act, or its local-government counterpart — this is where you'll spend your day. This series takes you from your first look at the screen to a fully reviewed document. Let's start with why Veil exists at all. Releasing official information safely is slow, manual, and error-prone. Requests arrive with hundreds of pages. Every page can hold a name, a phone number, a privileged sentence. One missed name can breach someone's privacy. And every piece of withheld content must be justified under the correct section of the Act — with proof that a person made that decision. Miss the statutory deadline, or fail to show your working, and the response is hard to defend. That's the problem. Veil is an AI-assisted disclosure workflow platform. Note the word workflow. It is not merely a redaction tool. It manages the whole life of a request: intake, automated detection, tiered human review, permanent redaction, export packages, and an immutable audit trail. It runs as a single instance for your agency — this one is the Ministry of DataSing, running in OIA mode. On a council instance you'd see LGOIMA wording instead; everything else is identical. Here's the lifecycle at a glance. One: the Lead creates the request — Veil assigns a reference and the statutory deadline automatically. Two: upload the gathered documents. Three: automated processing finds detections — the names, numbers, and sensitive passages. Four: people review each detection and assign withholding grounds. Five: the reviewer signs off, then senior review. Six: final approval per document, then a case-level attestation. Seven: export the right package — Veil verifies the redactions are permanent. Eight: release to the requester. And nine: close the case. Nine steps, one system, one audit trail. Now the most important idea in the whole product. Veil's AI reads every document and flags what might need withholding — a name, a bank account, a legally privileged sentence. Each flag is called a detection. But every detection starts pending. Nothing is ever pre-redacted. A person decides each one: Redact, or Don't redact — keep visible. The AI suggests. Humans decide. Every decision is recorded, with who made it and when. One more thing before we go deeper. Veil fails closed. When you export a package for release, it verifies that every redaction is genuinely permanent. If it finds a leak — or if it can't run the check at all — the external release is blocked. Couldn't verify is not the same as clean. That single rule is what makes Veil safe to trust with someone else's privacy. Let's recap. Manual disclosure is slow and risky — one missed name can breach privacy. Veil manages the whole lifecycle, from intake to release, not just redaction. Every request follows nine steps, ending in a verified, auditable package. And throughout, the AI only ever suggests — a person makes every decision. Next time: the core concepts — regimes, withholding grounds, detections, document states, and the five roles. See you in episode two.

Welcome back. Before we touch a single document, you need five ideas: regimes, withholding grounds, detections, document states, and roles. Get these, and everything else in Veil makes sense. Let's take them in order. Veil runs in one of two regimes. Central-government agencies use the Official Information Act 1982 — that's OIA, which is what you're seeing here at the Ministry of DataSing. Councils use the Local Government Official Information and Meetings Act 1987 — LGOIMA. Your instance is fixed to one regime at activation; it can't be changed in Settings. The two differ only in wording: the Act's name, the section numbers, and a couple of labels. This role, the OIA Lead, is shown as LGOIMA Lead on a council instance. The oversight body is the Ombudsman in both. The pipeline, the review screens, the export packages — all the same, with one exception we'll flag in episode seven: a LGOIMA-only tool for withholding a document in full. A withholding ground is the section of the Act that justifies keeping information back. There are three kinds. Section 6 grounds are conclusive — if one applies, there's no balancing to do. Section 9 grounds — you can see the group label here, Section 9, public interest test required — protect things like privacy and commercial position, but only if the public interest in release doesn't outweigh them. And Section 18 covers refusing a request outright. On a council instance, the same three kinds are numbered sections 6, 7, and 17 — Section 7 is the public-interest group there. Every redaction you make must carry one of these grounds before the case can be exported. In practice, a handful of grounds do most of the work. Privacy of a natural person — section 9(2)(a) here, 7(2)(a) under LGOIMA. Legal professional privilege. Free and frank opinions. And commercial position. Veil suggests a ground for most detections, and you can always change it. We'll assign grounds hands-on in episode four. 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, and nothing is pre-redacted. You make a call on each one: Redact — withhold it — or Don't redact, keep visible. The card tracks where you're at: to decide, redacted, or kept visible. A document is only finished when every detection has a decision. Each document moves through a fixed set of states, and the badge tells you where it is. Ready for Review — processing is done, waiting for a person. A reviewer opens it: In Review. Once every detection is decided it becomes Reviewed, Initial — that happens automatically; pressing Sign Off submits it for senior review the same way. A senior reviewer can send it back to In Review if something needs another look. Then a final approver signs off: Signed Off — and the document is frozen. Its redactions can no longer change. At release, it becomes Released. Frozen means frozen — if anything's wrong, send it back before final sign-off, not after. Five roles. A Reviewer reviews and redacts the documents assigned to them. A Senior Reviewer checks decisions and can request changes — but cannot give final sign-off. A Final Approver reviews, redacts, and gives that final sign-off. The Lead — shown here as OIA Lead — creates cases, assigns work, and can also review and sign off. And the Administrator configures the system but has no access to cases at all. One rule to remember: final sign-off belongs to the Final Approver or the Lead — never the Senior Reviewer. Last concept: what you can see is set by your scope, separately from your role. Department scope means you see only cases that include your department. Org-wide scope means you see everything — the Lead and the Final Approver are org-wide. Within a shared multi-department case, documents are further scoped to the department that owns them. And one warning worth engraving: permissions are enforced by the server, not the screen. A button you can't use is hidden, but the system re-checks your role on every single action. Recap. Your instance runs one regime — here it's OIA; only the wording differs from LGOIMA. Grounds come in three kinds: conclusive, public-interest-tested, and refusal. Detections start pending, and a person decides each one. Documents move from Ready for Review through to Signed Off — and frozen. Five roles, and only the Final Approver or the Lead can give final sign-off. Next time we put this to work: logging a new request, uploading documents, and watching the processing pipeline run. That's episode three.

Welcome back. Today we take a request from arrival to Ready for Review. A request has come in to the Ministry of DataSing, and as the Lead, it's our job to log it. Remember — only the Lead can create a case. Click New Case in the navigation. This is Log a new request. You enter what you know: a request summary — what's actually being asked for; the requester's name and type; the date the request was received; a priority; and the department or departments that hold the information. You can tag more than one department — the case is then shared, and each department sees its own documents. Take care with the date received: the statutory clock starts from it. Now look at what Veil does for you. The reference and the statutory deadline are assigned automatically — neither can be edited here. On this instance the deadline is calculated under section 15 of the OIA: twenty working days. On a council instance you'd see section 12 of LGOIMA cited instead — same twenty working days. If a request genuinely needs more time, the Lead can formally extend the deadline later, with a reason that's written to the audit trail. Press Create Case — Veil takes us to the case's workflow setup page; we'll head straight to document upload. This is Document Ingestion — the case's upload screen. Drag and drop files or folders here, or click to browse. We'll drop in a PDF and a Word document. The moment they land, Veil starts work. If your instance is connected to Microsoft 365, there's also an Import from SharePoint option here — same pipeline, same rules. What can you upload? PDF, Word, Excel, and PowerPoint. Plain text. And email — EML or MSG files — where each email's attachments become their own child documents, so nothing hides inside a message. Watch the EML land: the attachment gets its own row. Three hard limits to remember. First: PST email archives and ZIP folders are not supported — a ZIP is rejected at upload. Export emails as EML or MSG, or unzip the folder, and upload the files individually. Second: standalone image files are rejected too — scanned material must arrive as a PDF, which is read through OCR as normal. Third: audio and video files are not screened in a standard deployment. They may upload, but Veil does not transcribe, detect, or redact them — never treat a media file as reviewed or safe to release. And one more: a zip attached to an email is not screened — it lands as its own child document marked Error, telling you it must be handled manually. Extract it and upload the files individually. Now the pipeline runs, live. Each document is validated and converted, then its text is extracted — PDFs, including scanned ones, go through OCR. Then detection, in layers. Pattern detection finds structured New Zealand personal identifiers — phone numbers, emails, IRD numbers, addresses, bank accounts, passports — at high confidence, and it always runs. On top of that, AI detection reads for context: names, legal privilege, free-and-frank opinions, commercial sensitivity — each with a suggested withholding ground. The AI layer is a configured cloud feature; if it's ever unavailable, documents still complete on pattern detection alone — but names and contextual sensitivities are not detected, so review with extra care. Everything the pipeline finds becomes a pending detection, waiting for a person. One nice safety net: re-upload the same file and Veil shows this amber Duplicate warning. It's non-blocking — the file is still added — so it's on you to remove it if it really is a duplicate, like this. And if something goes wrong: a clearly corrupted file is refused at upload with a red error message, while files that fail later — a password-protected PDF, a service timeout — show Error with a plain-English reason. Fix the file, or just re-upload; timeouts often clear on a retry. And we're done. Every document now reads Ready for Review — text extracted, detections found and stored, all of them pending. That entire pipeline ran against live services; nothing here is simulated. Press Continue to Review, and the case is ready for the review team. That's exactly where episode four picks up. Recap. The Lead logs the request on Log a new request; Veil assigns the reference and the section 15 deadline automatically. Upload on Document Ingestion — PDFs, Office files, text, and EML or MSG email, but never PST archives, ZIPs, or standalone images, and in standard deployments media files are not screened. The pipeline extracts text, runs pattern detection always, and AI detection when configured. When a document reads Ready for Review, every detection is pending and waiting for a human decision. Next time, the heart of the job: reviewing documents — deciding detections, assigning grounds, and signing off. See you in episode four.

Welcome back. Our documents are processed, the detections are waiting, and this is where the real work happens. Open a document from the case and watch the badge: Ready for Review becomes In Review the moment we're in. This screen is the Document Review split view — and it's about to become very familiar. The layout is simple. Your document on the left. The Detections panel on the right — every piece of content Veil flagged, as cards. You can filter the panel: All Detections, Personal, Commercial, or Other. Click a card and the document jumps to that spot, so you always see a detection in its context. Your job: give every card a decision. Look inside a card before deciding. There's the flagged text, its type, and a confidence score. AI detections also carry an AI Explanation — why the model flagged it — a Public Interest Consideration where the ground demands one, and a Suggested ground you're free to change. Change History records everything done to this detection. Read the reasoning; don't just trust the highlight. Two buttons, one decision. Redact withholds the content — this name is personal information, so we redact it, and the card now reads redacted. Don't redact — keep visible releases it: this detail is plainly releasable, so we keep it, and the card reads kept visible. Nothing here is automatic. Every detection started pending — to decide — and stays that way until you or a colleague acts. Decisions aren't final yet either; you can revisit any card until the document is signed off and frozen. Toggle the preview from Original to Redacted and you see the document as the requester would. Our redacted name is now covered. But hear this clearly: this preview is visual only. It covers content on screen — the underlying text is still present in the app. Permanent redaction happens later, at export, when accepted redactions are burned in and the text is destroyed, not hidden. Until then, treat the document as containing everything. On a long document, the routine detections add up — names, phone numbers, bank accounts the patterns caught at high confidence. Accept all at or above ninety per cent clears them in one action. Watch: the high-confidence cards are decided in bulk, and everything below the line stays put for hand review. It's a time-saver, not a shortcut — you remain responsible for what it accepted, and each one can still be reversed individually. And the review-required types? This button never touches them — they stay pending, and Veil tells you how many require manual review. Those cards are yours to decide individually. The AI misses things — that's why you're here. This nickname refers to an identifiable person, but no pattern matched it. Select the text in the document, and Veil offers to add a manual detection. Choose the type, confirm, and it appears as a card like any other — except this one records you as its source. Anything a human eye catches gets the same treatment, the same grounds, and the same audit trail as an AI detection. Sometimes the AI flags the right text for the wrong reason. This detection is really personal information, not commercial. Click Change type and correct it. The type matters, because it drives the suggested withholding ground — and the change lands in the card's Change History, so the correction itself is on the record. Every redacted detection needs a withholding ground before the case can export. Veil pre-fills a suggested ground for most types, and this picker is where you confirm or change it. It's grouped by section, and it's regime-aware: here we see Section 9 — public interest test required — because this is an OIA instance. On a council instance the same group reads Section 7. Section 6, conclusive, is identical in both. We'll take privacy — section 9, subsection 2(a) — and add a short reviewer note explaining why. That note appears in the withholding schedule, so write it for the requester and the Ombudsman, not just for yourself. Some detection types carry a review-required flag — legal privilege, safety concerns, law enforcement. These are the calls with real consequences, so Veil demands extra scrutiny: the case-wide sweeps on the Bulk review page exclude them entirely. Slow down here. Read the AI Explanation, weigh the Public Interest Consideration, and decide it individually. If you're not certain, that's what your senior reviewer is for — leave a note and escalate rather than guess. Every card is decided, every redaction has its ground — time to hand the document on. Press Sign Off, confirm with Submit, and the document becomes Reviewed, Initial. It now waits for senior review and final approval; the toolbar will read Signed Off — Awaiting Final Approval once the final decision is pending. Two things to know. If you sign off with detections still undecided, they're escalated for a senior decision — best practice is to decide everything first. And a senior reviewer can send the document back to In Review with Request Changes if something needs another pass. Only after Final Approval is it frozen for good. Recap. The split view: document left, Detections right — every card gets Redact or Don't redact, keep visible. The Original-Redacted preview is visual only; permanent redaction happens at export. Bulk-accept the high-confidence routine work, add manual detections for what the AI missed, and give review-required types your full attention. Assign a ground to every redaction — Section 9 here, Section 7 on a council instance — then Sign Off to Reviewed, Initial. Your document is now reviewed — but it isn't released yet. In the next episode, we follow it through the approval chain: senior review, send-backs, final approval, and the case attestation. And remember: the AI suggests, you decide.

Welcome back to Veil training. In the last episode a reviewer decided every detection and signed the document off. But one reviewer's decision is not a release. In this episode we follow the approval chain: senior review, final approval, and the case-level attestation. On screen is our case at the Ministry of DataSing. This document is at Reviewed, Initial. That means the reviewer has finished, and it is now waiting for senior eyes. A senior reviewer opens the document and checks the work. Are the right things redacted? Does each redaction carry the correct withholding ground? Here the grounds cite the OIA — section nine, two, a, for privacy, for example. On an LGOIMA instance the same ground appears as section seven, two, a. The senior reviewer can review decisions and make disclosure calls, but note one thing they cannot do: give final sign-off. We will come back to that. Suppose something is wrong. A name has been kept visible that should be withheld. The senior reviewer presses Request Changes, adds a short reason, and presses Send Back. Watch the status: the document returns to In Review. It goes straight back to the assigned reviewer, with the reason attached. Nothing is lost — every decision they made is still there. They fix the problem and sign off again. The reviewer redacts the missed name and signs off once more. The toolbar now reads Signed Off, Awaiting Final Approval. This is the hand-off point. And here is the rule that matters: a Senior Reviewer reviews and can send back, but cannot give final sign-off. Final sign-off belongs to a Final Approver, or to the OIA Lead. On an LGOIMA instance that Lead role is labelled LGOIMA Lead — same role, different wording. Now the Final Approver takes over. They open the document, satisfy themselves it is right, and press Final Approval. Veil asks them to confirm. Confirm Approval is a deliberate second step, because what happens next is significant. The document becomes Signed Off — and it is frozen. Frozen means the redaction set is locked. Detections are locked after final approval — you can no longer redact, un-redact, or change a ground on this document. If anything is wrong, it must be sent back for changes before final sign-off, not after. This is the safeguard that makes the approval meaningful: what was approved is exactly what will be exported. Documents are approved one by one, but the case needs its own sign-off. On the Finalise and Close screen, the assigned approver completes the Final sign-off panel. They choose the Disclosure outcome: Granted in full, Granted in part, or Refused. Because we withheld some material, this one is Granted in part. Then they press Attest case complete. This attestation is the formal record that a named approver stands behind the whole disclosure — and external packages cannot be generated until it is done. One last tool ties the chain together. Veil snapshots a document's decisions at each milestone. Press Compare version snapshots, then pick a left and right version — here, Draft, Submitted for Review, against Final, Signed Off. Every detection is marked Added, Removed, Modified, or Unchanged. The left and right ground columns make a changed statutory ground stand out immediately. The summary pills filter the table, so an approver can answer, in seconds, exactly what changed between the reviewer's draft and the version that was approved. Snapshots are created automatically at draft sign-off and final approval — before then you will simply see No Snapshots Available. Let's recap. Send Back returns a document to In Review, with a reason, and nothing is lost. Final sign-off belongs to a Final Approver or the Lead — a Senior Reviewer cannot give it. Confirm Approval freezes the document: detections are locked from then on. And the case-level attestation, with its disclosure outcome, is what unlocks external export. Fix problems before the freeze, not after. Next time: the three export packages — what each one contains, who can produce them, and how Veil verifies your redactions are permanent before anything leaves the building. See you in episode six.

Welcome back. Our case is attested and every document is signed off. Now comes the step that actually leaves the building — and the step with the least room for error. This is the Finalise and Close screen. It handles export, release, and closure in one place. First, Document Readiness: only documents marked Signed off, ready to export, will export cleanly. Anything else shows why — Not Signed Off, Missing Grounds, or Review Incomplete. Veil produces exactly three packages, each for a different audience. The Requester Package is what you send to the person who made the request. The Internal Package, marked Recommended, is for your own records. And the Ombudsman Package is the full disclosure file for an Ombudsman review. The audience determines the contents — so choosing the right card matters more than anything else on this screen. The Requester Package is deliberately screened. Its withholding schedule omits the withheld-text column and reviewer reasoning — because the schedule itself could leak the very content you withheld. Filenames are anonymised to Document underscore zero zero one, zero zero two, and so on, because a filename can itself be personal information. And the verification report, which quotes withheld text, is excluded entirely. Redacted PDFs, schedule, covering letter — that is what the requester gets, and nothing more. The Internal Package adds what the requester must never see: the audit trail, the chain of custody, the verification report, and the schedule with full reasoning. The Ombudsman Package goes one step further — it contains the original, unredacted documents. Read that again. Unredacted originals. It exists so the Ombudsman can compare what you withheld against what you released. Never send the Ombudsman or Internal package to a requester. Only the Requester Package is screened for external release. Who can produce each package is gated by role, and the same check applies to download. A Reviewer can produce the Requester Package. Internal needs Senior Reviewer or above. Ombudsman needs a Final Approver or the Lead. Here, signed in as a Reviewer, the restricted cards are disabled: your role cannot emit this package type. And the Administrator cannot generate any package at all — remember, permissions are enforced by the server, not the screen. The Lead selects the documents, picks the Requester Package, and checks the export options — including the covering letter and the right-of-review statement. On this OIA instance the review right cites section twenty-eight, three; under LGOIMA it is section twenty-seven, three. Then: Generate Export Package. This is the moment Veil burns the redactions into the output — permanently — and then verifies them. You will see Verifying redactions are permanent. That check is not decorative. It re-inspects every output file for leaked content. And when verification is not satisfied, Veil fails closed. Here is a case where a document could not be verified clean. The export shows Export Failed, with the reason — and nothing is assembled or downloadable. This happens if a leak is found, and just as importantly, if the verifier could not run. Couldn't verify is not clean. Fix the flagged documents and regenerate. Never override or work around a block to force a release. Internal packages still generate, but each document's true status — passed, leak found, unverified, or exception — is shown honestly. Back on our healthy case, verification passes and the package is ready. Download Package saves the ZIP, and Veil displays a SHA-256 integrity hash alongside it. Record that hash. It lets you prove, later, that the file you sent is byte-for-byte the file Veil produced. The package you've just generated appears under Export History with its hash — and every export is permanently recorded in the case's immutable audit trail with its SHA-256, so there is always a record of exactly what was built, and when. Sending a package back to SharePoint is coming soon — it is not yet available on the current release, so download the package and file it according to your records process. One rule will be permanent by design: the Ombudsman package will never go to SharePoint, because it contains the unredacted originals. Download the package instead. Once the response has actually gone to the requester, the Lead presses Mark as released, under Release for disclosure. Pause before you click. This freezes the case and every document in it, and stamps the disclosure date. It is terminal — there is no un-release. Be certain the package you generated and checked is the one you disclosed. The case now reads Released for disclosure. Finally, Close and archive ends the case with a closure outcome. If something comes back — an Ombudsman complaint, say — the Lead can Reopen case later. And not every case gets this far: the administrative early-close outcomes, Withdrawn, Transferred, and No information held, close a case without a release. To recap. Three packages, three audiences — and only the Requester Package is screened for external release. The Ombudsman package contains unredacted originals; it never leaves the organisation except to the Ombudsman, and never via SharePoint. Export burns redactions in and verifies them, failing closed: a block is a stop sign, not an obstacle. And Mark as released is terminal — check twice, click once. Next time: working at scale. Bulk actions, cross-document redaction, custom detection rules, and extending a statutory deadline — the tools for the two-hundred-document request. See you in episode seven.

Welcome back. So far we've worked one document at a time. That breaks down at scale — a big request can run to hundreds of documents. This episode covers Veil's tools for exactly that. We're on the case's Documents tab. Filter with the search box, tick the checkboxes — or Select all documents — and a bulk-action bar appears. The core bulk actions — assign, sign off, exclude — authorise each selected document independently and reject the whole selection if anything is out of reach, so nothing is ever silently trimmed. First, Assign Reviewer. The Lead selects a batch and assigns it to one person by email — this is how a two-hundred-document case gets divided among a team in minutes. Remember from episode two: the Review Workflow Setup screen configures the stages; this is the tool that assigns actual documents to actual people. Sign Off Selected gives final sign-off to several reviewed documents together — Final Approver or Lead only. Treat it with respect. It freezes every selected document at once: the same irreversible lock as a single final approval, multiplied. Once frozen, a document's redactions can no longer be changed. Confirm each document is genuinely correct before you include it — bulk convenience is not an excuse for bulk carelessness. Three more tools on this bar. Mark Excluded takes the selected documents out of the release — for material that turned out to be out of scope. Re-run detection, with an optional context override, re-processes the selection — useful when you can tell the pipeline something it didn't know, like a project codename. And Delete permanently removes documents from the case — that one is Lead only, and it means permanently. Now the heart of working at scale: the Bulk review page, opened with Bulk Review from the Documents tab. Its promise is written under the title: apply one redaction decision across many documents at once, highest-reach detections first. A chip shows the scope you're reviewing, a meter tracks how many detections are cleared case-wide, and the work is organised into three numbered steps. Sweep what the AI is most sure about. Clear the structured identifiers. Then decide each repeated entity once. We'll take them in order. Step one is the biggest lever here — Lead or Senior Reviewer only. Set the confidence threshold, and three tiles preview the effect live: how many detections auto-accept, how many are held for manual review, and how many documents are affected. Before committing, show the detections this will redact — the black bar is the literal released result, listed closest to the threshold first, and you can untick any one to keep it visible. Press auto-accept, and it's done — each detection keeps its own suggested ground and the withholding schedule updates. And note the banner: review these, or undo this batch. Bulk is fast; it is not final. Step two clears the routine identifiers — Senior Reviewer and above. A phone number is a phone number: the decision doesn't depend on whose it is, so one press redacts every pending phone number in the case, each under its suggested ground. The same goes for email addresses, IRD numbers, addresses, bank accounts, passports, and NHI numbers. Notice what is not offered here: names, commercial information, and legal grounds. Those depend on who and why — so they go to step three. Step three is the spine: review by reach. Veil groups repeated values into entity groups, most-repeated first — this person's name appears eleven times across four documents, and you decide about the person once, not eleven times. Each card shows the released result, with the ground it would be withheld under — on this OIA instance that's section nine, two, a for a name; under LGOIMA it would read section seven, two, a. Three moves. Hide everywhere accepts the group case-wide — Senior Reviewer and above. Look first opens the document, for when context matters. And Not sensitive keeps the value visible. Every decision here is audited, and reversible with Change until sign-off. And a deliberate limit. Some detection types — legal privilege, safety concerns, law enforcement — are flagged review required, and this page never sweeps them. Step one holds them back: legal advice and safety grounds are never swept, and the tile counts them as held for manual review. Step two never offers them. And in step three, their card says it plainly — this needs a closer look — and routes you to review each occurrence individually. Those judgements are exactly the ones that must stay with a person, one document at a time. Detection scales as well. Custom Rules teaches Veil agency-specific things to look for — keywords, patterns, and entities, mapped to withholding grounds, running alongside the AI. New rule opens the editor. Give it a name; pick a type — keyword, pattern, entity, or combination; and a match mode — exact, fuzzy, or regular expression. Here we add our internal codename, Project Kererū, mapped to a withholding ground with a priority. From now on, every document processed in any case gets checked for it. Two things to understand about rules. First, Draft versus Active: Save as Draft parks a rule — drafts are saved but never match documents; only Active rules run. The per-row switch flips between the two. Second, and more important: these are detection rules, not redaction rules. Rules supplement the AI — they never override a reviewer. A match becomes an ordinary pending detection for a person to accept or reject. Nothing gets redacted because a rule fired. Import and Export move whole rule sets in and out as JSON. One scale tool you won't see on this instance. Under LGOIMA — local government — a document can be withheld in full under the public-excluded mechanism, section forty-eight. On the Documents tab of an LGOIMA instance, Mark as PE flags selected documents, and the review screen offers Apply withhold in full — no per-span review, no partial release. It's reversible while the document is in review, and locked once signed off. The OIA has no equivalent, so on this central-government instance the feature is hidden entirely. Finally, time itself. When a request genuinely needs longer — substantial collation, consultations — the Lead can formally extend the statutory deadline. Extend deadline shows the current deadline and the maximum extension date, both read-only. Enter the new deadline and a mandatory reason for extension; the reason is written to the audit trail. The new date can't exceed your agency's maximum, and the guidance in the reason field is regime-aware — the extension provisions differ between the OIA and LGOIMA. An extension moves the existing deadline; it does not restart the clock. Recap time. The Documents-tab bulk bar divides, signs off, excludes, re-runs, and deletes in batches — and Sign Off Selected freezes everything it touches, so check first. The Bulk review page works highest-reach first: preview and sweep the high-confidence routine, clear structured PII in one press, and decide each repeated entity once — with undo this batch behind every sweep. Review-required types are never swept — by design. And custom rules detect, but only people redact. Next time, the final episode: safety and governance. Why redaction is permanent, why the system fails closed, the immutable audit trail, and the reports that prove your compliance. See you in episode eight.

Welcome to the final episode. Everything in this series rests on a handful of safety properties, and they deserve six minutes of your full attention. Start with the one people misunderstand most. This is the review screen's preview toggle. Redacted here is a visual preview only — it covers content on screen, but the real document still contains every word. Nothing is removed at review time. Export is where redaction becomes real. When a package is generated, accepted redactions are burned into the output and flattened. The underlying text, and any covered images, are destroyed — not hidden under a black box. Watch: searching this exported PDF for the withheld name finds nothing, because the file no longer contains it. Hidden surfaces go too — form data, embedded files, metadata. And that is why there is no undo after export. If a redaction is wrong, fix it before final sign-off, in the app — never by editing an exported file. Second property: the system fails closed. Every external export runs the verifier — you saw Verifying redactions are permanent in episode six. A Requester or Ombudsman package is blocked if that check finds a leak, or if it cannot run at all. Couldn't verify is not clean. The Export Failed card is a stop sign, not an obstacle: fix the flagged documents and regenerate. There is no legitimate reason to work around it, and internal packages always show each document's true status — passed, leak found, unverified, or exception — never relabelled. Third: withheld content can escape through more than the PDFs. A withholding schedule that quotes withheld text. A filename that names a complainant. A verification report that lists what it checked. These are all leak channels, and Veil screens the Requester Package against every one of them — no withheld-text column, no reviewer reasoning, anonymised filenames, no verification report. The corollary: the Internal and Ombudsman packages do contain withheld content. Treat them accordingly, and keep them internal. Fourth: the originals never go away. Veil retains the unredacted documents for the audit trail and for the Ombudsman package — that is deliberate, and it's what makes an Ombudsman review possible. But they must never be sent to the requester. Before anything leaves your agency, double-check you are holding the Requester Package. One habit, applied every time. Fifth: people. Two reviewers editing the same document can clash, and Veil protects against silent overwrites. If someone else is editing, you'll see: this document is read-only — another reviewer is editing it. If the document changed underneath you, Veil tells you it was changed by another reviewer and reloads the latest — your stale change is not saved, so re-check your work after that message. And if a lock is held by someone who has stepped away, a Lead can Take over editing. Heed these messages; they exist so that no decision is ever lost silently. Now the evidence. Every case has an Audit Trail tab — the immutable audit log. Entries cannot be modified or deleted, by anyone. Every action is recorded with its user, role, target, and timestamp — and AI actions are logged right alongside human ones. This is what makes a disclosure defensible: not that nothing went wrong, but that you can show exactly who decided what, and when. Search it, filter it by type, and export it as CSV or PDF when the Ombudsman asks. The Reports screen turns that record into statutory paperwork — available to case roles, not the Administrator. The Compliance Summary — labelled OIA here, LGOIMA on a local-government instance — gives statutory performance for a period, ready for a Te Kawa Mataaho return. The Withholding Schedule lists every redaction with its ground, ready to attach to a response letter. Chain of Custody is the full decision trail for a case, Ombudsman-ready. And Cost Recovery estimates time and charges for substantial-collation requests. Pick a card, press Run, choose a case where prompted, and Generate PDF. Finally: is the AI actually any good? AI Governance is the single source for accuracy metrics. Detection accuracy over a rolling thirty days: precision, false positive rate, and how many detections people have reviewed — broken down by category and entity type. Human overrides show how often reviewers disagreed with the AI, and the miss analysis shows what people caught that the AI missed — the honest column. Model information tells you exactly which model is running. Until ten AI detections have been reviewed, you'll see Insufficient Review Data instead — Veil won't show you statistics it can't stand behind. AI assists; humans decide; and this page is where you check the AI is earning its place. That's the series. Four things to carry with you. Redaction is only permanent at export — the preview is visual, the exported file is final. The system fails closed, and a block is never bypassed. Every artefact is a leak channel — only the Requester Package is screened for release. And the audit trail is immutable — work as if everything is on the record, because it is. If you need help: your Lead owns case and workflow questions; your administrator owns configuration, single sign-on, and cloud services like OCR; and the in-app user guide covers every screen in this series. Thanks for watching — now go release something, safely.