ITA-Maskit · Junshu Sha

What it solves

Audit material often combines tables, JSON, email, PDF, and Word, where manual processing can miss sensitive values and break the relationship between the same person or employee identifier across files. ITA-Maskit connects rule selection, hit preview, local processing, and versioned audit records so that necessary joins survive while source values leave the original files.

Core capabilities

Select rules and batch-process files through the CLI or Windows GUI
Process tables, JSON, email, PDF, and Word locally
Preview rule matches and sample changes before writing output
Choose masking or deterministic pseudonymization
Use personnel lists to improve name and employee-ID matching
Inspect statistics, output locations, and versioned audit logs

How it works

Select files, a rule set, and optional personnel data
Preview matches without writing output
Execute masking or deterministic pseudonymization locally
Inspect statistics, output paths, and the audit log

Users select files, rule sets, and personnel lists through the CLI or Windows GUI. The workbench previews rule matches and sample changes before it writes anything, then processes the batch locally; statistics, output locations, and versioned audit logs stay within the same processing boundary.

Project highlights

Cover tables and documents with two processing engines

The column-based table engine applies rules at field boundaries for tabular data, while the full-text document engine scans JSON, email, PDF, Word, and similar material. Both paths run locally and reuse the same preview and rule decision, keeping cross-format audit batches inspectable.

ITA-Maskit rule preview showing files, rule matches, and pending processing statistics — The preview screen puts files, rule matches, and sample changes before formal writing; the image comes from the repository and uses scripted demonstration data.

Turn masking policy into maintainable data

YAML stores field mappings, match strategies, masking templates, and pseudonymization templates while rule versions remain separate from processing code. A business-policy change updates validated data configuration; preview and formal execution reuse that same version to reduce rule drift.

Preserve cross-file joins without exposing source values

Inputs are normalized according to field strategy before a user-supplied pepper participates in domain-separated HMAC. The same normalized value therefore receives a stable deterministic alias across files, while personnel lists can improve name and employee-ID matching; source values are not exposed as aliases, and the pepper remains runtime configuration.

ITA-Maskit rule management screen showing YAML rule sets and field strategies — The rule-management screen shows YAML rule versions, field strategies, and the rule-set entry point; the image comes from the repository and uses scripted demonstration data.

System architecture

ITA-Maskit architecture: the CLI and Windows GUI validate rules, route files through table and text engines, mask or pseudonymize values, and emit statistics and audit logs — The diagram separates rule decisions, format engines, pseudonymization configuration, and output records; the user-supplied pepper enters pseudonymization as configuration rather than stored data.

The same rule version drives preview first, then routes files through the column-based table engine or full-text document engine. Masking or deterministic pseudonymization produces the output, statistics, and versioned audit log locally, without sending audit material to an external service.

Project scope

This is a local audit-material processing tool, not a claim of certification or a replacement for deployment-level access control, key management, or encrypted storage; screenshots use scripted demonstration data from the repository. Deterministic pseudonymization is not encryption, and image OCR and layout-preserving PDF masking remain beta.