Resistance Survival Guide #320
A government algorithm denies benefits. A surveillance platform identifies the wrong person. An automated fraud system freezes assistance. Suddenly, everyone involved develops a severe allergy to active verbs.
The agency blames the contractor. The contractor says it followed agency requirements. The program office says technology staff handled it. Technology staff point toward legal counsel. Legal counsel declines to discuss internal deliberations. By the time the explanation reaches the public, the system appears to have authorized itself during a mysterious electrical storm.
It did not.
Government systems have sponsors, owners, contracting officers, security reviewers, privacy officials, legal advisers, data stewards, and authorizing officials. Someone requested the system. Someone selected the vendor. Someone approved the data. Someone accepted the risks. Someone signed the document permitting the system to operate.
This Resistance Survival Guide explains how to find those people and reconstruct the approval chain.
Why the Approval Chain Matters
Government agencies increasingly use artificial intelligence, automated screening, facial recognition, predictive analytics, identity verification, fraud detection, and risk scoring. These systems can influence access to health care, housing, employment, education, immigration decisions, disability benefits, public assistance, and law enforcement attention.
The consequences may be serious even when the technology is not officially described as artificial intelligence. Agencies and vendors may use softer terms such as decision support, advanced analytics, identity resolution, risk management, case prioritization, anomaly detection, or workflow modernization.
Do not let the vocabulary distract you. If a system analyzes information and influences what happens to a person, investigate it.
Federal guidance recognizes that certain systems require additional scrutiny. Office of Management and Budget Memorandum M 25 21 requires covered agencies to apply minimum risk management practices to high impact artificial intelligence. When an affected system cannot meet the required protections, the memorandum directs the agency to stop using it until the problem is corrected.
That requirement sounds reassuring. Unfortunately, a safeguard is only as strong as the documentation, testing, and human accountability behind it.
The People You Are Trying to Identify
The approval chain may differ between agencies, but most investigations should look for several specific roles.
The program executive or program manager explains why the system is needed and controls its operational use. The system owner manages the technology or business process. The contracting officer controls the procurement and has legal authority over the contract. The contracting officer representative monitors the vendor’s performance.
The chief information officer oversees agency information technology. The chief artificial intelligence officer coordinates artificial intelligence governance at covered federal agencies. The senior agency official for privacy oversees privacy compliance. Civil rights officials may review discrimination risks. General counsel or agency attorneys review legal authority. Records officers determine how system records must be preserved.
The security control assessor evaluates security controls. The authorizing official decides whether the system may operate at an acceptable level of risk. The Cybersecurity and Infrastructure Security Agency defines an authorizing official as the senior official who formally assumes responsibility for operating an information system at an accepted level of risk.
That signature matters. It identifies a human being who accepted responsibility after reviewing the risks.
The Documents That Reveal the Approval Chain
Your investigation should search for documents created during planning, procurement, review, authorization, deployment, and monitoring. No single record will reveal everything. The goal is to combine records until the same names, offices, dates, and decisions begin appearing together.
Useful records include:
- Artificial intelligence use case inventories
- System of Records Notices
- Privacy impact assessments
- Artificial intelligence impact assessments
- Algorithmic impact assessments
- Civil rights impact assessments
- Security assessment reports
- Authority to operate letters
- Risk acceptance memoranda
- Plans of action and milestones
- Data governance plans
- Data sharing agreements
- Requests for proposals
- Statements of work
- Performance work statements
- Source selection documents
- Award notices and contract modifications
- Vendor performance evaluations
- Meeting agendas and minutes
- Governance committee charters
- Legal memoranda
- Testing and validation reports
- Incident reports
- Appeal and override procedures
- Records retention schedules
- Emails between agency officials and the vendor
Some security records may be partially withheld because releasing technical details could create a genuine vulnerability. That does not automatically justify hiding the names of senior officials, approval dates, system purpose, contract value, oversight structure, or the existence of required reviews.
Step by Step Guide
Step One: Define the System Before Searching for It
Begin with the public name of the system, but do not stop there. Record the vendor name, product name, contract number, program office, agency division, announced purpose, approximate deployment date, and every acronym you encounter.
Search agency pages, procurement records, meeting minutes, budget documents, job advertisements, vendor announcements, conference presentations, and oversight reports. A system described publicly as a benefits modernization project may appear in contracts as a case integrity platform. The cheerful public name is often wearing a much more revealing procurement name underneath.
Create a simple research sheet with columns for name, title, office, document, date, decision, and source link. Every time a person appears, add them. You are building a responsibility map, not collecting decorative PDFs.
Step Two: Find the Agency’s Artificial Intelligence Inventory
Search the agency website for its current artificial intelligence use case inventory. Also search archived versions because descriptions, classifications, and responsible offices can change.
Compare the system’s purpose, status, impact category, agency owner, and public description across every available year. Look for systems that disappear, change names, move between offices, or suddenly stop being classified as high impact.
Do not assume the inventory is complete. A Government Accountability Office review found incomplete and inaccurate information in federal agency artificial intelligence inventories. Later agency updates corrected some of those problems, but several recommendations remained open during subsequent reviews.
The absence of a system from an inventory is a finding to investigate, not proof that the agency never used it.
Step Three: Identify the Program Owner
Search the agency’s organizational chart, budget justification, procurement forecast, leadership directory, testimony, meeting minutes, and project announcements. Your goal is to identify the office that requested the system and the executive responsible for that program.
Look for titles such as program executive, program manager, product owner, mission owner, system owner, business owner, project sponsor, or use case owner.
Once you find a likely official, confirm the role through at least two records. A vendor presentation may identify a project champion. A contract document may identify the same person as the program manager. An agency directory may confirm the person’s title during the relevant period.
Names matter, but dates matter just as much. The official currently holding a title may not be the person who approved the system three years earlier.
Step Four: Trace the Contract
Search SAM.gov, agency procurement pages, USAspending, inspector general reports, vendor announcements, and public meeting records. Search by vendor name, product name, contract number, program office, and distinctive phrases from the system description.
Collect the solicitation, statement of work, award notice, modifications, task orders, justification documents, and performance requirements. These records can reveal who requested the purchase, who signed the award, what the system was supposed to do, which data it would use, and whether the agency expected it to affect consequential decisions.
Office of Management and Budget acquisition guidance says agencies should identify reasonably foreseeable high impact uses during acquisition planning. It also says contracts involving potential high impact systems must support required documentation, testing, monitoring, and risk management practices.
Compare those requirements with the actual contract. If the contract does not require independent testing, performance monitoring, access to necessary records, or notification of major system changes, document the omission.
Step Five: Find the Contracting Officials
The contracting officer is not merely the person who uploaded a document. This official has authority over the government contract. The contracting officer representative usually monitors whether the vendor performs the work properly.
Search contract documents for the following names and titles:
- Contracting officer
- Contract specialist
- Contracting officer representative
- Program manager
- Technical representative
- Source selection authority
- Approving official
- Competition advocate
Record which person signed the initial award and every major modification. A system may begin as a limited pilot and become far more consequential through later modifications. The official who approved the expansion may be more relevant than the person who signed the original experiment.
A 2026 Government Accountability Office investigation of artificial intelligence acquisitions examined 13 acquisitions across four federal agencies. Investigators found that agencies were not consistently prepared to collect and share lessons from those purchases. That makes the underlying procurement record even more important.
Step Six: Locate the Privacy and Data Approvals
Search for the system’s privacy impact assessment, System of Records Notice, data use agreement, matching agreement, records notice, consent language, retention schedule, and privacy compliance review.
Compare the documents carefully. The privacy impact assessment may describe one set of data while the contract lists additional sources. The System of Records Notice may permit one category of disclosure while a data sharing agreement appears to authorize something broader. A later contract modification may add a new vendor or data source without an obvious update to the privacy assessment.
The March 2026 Government Accountability Office privacy review found that government wide guidance did not fully address eight of ten selected privacy challenges identified by experts. GAO warned that artificial intelligence may expose sensitive information and recommended clearer guidance for privacy assessments, auditing, consent, performance measures, and protection of sensitive data.
Find the official who approved each privacy document. Record the signature date. Then compare that date with the contract award and deployment date. A privacy review completed after the system began operating deserves immediate attention.
Step Seven: Request the Authority to Operate Records
An authority to operate is a formal decision allowing an information system to operate after security and risk review. The complete authorization package may contain sensitive technical information, but you can still request segregable records identifying the authorizing official, approval date, expiration date, system owner, conditions, unresolved risks, and final decision.
Ask for the authority to operate letter, authorization decision memorandum, security assessment report, risk acceptance memorandum, and any conditions imposed on continued operation. Also request records showing whether the authorization was renewed, suspended, extended, or replaced.
Do not frame the request as a demand for passwords, security keys, or exploitable vulnerabilities. You are investigating governance and accountability, not auditioning for a federal indictment.
Step Eight: Find the Impact Assessment and Testing Record
For a high impact artificial intelligence use case, request the artificial intelligence impact assessment, predeployment testing, independent evaluation, risk determination, testing datasets, performance thresholds, disparity testing, validation results, human review plan, appeal process, monitoring plan, and discontinuation plan.
The National Institute of Standards and Technology Artificial Intelligence Risk Management Framework states that leadership should take responsibility for decisions about artificial intelligence risks. It also calls for documented roles, continuing monitoring, risk responses, appeal mechanisms, human overrides, incident response, and safe decommissioning.
Compare the test population with the population affected by the system. Look for missing demographic groups, unrealistic laboratory conditions, low sample sizes, untested language differences, inaccessible appeal procedures, and performance measures that reward speed while ignoring wrongful outcomes.
A system can be accurate overall while repeatedly failing the people who have the least power to correct it.
Step Nine: Reconstruct the Approval Meeting
Request the charter, membership list, agendas, minutes, attendance records, presentations, recommendations, votes, decision memoranda, and email attachments for every committee that reviewed the system.
Possible bodies include an artificial intelligence governance board, investment review board, privacy board, data governance council, acquisition review board, information technology steering committee, civil rights office, or executive risk committee.
Meeting minutes may be bland, but attachments can be wonderfully indiscreet. Search every presentation for phrases such as accepted risk, conditional approval, pilot extension, unresolved issue, operational necessity, legal concern, manual review, false positive, or executive decision.
If minutes show unanimous approval but internal testing identified serious failures, determine whether those results reached the decision makers before the vote.
Step Ten: Request the Communications Around the Decision
Submit a focused public records request for communications among the program owner, authorizing official, contracting officer, privacy official, legal counsel, civil rights office, and vendor during the period immediately before and after approval.
Keep the date range narrow. Use the exact system name, product name, contract number, and known acronyms. Ask for emails and attachments containing approval recommendations, risk discussions, testing concerns, deployment decisions, or requests to delay implementation.
Do not begin by requesting every email anyone has ever sent about artificial intelligence. That is how a legitimate investigation becomes a geological era.
A targeted request is faster, easier to defend, and harder for the agency to dismiss as unreasonably burdensome.
Step Eleven: Compare Approval With Actual Use
An approved system can evolve after authorization. Vendors add features. Agencies connect new databases. Staff begin using risk scores for purposes never described in the original documents.
Compare the approved purpose with training materials, user manuals, job listings, policy directives, contract modifications, system updates, and accounts from affected people. Look for function creep, which occurs when a system quietly expands beyond its original purpose.
Check whether the agency conducted another review after major changes. Request new impact assessments, security authorizations, privacy reviews, testing records, and approval memoranda.
A pilot that later became mandatory is not the same system in any meaningful accountability sense, even if the agency kept the same cute acronym.
Step Twelve: Build the Responsibility Timeline
Place every significant event in chronological order. Include the procurement request, solicitation, contract award, privacy review, risk classification, testing, committee approval, authority to operate, deployment, reported failures, contract modifications, authorization renewals, and public complaints.
For every event, name the official or office responsible. Mark any point where the system operated without a current review, where approval followed deployment, or where officials accepted a known risk without documenting corrective action.
Your final timeline should answer six questions:
- Who requested the system?
- Who selected the vendor?
- Who approved the use of personal data?
- Who evaluated the risks?
- Who authorized operation?
- Who allowed continued use after problems became known?
That is the approval chain.
A Public Records Request You Can Adapt
Under the applicable public records law, I request records concerning the authorization, approval, testing, acquisition, deployment, and continued operation of the system known as [SYSTEM NAME], including any former names, product names, project names, and internal acronyms.
Please provide the authority to operate decision, authorization memorandum, artificial intelligence impact assessment, privacy impact assessment, System of Records Notice, security assessment, risk acceptance memorandum, civil rights review, legal review, testing and validation reports, monitoring plan, appeal and override procedures, governance committee records, relevant contract documents, and records identifying the program owner, system owner, contracting officer, contracting officer representative, security control assessor, privacy official, and authorizing official.
I also request meeting agendas, minutes, presentations, decision memoranda, and communications documenting whether the system was approved, conditionally approved, rejected, suspended, expanded, renewed, or permitted to continue operating after officials learned of performance, privacy, security, accessibility, or civil rights concerns.
If any portion of a record is withheld, please release all reasonably segregable material and identify the legal basis for each withholding. Please provide records electronically in their original digital format when available.
For federal agencies, cite the Freedom of Information Act. For state and local systems, use the applicable state public records law. MuckRock offers an independent platform for filing, tracking, and publishing public records requests. Its public request archive can also reveal whether another researcher has already obtained useful records.
How to Read an Approval Without Being Fooled by It
Approval does not prove that a system was safe, lawful, accurate, or necessary. It proves that an official allowed it to operate based on the information presented at that time.
Read every approval for conditions. Look for limited duration, restricted data, required human review, mandatory testing, unresolved vulnerabilities, or instructions to correct deficiencies. Then investigate whether the agency actually followed those conditions.
Watch for passive language. Phrases such as risks were accepted, concerns were addressed, or approval was granted can conceal the identity of the decision maker. Rewrite each sentence as a question.
Who accepted the risk?
Who decided the concern was addressed?
Who granted approval?
Who had authority to say no?
Passive voice is often where accountability goes to enjoy a quiet retirement.
Warning Signs in the Approval Record
Several patterns deserve closer investigation.
An authority to operate signed after deployment may indicate that the system operated before completing review. A privacy assessment copied from an unrelated system may show that reviewers treated compliance as paperwork. Missing meeting minutes can conceal who attended or dissented. Repeated temporary authorizations may indicate unresolved risks.
A contract that lets the vendor conduct all performance testing creates an obvious independence problem. A risk assessment that excludes affected communities may overlook predictable harm. An approval package that studies cybersecurity but ignores discrimination may be complete only in the bureaucratic sense.
Also watch for systems classified as administrative even though their outputs influence consequential decisions. Labels should never receive more trust than evidence.
Protect the People Behind the Evidence
Government technology investigations can involve personal medical, financial, immigration, employment, or disability information. Remove personal identifiers before publishing records. Obtain consent before sharing an individual’s experience. Explain how the information will be used and give the person an opportunity to correct factual errors.
Do not publish technical details that could expose private information or create a genuine security vulnerability. Accountability requires evidence, but it does not require turning victims into exhibits or handing bad actors an instruction manual.
Center the people affected by the system. Their experiences can reveal failures that an agency’s aggregate accuracy rate conveniently buries.
Turn the Research Into Public Accountability
Once the evidence is organized, publish a clear approval chain rather than an enormous document dump. Identify each official, title, decision, date, and supporting record. Distinguish confirmed facts from reasonable inferences and unanswered questions.
Send the findings to independent journalists, public interest attorneys, civil rights organizations, inspectors general, legislative oversight committees, and local advocacy groups. Provide the underlying documents through a public archive such as MuckRock or DocumentCloud.
Ask officials precise questions. Do not ask who was responsible in general. Ask whether a named official signed a specific approval on a specific date after receiving a specific warning.
It is much harder to hide behind process when someone has already reconstructed the process.
Final Thoughts
A harmful government system is not an orphan. It has a budget, an office, a contract, a risk record, and an approval history. Every one of those records points toward people who possessed authority and made choices.
Your investigation may reveal that officials followed the required process. It may reveal that the process ignored important harms. It may also reveal that critical approvals were incomplete, late, conditional, or quietly bypassed.
The goal is not to blame the nearest technology employee. The goal is to identify who knew what, when they knew it, what authority they possessed, and why they allowed the system to operate.
Algorithms do not accept legal responsibility. Vendors do not govern themselves. Passive voice did not sign the authorization.
A person did.
Source List
- Government Accountability Office: Privacy Gaps in Federal Artificial Intelligence Guidance
- Government Accountability Office: Federal Artificial Intelligence Acquisitions
- Government Accountability Office: Agency Artificial Intelligence Inventories
- Office of Management and Budget: Federal Use of Artificial Intelligence
- Office of Management and Budget: Acquisition of Artificial Intelligence
- National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework
- Cybersecurity and Infrastructure Security Agency: Authorizing Official
- MuckRock Public Records Platform
