Capability 3 of 4
Selective Redaction
Each recipient sees only what they are authorised to see. The record still verifies as authentic.
The problem
Redact a signed PDF and the signature dies.
- Digital signatures still prove authenticity after redaction
- Documents, files, telemetry, fields, or any other data type
- Remove the value and keep the field name, or remove the field entirely
- No individual copy or new file per recipient needed
Redacting a value should not invalidate the digital signature.NxChain keeps authenticity even after redaction.
Policy-driven
Set the policy once. New entries inherit it.
- Define reusable need-to-know policies: ally, partner, industry
- Attach a policy when a data flow is set up, internal or external
- Every entry is filtered live for that recipient, including future ones
- Multiple policies can serve the same record set, one per recipient
- Each recipient receives the same verifiable authenticity proof
Each recipient should see only what they need to know.Redaction is policy-driven and applied consistently.
The proof
The owner can prove the original values. Nobody can falsify them.
- The owner can prove exactly what sat behind each redaction
- Those values are signed. Even the owner cannot change them later
- Nobody can fill the redacted holes with forged data
- A redacted copy is enough. The full picture has to match when it is shown
After an audit or incident, the original can be reconstructed.It cannot be rewritten.
Progressive trust
Each tier can hide more. Trust can reveal it later.
- Each tier can add its own redaction, on top of what it received
- Nation, coalition, then contractor. Each tier can hide more
- Redacted parts can be revealed later, as trust grows
What this gives you
Selective Redaction
- Any data type
- Signature survives redaction
- What was redacted can be proven
- Need-to-know views
- Reusable policies
- Every entry filtered
- Reveal more later
- Each tier can hide more
Frequently asked questions
Selective Redaction questions, answered directly.
If I redact, can they still verify it is authentic?
Yes. A signed PDF becomes invalid when you put the black marker to it. An NxChain record can be redacted without invalidating the signature. You can hide a field or drop the field entirely, and the authenticity check still holds. The recipient can verify that the copy is genuine and that you are the author, and they only see what you chose to release. That is the point of a redacted share: a release-appropriate view that still proves it is authentic.
Do I prepare a new file for each recipient?
No. You keep one record. Reusable need-to-know policies (ally, partner, industry for example) attach to the flow, internal or external. NxChain filters every entry live as the record is replicated, synchronised, or queried. You do not pre-process a dataset into a stack of release copies. The same record can carry several policies, one per recipient, and later entries inherit the same rule.
Can I prove later what was redacted?
Yes. The owner of the original can prove the exact values that sat behind each redaction. Those values are signed, so even the owner cannot invent different ones afterwards. A partner who only has the redacted copy can still check that proof: a forged value in a hole fails the signature. After an audit or incident, the original can be reconstructed from what the owner proves. It cannot be rewritten.
If a partner is trusted later, can I reveal more?
Yes. Trust is not fixed at the moment of sharing. When authorisation grows, redacted parts can be revealed. Earlier bars can open. A later tier can still keep its own redaction in place. The record is not rewritten to do this; the view they are allowed to see changes.
Can a partner hide more before sharing onward?
Yes. Each tier can add further redaction on top of what it received. A nation can share a filtered view with a coalition; the coalition can hide more before a contractor sees it. The signature still holds at every hop. Hiding is not locking. When the content itself must stay secret, even in a partner’s hands, Post-Quantum Encryption is the next step: grant access later, on a need-to-know basis.