A phrase such as “improve reconciliation” can fit comfortably inside a corrective-action plan while leaving the records, source ownership, and criteria for demonstrating effectiveness unspecified. Turning that instruction into software requires an understanding of the process behind the finding and agreement on what would establish that the remedy works.
DoD OIG says auditors issued 2,485 notices of findings and recommendations to management in 2025. That figure deserves attention, but translating it into a workload for AI requires knowing what the findings actually concern.
The 2,485 notices reported by DoD OIG were issued during the year, and their underlying contents generally are not publicly posted, limiting what can be inferred about the specific remediation work involved. The count cannot establish a backlog of open tickets or a catalog of AI use cases. The 26 reported material weaknesses describe a separate measure whose significance also depends on the issues and responsibilities behind it.
Remediation involves collecting records, tracking changes, reconciling conflicting information, and showing reviewers what happened, activities that can divert attention from fixing the underlying control. A team may implement a reasonable change yet struggle to produce a coherent account of it, or assemble an excellent packet while the process remains weak. The software needs to connect the evidence to what was actually done so the reviewer can distinguish those situations.
The finding and the work underneath it
A finding may concern missing evidence, an ineffective control, a system limitation, a policy problem, or failure to carry out an established process. Those causes require different remedies, with retrieval potentially addressing an evidence gap while ownership or control-design failures need decisions and changes elsewhere in the organization.
A proposal to have an agent read a finding and execute its remediation plan assumes the plan defines its tasks and dependencies clearly enough for software to act. In practice, improving reconciliation may require agreement on an authoritative system, and a due date may depend on another team's deployment. Demonstrating effectiveness may also require observations across a period, with the collection and review conditions established before the agent can prepare useful evidence.
An owner with the relevant accounting knowledge, process knowledge, or system authority needs to make those relationships explicit before automation can execute useful work. A model can extract proposed requirements from a plan, but the owner must confirm their meaning and identify the evidence needed to assess them, including dependencies that the document may leave implicit.
After confirmation, software can retrieve records from authorized sources, preserve identifiers, normalize fields, and flag disagreements for review. A model may assist with interpreting inconsistent labels or drafting an explanation, while deterministic checks verify defined properties such as period coverage. Routing unresolved discrepancies to the source owner gives the investigation a next step that can lead to a correction.
Reducing repeated evidence assembly gives the responsible people more time to investigate and assess the corrective action while leaving closure with the appropriate authority. The product can be evaluated on how efficiently it prepares an inspectable case and whether that case helps the reviewer reach a supported conclusion.
Unreachable sources, stale artifacts, and conflicting records need to remain visible in the packet because they affect what management can conclude. The interface should connect each unresolved issue to the requirement it prevents the team from demonstrating, preserving the distinction between completed work and a favorable description of work that remains uncertain.
A packet is a claim about the process
Approved policies, completed reconciliations, and signed reviews need to be examined against what the control is supposed to accomplish. A current policy may not be followed in practice, a reconciliation may cover the wrong period, or a review may lack the records needed to reproduce its conclusion. The software should help the reviewer inspect those properties and identify the observations that support an assessment of effectiveness.
The evidence model should identify what each artifact supports, distinguishing authorization of an action, observation of its execution, and a comparison of the resulting state with an expected condition. A reviewer can then assess whether those observations support the requested conclusion and identify where additional evidence or a different kind of check is required.
The product should let a reviewer move from a statement to its supporting record, source, and collection history. A claim that corrective action was implemented may originate in a system observation, a person's attestation, or a plan describing future work; retaining the evidence type prevents a generated summary from making those sources appear equivalent.
Collection time, the period covered by an artifact, and the action being assessed need to be retained together. A pre-change record cannot establish the effect of a later modification, while a post-change record may cover too narrow a period to support a broader conclusion. The reviewer needs those relationships to judge relevance, rather than a pointer to whichever document was uploaded most recently.
Preserving originals and recording transformations, replacements, and corrections keeps the packet reconstructable as the plan evolves. When a reviewer rejects an interpretation, the application should retain the decision and route the underlying issue for resolution, preventing the next run from presenting the same unsupported conclusion as new evidence.
An action ledger should record what the agent attempted, accessed, or changed and which identity authorized each consequential operation. A transcript may help explain the reasoning, but the operational record needs to establish what actually happened independently of how the model described it.
The system should retain missing evidence and contradictory records as unresolved conditions until an appropriate resolution is recorded. Status indicators need to reflect those conditions without requiring users to choose a favorable outcome merely to complete a row or advance the workflow.
Versioning the approved plan also helps the team maintain that evidence model. When a requirement changes, the application should retain the earlier requirement and its associated records, then identify which checks and evidence requests need revision. A record collected for the old requirement may remain useful without being sufficient for the new one, so the reviewer needs to see why it was carried forward and what still needs to be gathered. This makes the next status packet a view of the currently approved work while preserving the basis of earlier reports.
For recurring checks, the team should define what observation period supports the intended conclusion and how gaps will be represented. A successful run on one day may establish that a service executed, while a claim about continued control operation needs evidence across the relevant period. Recording coverage alongside results helps the owner detect missing intervals and prevents an automated packet from overstating what its collection history demonstrates.
Where the agent stops
Permissions should follow the responsibility assigned to each participant, allowing an agent to collect evidence and prepare comparisons while reserving submission approval and assessment of the remedy for the appropriate identities. Accounting judgments, policy decisions, control design, and leadership accountability need to remain attributable to people with the authority to make and defend them.
Collection permissions should be limited to the access needed for gathering evidence, with modifications handled through separately authorized operations and retained records. Otherwise, a model able to change the sources it is examining could alter the evidence before a final approval screen is reached. Instructions found in retrieved material must not become a means of expanding those capabilities.
Where a document states that management considers an action complete, the agent can report the assertion together with its source and associated evidence. The reviewer should be able to inspect whether that evidence supports the assertion, without the application silently promoting management's statement into an independent verification.
Identity, queues, state, and durable records need predictable behavior and belong in the workflow implementation. The model can assist where documents vary, language requires interpretation, or a draft reduces clerical work, with that contribution assessed separately from the reliability of the surrounding services.
Weak provenance can force reviewers to reconstruct every packet, adding an extra layer of work that eliminates the expected savings. Narrower scope and clearer evidence presentation can make verification more efficient, but their effect needs to be measured across the full process. Rework and reviewer effort reveal whether the packets help people complete their task, while a count of generated packets alone measures output volume.
Evaluation should cover incomplete records, ambiguous requirements, stale artifacts, conflicting sources, and interrupted access. If a source becomes unavailable during collection, the workflow needs to preserve what was gathered and identify the requirement that remains unsupported. The reviewer can then determine whether to retry retrieval, seek another authorized source, or leave the requirement unresolved, with the interruption visible in the case history.
Maintaining the automation requires an owner for the mapping between requirements, sources, and checks as systems, permissions, and plans change. The workflow can become misleading without crashing when a source changes meaning or a revised plan invalidates an old check, making that maintenance part of both the product's cost and its continuing evaluation.
The reason I like audit support as a place to build is that it forces the conversation toward evidence. The buyer has a reason to care where information came from, who approved an action, and whether a conclusion can survive scrutiny. Those demands make vague agent capabilities less useful and good infrastructure more valuable.
Useful audit support can help an owner locate evidence, identify disagreements requiring attention, and preserve history through changes in the plan. A status packet produced from those retained relationships can become a reproducible view of the work, reducing repeated recollection while exposing what remains to be demonstrated.
The original finding may still require a hard decision, a system change, or sustained management attention. Automation contributes by giving the responsible people a clearer and more inspectable account of completed work and unresolved requirements, with evidence that can support their decisions as remediation proceeds.
Have a challenge we can help with?