Data Retention & Processing Policy
Principle: Unknown Verdict is built on the doctrine of data minimisation. The retrieval engine processes query text in memory and does not persist it beyond the PII-redacted audit entry. There is no user account system. There is no session tracking. There is no query history.
1. What data is processed
| Data | Where it lives | How long |
|---|---|---|
| Query text (original) | Process memory only | Milliseconds — discarded after response |
| Query text (PII-redacted) | Hash-chained audit ledger (JSONL file) | Until manually purged |
| Request ID | Audit ledger + response body | Same as above |
| Retrieval strategy, chunk count | Audit ledger | Same as above |
| Retrieved chunk text | Not stored | — |
| Response payload | Not stored | — |
| Client IP address | Not logged by application | — |
| Cookies, session IDs | None | — |
| Analytics, telemetry | None | — |
2. PII redaction
Before any query text is written to the audit ledger, it passes through a redaction module that detects and removes the following Indian personal identifiers:
- Aadhaar number — 12 digits, optionally grouped
- PAN — 5 letters, 4 digits, 1 letter
- GSTIN — 15-character Goods & Services Tax Identification Number
- IFSC — 11-character bank branch code
- CNR — Case Number Record, 16-character alphanumeric
- Email address — standard format
- Phone number — Indian mobile formats with or without country code
- Bank account number — 10 to 18 digits when preceded by a context keyword
Redacted fields are replaced with the token [REDACTED:TYPE]. The original value is not retained anywhere.
3. Audit ledger
Every retrieval produces one entry in the audit ledger. Each entry contains:
- A sequential number
- A UTC timestamp
- The event type (
retrieve,error, etc.) - The redacted query and retrieval metadata
- The hash of the previous entry (
prev_hash) - The hash of this entry (
hash)
The ledger is hash-chained: each entry's prev_hash is the SHA-256 of the previous entry's canonical JSON. Any modification to any historical entry breaks the chain and is detectable by the /admin/audit/verify endpoint.
4. Why we retain the redacted ledger
The ledger is retained for two purposes:
- Reproducibility. If a user reports that a specific retrieval returned an unexpected result, the ledger allows the operator to reconstruct what happened without needing to reproduce the query on live data.
- Compliance. Regulators may ask whether the platform can demonstrate that it processes queries without retaining PII. The hash-chain is the answer: it proves the log has not been tampered with, and the entries themselves are PII-free.
5. What we do not retain
- The original (un-redacted) query text — discarded after the response is generated.
- The retrieved chunk text — returned to the user but not written to disk.
- The full response payload — not stored.
- Your IP address — not logged at the application layer.
- Your browser fingerprint, screen size, language preferences — not collected.
- Cookies — none set by the retrieval interface.
6. Deletion requests
If you wish to have your redacted query entries removed from the audit ledger, email upmanyu@advocacyalawfrim.in with the request ID (visible in the response payload of the query in question). We will remove the entry and re-chain the ledger to preserve integrity. Response time: within 30 days.
Note: because the ledger entries do not contain PII, a deletion request will typically not reveal any personal information. The request is honoured as a matter of policy, not as a technical necessity.
7. On-premise deployments
Unknown Verdict is designed to be runnable on client-controlled infrastructure. When deployed on-premise, the audit ledger is written to the client's own storage. The operator of Unknown Verdict (The Advocacy — A Law Firm) has no access to that ledger.
8. Contact
Data Protection contact: upmanyu@advocacyalawfrim.in
Grievance Officer: Upmanyu Kumar, Advocate — upmanyu@advocacyalawfrim.in