Oversight by design: why we do not score people

The problem with scoring people

A score of a person compresses weak signals, such as how often a name appears in records, who it appears next to, and where, into one number. The number then travels without its doubts. The person scored rarely knows it exists and has no way to answer it. And because the inputs often track who is policed rather than who offends, a score can quietly follow identity even when no field says religion, caste or language.

The failure is not hypothetical. In September 2026 the Internet Freedom Foundation reported that Delhi Police's facial recognition flagged 2,873 people with "criminal antecedents" at protests at Jantar Mantar, using an 80% similarity threshold, against a database with no disclosed statutory basis or retention limit. An Indian Express check of 205 of them, cited by IFF, found at least 25 were in jail when the software placed them at the protest (IFF, 4 Sep 2026). The Supreme Court has agreed to hear a plea against police use of such tools at protest sites (LiveLaw, 13 Aug 2026).

We know the pull of it. The first prototype of our own console, in May 2026, scored named people from their mentions in public records. It is being removed, and red line 1 exists so that it does not come back.

What the courts have said

• The test. Any intrusion on privacy must pass legality, a legitimate aim, proportionality and procedural safeguards (K. S. Puttaswamy v. Union of India, 2017).
• Tracking. A bail condition that lets police track every movement of an accused, by technology or otherwise, violates the right to privacy (Frank Vitus v. NCB, Supreme Court, 8 Jul 2024).
• Interception. Covert phone tapping to detect crime falls outside the public emergency and public safety conditions of the Telegraph Act; the Madras High Court quashed the order and barred use of the material (P. Kishore, Madras HC, 2025).
• Citizenship. Foreigners Tribunals may not proceed on "bald and vague allegations" (Md. Rahim Ali, Supreme Court, 11 Jul 2024), and the burden of proof "does not convert the absence of the proceedee into proof of the allegation" (Sabitri Dey, Supreme Court, 13 Jul 2026). This is why we build no tool that ranks or predicts outcomes for people in these cases.

What the law will require

The Digital Personal Data Protection Rules were notified on 13 November 2025; consent managers follow on 13 November 2026 and the core duties apply from 13 May 2027 (Hogan Lovells Cadwalader). Section 17(1)(c) lifts consent, notice and individual rights for the prevention and investigation of offences, but the duties of accountability and security in section 8 still apply (DPDP Act s.17). Failing to keep reasonable security safeguards can cost up to ₹250 crore (Schedule).

Elsewhere, the European Union's AI Act bans systems that predict whether a person will commit a crime based solely on profiling, and requires human oversight of high-risk systems (AI Act, Article 14). The UK's Data (Use and Access) Act 2025 dropped the requirement for police logs to record a justification for each consultation (s.82). We keep it: every sensitive request in our software carries a declared purpose.

How the software enforces it

1. Events, not people. Identifiable personal data of private persons is a data class the policy always denies (RL-1). Redacted records about people never leave the deploying organisation through the platform (RL-2).
2. No identity filters. A firewall rejects filters and free-text requests that select by religion, caste, tribe, ethnicity, language, surname, name origin, nationality of origin or descent, and logs each refusal (RL-4).
3. Purpose before query. Six purposes are defined. Operational ones need a ticket, such as an NDMA alert number, an FIR or an incident ID, that expires after 7 to 90 days. Public research and training see only public, aggregate, environmental or simulated data (RL-3).
4. Two keys. Searching or exporting records about people, and copying sensor tracks out, need a second, independent approver. Approvals are single-use and expire after 24 hours (TP-1, TP-2).
5. One ledger. Every action is an entry hashed with SHA-256 over canonical JSON and chained to the one before. Every 16 entries a Merkle checkpoint is written; roots published outside the system let anyone detect a rewrite. The ledger is kept three years.
6. Data expires. Sensor tracks after 90 days, redacted records about people after a year, simulated data after 30 days, unless a legal hold applies. Counts below 5 are suppressed before aggregates are released.

Status on 21 October 2026: the policy, its test vectors and the ledger library are written and tested; wiring them into every product is in build. The full schedule is on our trust page.

Limits

• An audit log proves what was done, not that it was right. It helps an oversight officer or a court ask the right question.
• Redaction depends on recognising names in messy text. A scanner catches most of what slips through; it will not catch everything, which is why person-level searches need a second approver.
• A second approver is a check, not a guarantee. Two people can agree to do the wrong thing; the ledger makes that visible afterwards.
• Small numbers can identify people in small places. Suppressing counts below 5 reduces that risk; it does not remove it.

If you see our software, data or staff crossing a red line, write to oversight@trinetra.in. You do not need to give your name.