DataInfra RedactionEverything: a local redaction workbench for Chinese and bilingual documents

The gap RedactionEverything is aimed at: messy business files, not clean text

Most PII tooling assumes you can hand it a string. RedactionEverything assumes you cannot. The README's positioning section says the project targets a different layer of the problem than token-level detectors, naming OpenAI Privacy Filter as a high-throughput baseline for text PII and describing its own scope as Chinese and bilingual business documents, scanned PDFs, Word contracts, images, visual privacy regions, human review, batch delivery and local deployment. That is a coherent split. A token classifier answers whether a span is a name. It does not answer where that name sits on a scanned page after OCR has reflowed the layout, or whether the name is printed under a company seal that the detector could not read through. The intended user is someone with a folder of contracts, legal files, finance documents or healthcare materials, in Chinese or mixed Chinese and English, who needs masked output and cannot send the originals to a hosted API. The README states that raw files, configuration, recognition results and exported artifacts are intended to remain inside a local or intranet runtime. Everything else in the project follows from that constraint.

Two detection paths, one review surface

The architecture splits each file into a text path and a visual path. The text path runs HaS Text semantic NER by default, with regex kept only as a user-defined fallback rather than a built-in rule set. HaS Text recognizes entities from the configured NER tags, so the label vocabulary comes from the schema you select, not from a fixed internal mapping. The visual path is where the design gets specific. Images and scanned documents go through PP-StructureV3 on PP-OCRv6 engines, with an optional PaddleOCR-VL supplement, producing text blocks. HaS Text then runs over that extracted text, and the recognized values are mapped back to glyph-exact coordinates, which is what keeps a label such as 户名： outside the mask instead of blacking out the field name along with the value. Visual-semantic targets that have no text at all, faces, fingerprints, IDs, bank cards, seals, screens, QR and barcodes, signatures, are grounded by a single LocateAnything-3B service, which also accepts user-defined visual labels. A local OpenCV detector runs alongside it to recover red binding and edge seals, deduplicated against the boxes LocateAnything already produced. The README also describes a red-ink suppression pass that whitens seal ink and re-detects, recovering print that a stamp hid from the detector, giving party names under a company seal as the example. That pass is the clearest signal that the project was built against real scanned paperwork rather than a benchmark set.

Schemas are the configuration surface, and that is the honest design choice

The project is explicitly not a fixed-rule PII scanner. Detection items come from schemas, and the README lists built-in general, legal, finance and healthcare presets, with custom text and visual labels supported. The general set covers people, organizations, contact details, credentials, accounts, financial values, dates, addresses and common identifiers. The industry sets add domain-specific items. This is a reasonable place to put the extension point, because the label vocabulary is exactly what differs between a hospital record and a loan agreement, and pushing it into configuration means the NER model does not need retraining per vertical. The cost is that schema quality becomes your problem. A preset that misses a field type will silently produce no detection for it, and the README does not describe any coverage report or recall estimate per preset, so there is no way to know from the documentation how complete a given schema is for your corpus. Treat the presets as a starting vocabulary to audit against your own files, not as a guarantee.

Getting it running: what the README actually specifies

The README's quick-start section is referenced in the table of contents but the cleaned text supplied here does not include its commands, so the exact install and launch invocations cannot be confirmed from this material. What can be confirmed is the shape of the deployment. It is a Python project on the main branch with a CI workflow at .github/workflows/ci.yml and no published releases, so you are tracking the repository rather than a versioned artifact. It runs model services locally, and the README names them: HaS Text for semantic NER, PP-StructureV3 on PP-OCRv6 engines for document parsing, an optional PaddleOCR-VL supplement, and a single LocateAnything-3B visual feature service. There is a dedicated Limitations and GPU Memory section in the table of contents, which tells you the resource ceiling is a real constraint and not an afterthought. There is also a Multi-Tenant Deployment section and a User Isolation section, so the system is designed to serve more than one operator from one installation. Before you plan hardware, read those three sections in the repository directly: the GPU memory figures and the model service topology are the numbers that determine whether this runs on your machine at all.

The workflow is not just detection, and that changes the operating cost

Recognition is the first step, not the product. The feature table lists single-file processing across TXT, DOCX, PDF, scanned PDF, PNG and JPG; batch processing where you pick a schema, upload a mixed queue, run recognition, review each file and export packaged results; a task center tracking status, progress, review continuation, details and deletion, with the constraint that running tasks must be cancelled before deletion; and a processing results view covering single-file outputs, batch tree results, paginated selection and packaged downloads. The review interface exists because no detector is reliable enough on this document class to skip it. That is the right call, but it sets the real cost of adoption: somebody has to sit in front of the review surface for every batch. A tool that only flagged spans would be cheaper to run and less useful. The trade the project makes is throughput for correctness, and the README does not offer a headless mode or an auto-accept threshold that would let you skip review on low-risk files, so plan for the human time as part of the deployment.

Where it is the wrong tool

If your inputs are clean UTF-8 text, RedactionEverything is more machinery than the job needs. The OCR stack, the visual feature service and the GPU memory budget all exist to handle scans, images, layout and stamps. On plain text those components are idle cost, and a token-level detector will be faster and simpler to operate. The same applies if your documents are primarily English and Western-layout. The project's stated depth is Chinese contracts, legal files, finance and healthcare materials and mixed Chinese-English content, and the schema presets follow that. A Western-style invoice corpus is not what the presets were written for. There is a second boundary that matters more than either of those. The licence is a custom Personal Use License, and the README is unusually direct about it: individuals may use it for free for personal, non-commercial purposes, while paid work, consulting delivery, companies, institutions, government agencies, teams, hosted services, production deployments, OEM redistribution and commercial integrations require a separate commercial licence. That is not an open source licence regardless of what the repository's licence field reports. If you are evaluating this for an organisation, the evaluation itself is the thing to check first, not the model quality.

Alternatives, and the actual difference in approach

The README names OpenAI Privacy Filter as a high-throughput baseline for token-level PII detection in text. The difference is not quality, it is layer. A token-level filter takes text and returns labelled spans; it has no concept of a scanned page, a seal, a signature or a review queue, and no coordinate mapping back to a rendered document. If your pipeline already produces clean text and you only need spans, that is the shorter path. The other direction is general OCR and document-AI tooling. PaddleOCR and PP-StructureV3, which RedactionEverything itself uses for parsing, can be run directly, and so can a general visual grounding model. Building on those gives you no licence restriction from this repository and full control over the stack, at the cost of writing the schema layer, the coordinate mapping, the review interface, the batch task state and the export packaging yourself. That is the honest comparison: RedactionEverything is a bundled workflow with a restrictive licence, and the alternative is the same underlying components with the workflow left as your work. Which is cheaper depends entirely on how much of the workflow you would otherwise have to build.

Maintenance cost, licence implications and what to verify before adopting

There are no retrieved releases, so upgrades mean pulling from main. A project that tracks a moving branch and wraps several model services, HaS Text, PP-StructureV3, PaddleOCR-VL and LocateAnything-3B, has more upgrade surface than a single-library dependency: a change in any upstream model service is a change in your deployment. The repository does carry a CI workflow, which is a signal that the main branch is at least exercised, but CI passing is not a compatibility guarantee for your hardware or your document mix. On licensing, the README states that commercial deployments must clear third-party component licences on their own, and it names two: the LocateAnything-3B weights are released under an NVIDIA non-commercial license, and PyMuPDF is AGPL-3.0, dual-licensed commercially by Artifex. That matters because a commercial licence obtained from this project's maintainer would not by itself settle those two. Anyone planning paid or organisational use should read LICENSE in the repository, read the component table it points to, and confirm the terms of the visual model weights and the PDF library separately. This is a description of what the README says, not legal advice; the terms of your own use are a question for a lawyer, not for a review.

Editorial conclusion

RedactionEverything fits a single engineer or researcher redacting Chinese or bilingual business documents on their own machine, where the schema presets and the OpenCV seal recovery do work that a token-level PII detector will not. It does not fit a company, a consultancy, a government body or anyone shipping it inside a product, because the repository carries a custom Personal Use License and the README states that paid work, hosted services, production deployments and OEM redistribution all require a separate commercial licence. Before installing anything, read LICENSE in the repository and the component table it references, and confirm the LocateAnything-3B weights and the PyMuPDF dependency separately, since those two carry their own non-commercial and AGPL-3.0 terms that a commercial licence from the maintainer does not override.

Official sources

1. Issues
2. README
3. ttttccxxui/DataInfra-RedactionEverything on GitHub