RDT26 — controlled selective reversal.
Reversible Data Transformation is the exception path. When — and only when — a specifically identified record needs lawful re-identification, RDT26 reveals a single element under key management. Bulk, batch, and stream reversal are blocked by design.
Four properties that make the reversal safe to authorise.
RDT26 is deliberately not a general-purpose unmasking tool. Its properties are chosen so that an authorising officer can grant a reversal without worrying about lateral scope, and so that the reversal itself is auditable, single-record, and single-field.
Reversal requires the original NPDL26 seed algorithm.
Because NPDL26 transformation is deterministic and seeded, reversal is impossible without the original seed. There is no path from a transformed dataset back to its source values outside the RDT26 governance path.
The bulk pipeline is blocked.
RDT26 explicitly refuses bulk, batch, or stream operations. There is no configuration option to re-identify a table or a set. The design ensures reversal cannot silently scale.
A specifically identified record, from within a group.
Within a group of anonymised records, one individually identified record can be highlighted for follow-up. The surrounding population remains protected. Every selection is logged.
One field revealed per pass; remaining fields stay protected.
A single reversal reveals a single element of a single record — for example, an account number under investigation. Other fields on the same record and the wider dataset remain protected. Multiple elements require multiple, separately authorised passes.
RDT26 is invoked only after NPDL26 has already applied protection. It is not a fallback for cases where NPDL26 was not applied — it is the governed exception path for cases where a protected record needs to be re-identified under authority.
Where lawful re-identification is the correct answer.
RDT26 is designed for the small number of workflows where re-identifying one record, once, is genuinely the right decision under law and policy. Common scenarios include:
- Fraud investigation — identifying an account under a formal internal or external investigation.
- Incident response — contacting an affected individual as part of a documented response process.
- Regulator disclosure — producing a specific record in response to a compulsory request.
- Analytics follow-up — where a single anomalous record needs to be tied back for investigation, with the surrounding population left protected.
In every case, the workflow is: identify the specific record, authorise the reversal, reveal one element, log the operation. There is no batch mode. That is the point.