Follow The Data Flow
Ask what enters, who can query, who can export, what vendors can see, what gets shared, how long it is retained, what is deleted, and what happens when the data is wrong.
Publication information
Context
Follow The Data Flow asks whether the public record supports this proposition: Ask what enters, who can query, who can export, what vendors can see, what gets shared, how long it is retained, what is deleted, and what happens when the data is wrong.
Ask what enters, who can query, who can export, what vendors can see, what gets shared, how long it is retained, what is deleted, and what happens when the data is wrong.
Start with contracts, procurement files, privacy impact reviews, data-sharing agreements, vendor documentation, budgets, and renewal records.. Record what it establishes, what it does not establish, and which additional evidence would change the assessment.
Evidence Snapshot
Reader Verification Path
Separate stated purpose from records that can independently support the claim.
- Follow the purchase, policy, data source, retention rule, and audit trail before accepting a vendor claim.
- Use the surveillance and data-broker links to check what kind of system the page is talking about.
- Ask who can see the record, who can challenge it, and when it expires.
Relevant Public Records
For Follow The Data Flow, pull the system trail from purchase to use: contract, scope of work, data source, integration note, access policy, retention schedule, sharing agreement, audit log, and deletion rule.
Look for the public body that approved the risk: procurement board, city council, school board, agency leadership, privacy office, inspector general, grant file, or litigation record.
Use contracts, procurement files, privacy impact reviews, data-sharing agreements, vendor documentation, budgets, and renewal records. to show whether the system exists, then ask who can query it, who can export results, who reviews misuse, and what happens when the record is wrong.
A surveillance page is incomplete until it names the appeal, deletion, correction, audit, or oversight route available to someone affected by the system.
Verify And Read Further
These are direct references, not off-site search results. They point to official organizations, public records references, legal sources, civil-liberties material, or technical governance pages worth reading on their own.
- Freedom of the Press Foundation Official organization page from the 2IA directory seed; use it to verify identity, scope, and current work.
- Citizen Lab Official organization page from the 2IA directory seed; use it to verify identity, scope, and current work.
How To Read The Record
When reading Follow The Data Flow, trace the boundary of the system: collection point, data source, database, vendor integration, authorized user, export path, retention rule, and deletion path.
Look for who approved the system and who can stop it. Contracts, council records, privacy reviews, grant files, memoranda, lawsuits, and audits often reveal authority better than product pages do.
The record becomes more serious when access logs, query rules, sharing limits, misuse review, retention schedules, and redress procedures are missing, vague, or left to vendor discretion.
Keep Reading
Issue and documented effects
Follow The Data Flow asks whether the public record supports this proposition: Ask what enters, who can query, who can export, what vendors can see, what gets shared, how long it is retained, what is deleted, and what happens when the data is wrong.
Documented incentives or beneficiaries: Relevant incentives, institutional interests, commercial beneficiaries, or decision-making advantages should be identified from records and attributed evidence rather than assumed.
Documented or plausible impacts: Documented or plausible effects should be tied to a named decision, affected group, time period, and evidence source; unverified harms remain labeled as such.
Evidence To Request
Ask which record, method, audit, policy, or correction history would allow the claim to be independently checked.
- Where does collection begin: camera, license plate reader, commercial feed, public-source monitor, case-management tool, platform report, device record, or vendor integration?
- Who can query, export, share, retain, delete, audit, or correct the data?
- Which public body approved the purchase, grant, renewal, policy, or data-sharing agreement?
- What contract clause lets the public terminate the system, audit use, or require deletion?
- What record proves or contradicts this claim from Follow The Data Flow: Ask what enters, who can query, who can export, what vendors can see, what gets shared, how long it is retained, what is deleted, and what happens when the data is wrong.
The Record Trail
Verification starts with records that already exist: contracts, policy manuals, retention schedules, audit logs, denial letters, complaint files, vendor claims, court forms, and correction history.
- Contracts, procurement files, privacy impact reviews, data-sharing agreements, vendor documentation, budgets, and renewal records.
- Policy evidence: access rules, authorization standards, audit logs, retention schedules, deletion procedures, sharing limits, and appeal paths.
- Technical-claim evidence stated at governance level: data sources, model claims, integration points, and limitations without operational misuse detail.
- Public-accountability evidence: meeting minutes, oversight reports, inspector-general style findings, litigation records, or public statements.
Revision Conditions
Follow The Data Flow changes when the record changes. A released contract can show the tool was never purchased. A policy can show a narrower rule than officials implied. An audit can prove error rates are tracked and repaired. A correction log can show whether people actually get relief.
A claim is more useful when it identifies the record or observation that would revise it. That makes uncertainty and correction part of the analysis rather than an afterthought.
- What part of the architecture affects rights?
- Which contract, policy, or audit trail proves the claim?
- What information should remain out because it would enable probing, evasion, or targeting?
Reference Notes
Sources and limitations
Open questions
- What part of the architecture affects rights?
- Which contract, policy, or audit trail proves the claim?
- What information should remain out because it would enable probing, evasion, or targeting?
What stays out
Surveillance-system pages can discuss governance and public accountability. They must not publish probing instructions, evasion guidance, sensor-triggering paths, or targetable infrastructure detail.