AI Findings Register Design

An AI findings register should preserve the meaning of an audit finding as evidence, ownership and remediation change. Its job is not simply to count open tickets. A useful register lets a reviewer answer which criterion was not met, what was observed, which system version was affected, who owns the response and what evidence supports the current status. Those answers must remain available after the original assessor leaves.

This guide is for audit operations leads, risk teams and system owners designing that record. A hypothetical rental-equipment handover summariser illustrates the choices. The assistant turns handover notes into a draft summary; the example does not describe an actual customer or completed audit. The proposed register is an original internal design, with separate records for observations, findings, actions and verification.

Define the unit of a finding before choosing the software

A finding is an assessed departure from an agreed criterion within a defined scope. An observation is a piece of evidence about what happened. An action is something an owner plans or performs in response. These are related but different entities. If a register treats every failed test as a separate finding, it can inflate counts. If it treats every shared symptom as one issue, it can hide different owners, consequences and remedies.

For the handover summariser, several outputs might omit a note that a detachable component was absent at return. The observations could support one finding about preservation of specified handover conditions. A separate observation showing that staff could approve a summary under the wrong role may require a distinct finding because the criterion, control owner and correction differ. Similar business context alone is not a sufficient reason to merge them.

Start with the relationships you need to preserve, then choose a spreadsheet, issue tracker or governance platform. A small controlled register can work well when access, history and links are managed. A sophisticated platform can still fail if a “closed” status means whatever each owner chooses. The process definition matters more than the product name or the number of fields available.

NIST's OSCAL Assessment Results model distinguishes observations, risks and findings in structured assessment information. That is a useful conceptual reference, not a requirement to adopt OSCAL for this proposed register. The design below uses its own fields and workflow, selected for practical traceability in an AI assessment.

Separate permanent identity from changing assessment

Assign a stable finding identifier that does not encode severity, owner or status. Those attributes may change after new evidence or organisational changes. Preserve the original title and subsequent revisions where they affect interpretation. The identifier should continue to refer to the same assessed issue, even when its wording becomes clearer. Deleting and recreating an issue to reset its age destroys useful history.

Store the affected scope explicitly: system, workflow, available release identifiers, environment, tested period, languages and relevant populations. Avoid a single free-text “AI system” cell when several deployments share a model but use different instructions or permissions. If a finding may affect other deployments, record that as suspected exposure with an investigation owner. Do not silently extend a tested finding to every deployment sharing a brand name.

Core finding fields and the errors they prevent

Field group	Required content	Why it matters
Identity and origin	Stable ID, engagement, creation date and author	Preserves lineage when ownership or wording changes.
Criterion and condition	Requirement reference, applicability and observed departure	Prevents a vague concern becoming an unsupported compliance allegation.
Scope and evidence	Versions, period, population, observation IDs and controlled evidence links	Keeps the finding tied to what was actually examined.
Assessment	Consequence, exposure, severity rationale, confidence and unresolved cause hypotheses	Separates seriousness from strength of evidence.
Response	Accountable owner, action IDs, containment and decision records	Distinguishes management responsibility from assessor verification.
Verification and disposition	Retest plan, result, reviewer, limitations and closure basis	Prevents deployment or owner assertion from being mistaken for effective correction.
History	Material changes, reasons, actors and timestamps	Supports review of reclassification, merging and reopening.

Keep a data dictionary beside the register. Define what each field means, which values are allowed and who may change them. A field named “risk” may otherwise contain a consequence in one record, a severity score in another and a proposed fix in a third. Consistent meaning makes portfolio reporting possible without pretending that every system has comparable exposure.

Use linked records instead of overloading one row

One finding may require several actions: contain the immediate exposure, investigate the mechanism, correct the control and verify operation. Each action needs its own owner and status. If all actions are compressed into one cell, the register cannot show that containment is complete while the durable correction remains unimplemented. Link action records to the finding and retain the finding's assessment independently.

Similarly, link evidence by stable reference rather than pasting raw personal records into the register. The register should identify what an item supports and where authorised reviewers can inspect it. A link to a mutable dashboard is not equivalent to a preserved observation. Record the evidence version or observation time and follow the agreed evidence-handling rules. Access to the register should not automatically grant access to restricted attachments.

Preserve a separate decision record where management accepts residual exposure, authorises temporary operation or changes a deadline. Record the authorised person, rationale, conditions, scope and review trigger. An acceptance decision is not an action completion and not a successful retest. Keeping these entities separate prevents a governance decision from erasing a technical weakness in later reporting.

Worked record: an omitted handover condition

In the hypothetical case, selected draft summaries omit a source note that a detachable accessory was not returned. The organisation's agreed internal rule requires that designated handover conditions remain visible or be referred for review. The assessor confirms the omission in preserved source-output pairs. Whether a downstream charge was issued is a separate question and is not assumed from the draft alone.

Illustrative finding record before remediation

Field	Filled example
Finding ID and title	HAND-07: designated return conditions omitted from selected draft summaries.
Criterion	Internal handover rule HR-04, approved for the assessment; preserve designated conditions or refer for review.
Scope	Draft-summary workflow, tested instruction release 6, selected completed handovers in the agreed window.
Condition	Preserved source-output pairs show omission of an explicitly recorded absent accessory.
Consequence	A reviewer relying only on the summary could miss a relevant return condition; actual downstream use requires separate evidence.
Cause status	Unresolved: source extraction and summarisation behaviour remain candidate explanations.
Evidence links	Observation OBS-H12; workpaper WP-H03; controlled source-pair references.
Accountability	Process owner owns the response; technical owner owns diagnosis; designated reviewer verifies correction.
Initial disposition	Confirmed finding; management response requested; no claim of verified correction.

The title states the observed control issue rather than a preferred remedy. “Retrain the model” would be an action proposal, and possibly the wrong one if preprocessing removed the source condition. The register should preserve uncertainty about cause while still recording a supported finding. An unresolved cause does not make an observed departure disappear; it affects the remediation plan and the confidence in a proposed fix.

Make status changes evidence-dependent

Define state transitions rather than a loose list of labels. A record moves from preliminary observation to confirmed finding when the criterion and supporting evidence have been reviewed. It moves to remediation planned when management has assigned a response. It becomes ready for verification when specified implementation evidence is available. Verified correction requires the agreed retest result, not simply a completed engineering ticket.

Proposed status transitions and required support

Transition	Required support	What the transition does not establish
Observation to confirmed finding	Applicable criterion, reviewed evidence and bounded condition	It does not establish an untested root cause.
Confirmed to response agreed	Owner, actions, containment, dates and acceptance criteria	It does not show that actions were implemented.
Response agreed to ready for retest	Change identifiers, deployment evidence and testable closure package	It does not prove operating effectiveness.
Ready for retest to verified corrected	Reviewed retest evidence meeting the defined criteria	It does not certify every future output or unrelated control.
Open to risk accepted	Authorised, scoped acceptance with rationale and review trigger	It does not mean the defect was corrected.
Any relevant state to reopened	New evidence of recurrence, invalid closure support or changed exposure	It does not erase the prior decision history.

Use remediation planning to define actions and dependencies, and retesting to define verification evidence. Keep status labels short but meanings precise. If a platform forces one “closed” state, add a mandatory disposition field distinguishing verified correction, accepted risk, duplicate linkage and superseded scope. Reports should not combine these dispositions into a reassuring total without explanation.

Handle duplicates, shared causes and recurrences carefully

Two observations are duplicates only when they describe the same underlying record or issue under the register's defined unit. Similar wording is not enough. Compare criteria, affected versions, mechanism, consequence and ownership. If the same omitted handover condition appears in several selected cases, linking them to one finding may be appropriate. If a separate workflow suppresses a different mandatory field for a different reason, it may need its own record.

When merging findings, preserve the original identifiers as references, explain the reason and retain each observation. Do not delete the older record without a trace. When splitting a finding, show which observations and actions move to each child record and how the original is disposed of. The resulting counts should be interpretable; a fall in open findings caused by merging is not evidence of reduced exposure.

Distinguish recurrence from newly discovered historical evidence. A failure that happened before the correction but was discovered later does not necessarily show that the correction failed. A new failure under the corrected version may do so. Record occurrence time, discovery time, affected version and relationship to the prior finding. This prevents misleading recurrence metrics and supports a targeted investigation.

Preserve disagreement and rating changes

Management may dispute the criterion, factual condition, consequence or severity. Record the disputed element and the evidence offered, then document the assessor's response. A disagreement field should not become a place for vague statements such as “business disagrees”. A later reviewer needs to know what was contested and whether the finding changed because of new evidence, corrected interpretation or an authorised risk decision.

Severity changes should retain their rationale and effective date. A reduction may be justified by verified containment or better evidence about exposure; it should not occur merely because a deadline is approaching. Use the severity framework consistently, while distinguishing current residual exposure from the original assessed condition. Preserve both where the distinction matters for oversight and trend analysis.

Do not confuse evidence confidence with management agreement. A strongly supported finding can remain disputed, and an uncontested claim can still have weak evidence. Include the confidence or limitation narrative separately from the response status. This makes the register useful for review instead of turning it into a negotiation scoreboard.

Choose metrics that reflect decisions, not cosmetic closure

Useful reporting may include unresolved material findings, overdue actions, findings awaiting evidence, time to verified correction and accepted risks approaching review. Define every denominator and clock. Time from observation to confirmation measures something different from time from an agreed action plan to successful retest. A single “average closure time” can reward easy issues and hide long-standing consequential ones.

Report age by meaningful state. A finding waiting for supplier evidence should remain visible even if no engineering task is overdue. A completed action awaiting independent verification should not count as verified correction. Show changes caused by scope retirement, duplicate merging or administrative reclassification separately from corrections. Otherwise the dashboard can improve while the underlying control position remains unchanged.

Use portfolio comparisons cautiously. A larger count may reflect broader audit coverage or better detection, not a worse system. A small count may reflect limited access or a narrow scope. Pair findings metrics with coverage and evidence limitations. The report narrative should explain these relationships so decision-makers do not rank business units using incomparable raw counts.

Protect history, permissions and exports

Assign permissions according to responsibility. Owners can update action progress; assessors control assessed findings; authorised reviewers approve verification outcomes; governance owners record risk acceptance. The exact separation depends on the organisation, but material changes should be attributable. A shared spreadsheet with unrestricted editing and no version history makes it difficult to distinguish a valid correction from accidental deletion.

Test exports as part of the design. A board extract should preserve material limitations and distinguish closure dispositions without exposing sensitive evidence. An engineering export should include actionable references and acceptance criteria. An external supplier extract should reveal only authorised information. The same underlying finding can support several views, but those views must not change its meaning.

Plan for staff turnover and tool migration. Use stable identifiers, documented field definitions and exportable relationships. Verify that attachments, decision history and links survive migration, rather than assuming a row count proves completeness. Preserve the final engagement reference so a later reviewer can understand which report relied on which register version.

Check the register's own data quality

The register is a control record and needs its own checks. A finding can have a plausible title and still be unusable because its evidence link points to a deleted file or its owner has left the organisation. Run periodic checks for missing required fields, unresolved references and inconsistent states. These checks should identify records for review, not silently rewrite assessments or close items that appear administratively old.

Original consistency checks for a findings register

Check	Flag for review
Closure support	A verified-corrected finding has no linked retest result or reviewer.
Decision authority	A risk-accepted finding lacks an authorised decision or review trigger.
Action completeness	A finding marked ready for retest still has a required implementation action pending.
Scope consistency	The retest concerns a different deployment from the affected scope without an explanation.
Evidence availability	A referenced item is unavailable and no controlled replacement or limitation is recorded.
Owner continuity	The accountable role is vacant or an individual assignment has not been transferred.

For the handover example, an automated check might identify that HAND-07 is marked verified corrected while the linked retest only covers a new interface used at one location. The check does not decide whether closure was wrong. It prompts a reviewer to determine whether the original scope was intentionally narrowed, whether other deployments were retired, or whether verification remains incomplete. Record the explanation instead of forcing all situations into a rigid automated rule.

Protect against misleading date changes. Retain the original target date as well as any revised date, reason and approving role. A repeatedly extended deadline can otherwise appear permanently on time. Similarly, preserve when an action was completed and when its effectiveness was verified; the interval between them may reveal a verification bottleneck. These are different events and should not share one overwritten completion field.

Review the register's data quality alongside its substantive findings. An incomplete record may require administrative correction, while missing evidence may limit the audit conclusion. Distinguish the two rather than assigning every incomplete field the same significance. The goal is to make records interpretable and reliable enough for decisions, without turning field completion into a substitute for evidence review.

Introduce the register with a small reconstruction exercise

Before rolling the design across a portfolio, take one hypothetical or masked finding from observation through assessment, management response, implementation evidence and retest. Ask another reviewer to reconstruct the sequence using only the register and authorised links. If they cannot identify what changed or why the status changed, improve the field definitions and transition rules before adding more records.

OpenForAI's AI auditing service can be discussed around the evidence and follow-up needs of a defined engagement. Bring a masked register export, current status definitions and an example of a difficult closure decision. Discuss a traceable findings register for your AI audit.