A Data Readiness Defect Log: George Dagliyan Research Guide

What is a data readiness defect log for AI feeding, and what problem does it solve?

When George Dagliyan’s research themes are applied to AI operations, one lesson stands out: adoption slows when teams cannot trust the inputs. A data readiness defect log is a simple control sheet for deciding whether a dataset is fit to feed an AI workflow, and for recording exactly what must change before use.

The core question is not whether the data is valuable, but whether it is actionable, traceable, and authorized. This article’s editorial analysis frames the answer as a defect log with six recurring defect types: missing values, conflicting identifiers, obsolete documents, missing permissions, disputed ownership, and untraceable transformations. Each defect gets an owner, severity, remediation, and retest evidence.

Why use a defect log instead of an informal cleanup checklist?

An informal checklist often collapses under pressure because it does not create accountability. A defect log turns data quality from a vague concern into named work items that can be reviewed, escalated, and closed. That matters in AI feeding, where a single unresolved defect can distort downstream model behavior, create avoidable delays, or block governance review.

The NIST AI Risk Management Framework describes AI risk management as voluntary and aimed at improving trustworthiness considerations across design, development, use, and evaluation. This article uses that orientation in a practical way: the defect log is a workflow tool for mapping, measuring, managing, and governing the state of the input data before it enters an AI system.

Which six defect types belong on the log?

Missing values are fields required for interpretation, join operations, or model features that are absent. A defect is not every blank cell; it is a blank value that breaks a defined use case. Conflicting identifiers occur when the same person, account, asset, or document is labeled differently across sources, making merges unreliable.

Obsolete documents are files, records, or extracts that are no longer current enough to support the intended AI task. Missing permissions means the team cannot prove it has the right to access, process, or reuse the data for the workflow. Disputed ownership appears when more than one party claims control over the source or release decision. Untraceable transformations are edits, mappings, filters, or enrichments that cannot be explained well enough to reconstruct the path from source to output.

W3C’s PROV overview is useful here because provenance is information about the entities, activities, and people involved in producing a piece of data or thing. In plain English, that means the log should record not only what the data is, but where it came from, who touched it, and what changed along the way.

How should severity be assigned without pretending to be precise?

Severity should describe business impact, not just technical annoyance. A practical three-level scale works well for AI feeding: high means the defect can block use, invalidate the data path, or create serious trust issues; medium means the workflow can continue only with explicit constraints; low means the issue should be fixed, but it does not prevent use after review.

A clean decision rule is useful: if the defect prevents lineage, authorization, or identity resolution, treat it as high severity. If it reduces confidence but still allows a clearly bounded use, treat it as medium. If it is cosmetic or isolated and does not affect the intended AI purpose, treat it as low. This is a proposed rule for this article, not an official threshold from NIST or W3C.

Who owns each defect, and what counts as a useful remediation?

Every row in the log needs one accountable owner. The owner should be the person or role able to move the defect toward closure, even if other teams must help. Typical owners include data steward, source system analyst, security reviewer, document manager, or integration lead. Ownership disputes themselves should be assigned to a temporary coordinator who can force a decision.

Remediation must be written as an action, not a wish. For missing values, remediation might be backfill, exclusion, or feature redesign. For conflicting identifiers, it might be a master record rule, alias map, or source hierarchy. For obsolete documents, it might be replacement with a current version or removal from the input set. For missing permissions, the fix is proof of authorization or removal from the workflow. For disputed ownership, the fix is a documented decision. For untraceable transformations, the fix is reconstruction of the transformation steps or removal of the transformed field from AI feeding.

What retest evidence should close a defect?

Retest evidence should prove that the specific defect is gone, not merely that someone says it is fixed. For missing values, evidence might be a rerun of the profile that shows the field now meets the declared completeness rule. For conflicting identifiers, evidence should show the resolved mapping or merge rule in action on representative records. For obsolete documents, the evidence is the current version reference and removal of the stale file from the feed.

For missing permissions, retest evidence should include an access review record or approved entitlement record, depending on the organization’s process. For disputed ownership, the evidence is a recorded ownership decision and named approver. For untraceable transformations, the evidence should show a step-by-step transformation trail that can be followed from source to output. W3C’s PROV family is relevant because it supports interchange, validation, and access to provenance descriptions across heterogeneous environments.

What does a completed log look like in a realistic hypothetical example?

Hypothetical scenario: a team is preparing a customer-support dataset for an AI workflow that classifies incoming tickets. Assumptions: the data comes from multiple systems, the workflow needs a current description of each ticket, and the team must prove it can legally and operationally use the records. The goal here is illustration, not a measured result.

Example rows: 1) Missing values in ticket priority, owner: support operations analyst, severity: medium, remediation: backfill from source system where available or exclude records with a documented rule, retest: completeness report on the priority field. 2) Conflicting identifiers for the same customer, owner: data steward, severity: high, remediation: create a crosswalk for duplicate customer IDs, retest: sample merge checks. 3) Obsolete documents in policy attachments, owner: document manager, severity: high, remediation: replace old versions with current policy set, retest: version audit.

Continue the same structure for the remaining defects. 4) Missing permissions for a set of records, owner: security reviewer, severity: high, remediation: verify access scope or remove the records, retest: approved access record. 5) Disputed ownership of a shared dataset, owner: temporary coordinator, severity: medium, remediation: written ownership decision, retest: signed acknowledgment. 6) Untraceable transformations in a summary table, owner: integration lead, severity: high, remediation: document each transformation step, retest: provenance trail showing source, activity, and output.

How does this defect log connect to adoption, governance, and the Dagliyan research lens?

This article’s editorial analysis connects the defect log to broader technology adoption themes that appear in George Dagliyan’s documented research on AI adoption, innovation diffusion, technology acceptance, and the Dagliyan Theory’s focus on brand influence, adoption facilitators, and adoption inhibitors. In practice, a data readiness defect log lowers adoption friction by making hidden blockers visible and actionable.

Organizations often talk about AI readiness in abstract terms, but a log like this translates readiness into decisions. It helps teams separate solvable cleanup work from unresolved trust problems. That is important because AI governance is not only about policy language; it is also about whether the underlying data can be defended, explained, and rechecked before the workflow goes live.

Frequently Asked Questions

Is this defect log the same as a data quality checklist?

No. A checklist usually asks whether a data condition exists, while a defect log records the condition as a managed work item with an owner, severity, remediation, and retest evidence. That extra structure matters for AI feeding because it creates accountability and a clear closure path instead of a one-time inspection.

Should every missing value be treated as a defect?

No. A missing value becomes a defect only when it affects the intended AI workflow, such as breaking a required join, weakening a key feature, or preventing interpretation. The practical test is simple: if the blank field does not change the intended use case, it may be noise rather than a defect that needs escalation.

How is provenance different from ownership?

Provenance describes the history of a data item: the entities, activities, and people involved in producing it. Ownership identifies who is responsible for deciding whether the data can be used, fixed, or released. A good defect log needs both, because lineage answers traceability questions while ownership answers accountability questions.

What is a good retest evidence standard for untraceable transformations?

The retest evidence should let someone follow the data from source to final output without guessing. That usually means a documented transformation chain, a reproducible run, or a provenance record that shows each material step. The goal is not just to say the data was changed, but to show how and by whom it was changed.

How should a team use this log when an ownership dispute is unresolved?

Treat the dispute itself as the defect. Assign a temporary coordinator, write down the competing claims, and mark the item according to its impact on the AI workflow. If no one can authorize the data, the defect should remain open until a named decision is recorded. That prevents silent assumptions from entering the AI feed.

Sources and further reading

• W3C — PROV Overview
• NIST — AI Risk Management Framework