On-chain and off-chain data

DigiFIR keeps data in four places, and each piece of data goes to the narrowest one that still lets the system work.

Place	Who can read it	What kind of data
Shared ledger (public world state and blocks)	Every peer of every member institution	IDs, numbers, statuses, versions, links, times, hashes and salted commitments
Private data collections	Peers of the member institutions of that collection only. Other peers hold only a hash.	Narratives, personal details, statements, diary text, file keys, reports, reasons
Object storage, off the chain	Nobody can read it without the key, which sits in a private collection	Encrypted files and documents
Backend database, off the chain	The backend, behind role and jurisdiction checks	Read views of shared-ledger data, sessions, rosters, notifications, the encrypted identity vault

The Aadhaar number, VID, e-KYC XML and biometrics are stored in none of these places.

Data by type

Data	Shared ledger	Private collection	Off the chain	Backend database
Complaint and FIR control data: IDs, numbers, status, versions, station, BNS sections, times, links	Yes			Read view
Narrative; complainant, victim and accused details	Salted hash	Value, in the state's collection		Never
Statements and case diary text	Hash	Value, in the state's collection		Never
Attachments and evidence files	Plain and ciphertext SHA-256, size, media type	File key in the state's collection; a copy of the key in the state's laboratory collection when the exhibit goes to a laboratory	Ciphertext in object storage	File index
Custody hops	Yes: who, to whom, where, why, and both signatures			Read view
Seizure memo	Hash	Value, in the state's collection (laboratory cannot read it)		Never
Laboratory working notes	Hash	Value, in forensics_private		Never
Sealed laboratory report	Hash, sealer, time	Report text, in the state's laboratory collection	PDF ciphertext	Read view without content
Court orders	Type, outcome, order hash	Reasons, in the state's collection; draft notes in judiciary_private	Signed order PDF	Read view
Citizen identity	DID, public keys, KYC method and assurance level			Contact details for notifications, consented and encrypted, in the identity vault
Officials	Key ID, public key, roles, designation, jurisdiction, validity			Names, in the backend's directory
Push tokens, sessions, rate limits, rosters, leave				Yes
Aadhaar number, VID, biometrics, e-KYC XML	Never	Never	Never	Never

Every private value is salted before it is hashed, so a hash on the shared ledger cannot be reversed by guessing likely values. Keys of ledger records never contain personal data.

Private data collections

Each chaincode that holds private data has its own collections. All of them keep values until a governed erasure (blockToLive is 0), and only member institutions can read or write them through the chaincode.

Collection	Chaincodes	Members	A write needs	What it holds
stateA_private, stateB_private	fir-registry, evidence-custody, judicial-actions	That state's police and the judiciary	The state's peer and the judiciary's peer	Narratives, people, statements, diary, attachment keys (fir-registry); seizure memos and evidence keys (evidence-custody); court reasons and police replies to status requests (judicial-actions)
stateA_lab, stateB_lab	evidence-custody	That state's police, the forensic laboratories and the judiciary	The laboratories' peer and the state's peer	Forwarding letters, escrowed evidence keys, sealed report text
forensics_private	evidence-custody	Forensic laboratories only	The laboratories' peer	Laboratory working notes
judiciary_private	judicial-actions	Judiciary only	The judiciary's peer	Court working notes

The judiciary is a member of every state collection because a magistrate deciding a probable duplicate must read the narratives of both complaints, which can be in different states. A new state adds its own stateC_private and stateC_lab collections; the existing ones do not change.

Erasure

Nothing on the shared ledger is ever deleted. When personal data must go, DigiFIR purges the private value and keeps the proof that it existed, a rule summed up as "destroy the key, keep the proof".

1. A magistrate records a court erasure order (court.erasure_order), or a statutory erasure rule applies. Rules live in on-ledger configuration and are empty until added after legal review.
2. The registrar of the institution that owns the data signs erasure.execute, naming the keys to purge. The chaincode checks that the order or rule covers each key.
3. The chaincode calls Fabric's PurgePrivateData. The value disappears from the collection's state and history on every member peer. Its hash stays in the block, and an erasure marker records the hash, the action and the time.
4. Reads of a purged value then answer erased with the erasure action's ID.
5. When every copy of a file's key has been purged, the backend marks the file erased and downloads answer 410 Gone. The ciphertext can then be deleted under the operator's retention policy.
6. Operators compact CouchDB afterwards (network.sh compact) so no old revision of a purged value remains on disk.

WARNING

A citizen's request alone never erases case data. Section 17(1)(c) of the Digital Personal Data Protection Act, 2023 exempts processing for the prevention, detection, investigation or prosecution of offences, and destroying evidence without a court order may itself be an offence. When a citizen deletes their account, the backend erases the off-chain account data and leaves the ledger untouched.

What stays after an erasure: every public record and its history, every private-data hash, file hashes, custody chains with both signatures, documents registered for verification, the erasure records and the order or rule that authorised them.

Sources: digifir-backend docs/architecture/ARCHITECTURE.md section 4, DECISIONS.md ADR-12 and ADR-13; digifir-chaincode docs/SPEC.md sections 1.4, 6 and 8; digifir-network docs/OPERATIONS.md.