Who Owns High-Quality Datasets? Roles, RACI, and Collaboration for Data Product Governance

Why Temporary Project Teams Cannot Handle Post-Launch Issues

Project tasks have clear endpoints: vendors deliver samples, engineering completes integration, algorithms deliver evaluation reports, and project managers organize acceptance. However, post-launch changes do not stop with project closure. Headquarters updates risk rules, branches add contract types, source systems add attachments, and downstream models replace versions — all altering the data's original applicability conditions.

If experts are only borrowed temporarily for acceptance, vendors stop taking orders after payment, and data engineering only has budget for new projects, then even if a release record names a responsible person, problems may stall in chat groups. That name lacks corresponding time, budget, and decision authority. Therefore, at project initiation three things must be confirmed: which business domain continuously owns the data product, where expert and engineering maintenance hours come from, and who takes over the problem queue and consumer relationships after the project ends. If these conditions cannot be met, the delivery scope should be limited to a time‑boxed trial, not accepted as a long‑term production supply commitment.

What Real Authority Does a Data Product Owner Need

The data product owner can be a data product manager or an authorized business/data lead. The title is not the prerequisite; the ability to make continuous trade‑offs is. In the group case, the business domain designates one owner to manage the Dataset Contract — specifying purpose, inputs/outputs, quality requirements, and usage limits. This owner must be able to adjust sample priority by risk and value, arrange expert and engineering resources, reject candidate versions with insufficient evidence, and organize pause, fix, or exit when issues arise.

These powers should be written into the appointment. Matters beyond the owner's authority escalate to a business sponsor who can commit budget and cross‑department resources, not rely on personal connections. The data product owner organizes professional confirmations and decides release after necessary confirmations are in place, but cannot sign off on business rules, source data facts, or usage authorizations on behalf of others. Contract risk identification is also affected by models, processes, and manual handling. The data product owner is responsible for data supply and improvement under the agreed purpose; the business application owner is responsible for application operation and actual handling; the two are linked via task metrics and consumption records.

Division of Labor Must Land on Judgments and Deliverables

The coarse division "business proposes requirements, data processes, algorithm uses data" is insufficient. The real sticking points are whether each person's deliverables are sufficient for the next responsible person to make a decision.

Responsibility Roles, Judgments, and Required Artifacts

Role                          | Must‑Be‑Responsible Judgments                              | Evidence or Artifacts to Deliver
------------------------------|------------------------------------------------------------|--------------------------------------------------------------
Data Product Owner            | Purpose, priority, version scope, continue investment, exit| Product contract, requirements prioritization, release decision, consumer list
Business Owner & Experts      | Risk definition, applicability scope, exceptions, arbitration| Rule versions, boundary cases, arbitration conclusions; expert opinions confirmed by authorized owner
Source Data Business & Eng.   | Former confirms facts & source; latter guarantees faithful, reproducible processing| Source confirmation, snapshots, lineage, processing records, anomaly lists
Algorithm & Application Teams | Whether data improves target task; whether application can consume per agreement| Comparative evaluations, failure samples, consumption constraints, integration & rollback verification
Quality & Evaluation Owner    | Whether acceptance evidence is credible; whether evaluation stays independent| Spot‑check reports, independent evaluation conclusions, defect grading, re‑verification results
Governance, Security, Compliance| Governance confirms registration & responsibility completeness; security confirms access control; compliance confirms usage constraints| Required confirmations assigned to individuals, retaining verification bases, policies, restriction lists
Data Operations Owner         | Whether issues are ticketed; whether changes are notified to consumers| Incident ledger, response records, migration receipts, closure evidence

The table shows responsibility roles, not requiring seven separate departments. However, production and final quality acceptance of the same high‑risk data should be assigned to different people, avoiding the delivery side proving itself qualified. Algorithm teams can propose difficult‑case requirements but cannot unilaterally modify evaluation answers and declare improvement effective.

CCSA TC601 "High‑Quality Dataset Practice Guide (1.0)" discloses a medical case: double‑blind annotation consistency exceeded 95%, experts reviewed 10% samples, and review‑result annotation accuracy reached 98%+. It provides a layered quality‑inspection project reference; these numbers cannot directly become project thresholds nor derive a universal responsibility matrix.

Every Signature Layer Must Answer a Specific Question

RACI assigns responsibility: R = executes, A = ultimately accountable, C = consulted, I = informed. The "result" for each item must be explicit. "Dataset launch" comprises decisions on business rules, annotation quality, task effectiveness, usage constraints, and release operations. Each decision should have only one A; professional confirmations serve as prerequisites and are recorded separately; co‑signing must retain individual accountability.

RACI Matrix for Seven Decision Objects

Decision Object                     | Execute (R)                                      | Ultimately Accountable (A)                     | Required Evidence Before Signing
------------------------------------|--------------------------------------------------|------------------------------------------------|--------------------------------------------------------------
Project goals & resource commitment | Data Product Owner                               | Business Sponsor                               | Task boundaries, benefit hypotheses, budget, ongoing maintenance plan
Risk rules & exceptions finalization| Business experts, branch rule contacts           | Authorized business owner for that scope       | Formal basis, effective scope, dispute resolution conclusions
Annotation batch acceptance         | Vendor or internal annotation team submits; internal QA re‑verifies| Internal Quality Owner                         | Frozen specification, spot‑checks, arbitration & rework results
Candidate version release           | Data engineering gathers evidence; platform team executes release| Data Product Owner with release authority      | Business, quality, task effectiveness, usage control confirmations; rollback plan
Data version change approval        | Data engineering, quality, data operations       | Data Product Owner with change authority       | Impact analysis, affected parties re‑confirm, version validation, notification plan
Single consumer application switch  | That application's algorithm, engineering, ops   | Business Application Owner with switch authority| Integration evaluation, migration & rollback verification, switch plan
Retirement closure                  | Data operations, engineering, consumers, vendors | Data Product Owner with retirement authority   | Business exit confirmation, consumer unbinding, retention & disposal requirements, execution receipts

For example, the algorithm team submits an effectiveness report, the independent evaluation owner verifies, the business owner confirms the task threshold, and the platform team executes release per the approved result. Each application owner separately approves their own switch, confirms migration completion after execution; the data product owner collects receipts and tracks overall progress.

C and I must also be specific. Rule changes require consulting affected‑region business owners, algorithm, and governance teams; version switches must notify registered consumers and obtain receipts when migration is needed. Receiving a notice does not mean migration is done.

Signatures should record object & version, scope, conclusion, basis, limitations, time, and authorized identity, using controlled approval records. After a substantive version change, old signatures cannot automatically cover the new object.

Headquarters and Branch Disagree — Who Arbitrates

Returning to the exemption dispute: the data product owner first organizes confirmation of whether the branch provides a formal approval document, local applicable rules, or a long‑standing operational habit. The branch business owner confirms contract type, original text, and local basis; the HQ‑authorized risk rule owner judges the exemption and its scope; matters beyond authority escalate along the authorization chain. Data engineering checks for missing attachments — business disagreements cannot be resolved by modifying fields.

During arbitration, data operations per plan suspends disputed‑sample deterministic label release, retaining a "pending arbitration" status. Affected online applications are restricted to manual handling per the business application owner's authorization. Other data ranges continue supply only if they are isolatable, pass evaluation, and usage permits, as decided by the data release owner.

Assume arbitration confirms: a contract type is exempt within a specified period, while the liability clause retains its risk label. The business owner signs the conclusion; the data product owner organizes rule and label updates; engineering rebuilds affected batches; quality re‑verifies.

Training data updates do not automatically fix deployed models. Algorithm and application teams must verify whether retraining or application adjustment is needed, and complete the update or stop affected usage per the application release process. Only after new data version acceptance and consumer disposal are both complete can the issue be closed; incomplete migrations retain responsible persons and usage restrictions. Historical versions retain their original basis; new conclusions cannot be silently back‑ported.

Pre‑agreed acceptance time limits, arbitration time limits, and escalation contacts for overdue cases are required. Cross‑department disputes that exceed the time limit should execute approved measures — suspend, reduce scope, or transfer to manual — not treat silence as consent.

Headquarters Provides Common Capabilities; Business Domains Retain Business Decisions

When the group builds multiple data products, collaboration can be organized at three levels:

AI CoE (AI Center of Excellence) : maintains shared methods, evaluation specifications, tool selection principles, and cross‑domain escalation mechanisms. It can drive a unified definition of "what counts as evidence" but should not define all standard answers for every business domain.

Platform Team : responsible for data registration, pipelines, permission access, audit, and observability. Platform failures are handled by the platform team; formal rule conflicts still go to the business side with authority to interpret rules.

Business Domain Teams : hold data products, responsible for the business meaning of common rules and domain‑specific usage. Group‑level common products have an HQ‑designated owner; branches confirm local facts and applicability conditions. If a branch forms an independent data product with different usage, it should have a separate owner and contract — not just copy HQ files and continue sharing one responsibility name.

FDE (Field Data Engineer) — engineers who go on‑site to drive engineering implementation — can turn "branch discovers false positive" into reproducible samples, responsibility objects, and platform improvement needs. They can organize joint debugging and handover, but cannot default to rule approval authority or become permanent receivers just because they know the site best. If they also act as data product owner, they need separate explicit authorization, maintenance resources, and succession arrangements.

Outsourcing Can Deliver Samples; Internal Must Be Able to Accept

Procurement handles commercial arrangements; business handles rules; internal quality owner handles batch acceptance; data product owner organizes version decisions based on that. Before ordering, agree on:

Scope & Version : annotation units, specification version, delivery batches, evidence fields, question escalation, and refusal‑to‑label conditions.

External Data Sources : vendor provides source and usage‑license evidence; internal compliance & authorization owner confirms applicable usage; buying files does not grant all usage rights.

Acceptance Method : who samples, how to cover high‑risk categories, how to grade defects, when to reject entire batch, who executes independent re‑verification.

Confidentiality & Tool Usage : personnel access, external distribution limits, tool & model usage restrictions, subcontracting constraints, operational audit trails.

Rework & Change Billing : rework due to errors under frozen rules vs. re‑labeling after client changes rules handled separately; disputes retain the version and judgment basis at the time.

Exit & Handover : deliver data and process records, revoke access, obtain evidence of agreed data disposal, confirm internal team can continue maintenance.

Contract risk sample acceptance cannot settle solely on overall accuracy. High‑risk clauses and exception samples need independent acceptance requirements; ordinary sample volume cannot offset critical errors. Supplier's undecidable items should be received by the internal business owner, not forced to guess a label for delivery completeness.

Supplier sign‑off or payment records cannot replace internal professional acceptance.

Operational Meetings Must Output Decisions; Handovers Must Have a Receiver

Data operations organizes fixed regular meetings around pending decisions. Inputs: high‑consequence errors & versions, overdue disputes, rule changes, consumer migration status, supplier defects, new investments and unit task costs. Each item must carry responsible person, impact scope, and the decision needed. Outputs at minimum: continue supply or pause, next‑batch priority, who is responsible for supplementary evidence or fix, completion deadline, acceptor, and closure conditions. Emergency events are handled per plan immediately, not waiting for the meeting to end.

When an exemption dispute enters the meeting, submit unclosed items and pending decision requests — e.g., whether migration delay is acceptable, how many expert hours for supplementary verification.

When personnel leave or a supplier exits, hand over unclosed issues, versions & consumers, pending authorizations, release and on‑call permissions, confirmed by the successor. If no one takes over, reduce supply scope or arrange pause — do not just keep the old name in the registry.

Small Teams Also Need Divided Responsibilities, But Not All Positions

For single‑purpose, low‑risk, low‑frequency‑release data products, an existing product manager can double as owner, an engineer as operations, using one responsibility table and controlled approval records. Independent review can be provided by an adjacent team, not necessarily a new quality department.

As cross‑region rule disagreements, high‑risk uses, supplier count, and consumer relationships increase, add dedicated operations, specialized QA, and cross‑domain arbitration arrangements. The trigger point should be when existing mechanisms can no longer complete acceptance, arbitration, and verification per agreement — not when data volume crosses a certain number.

This arrangement has costs: experts reserve hours, independent acceptance consumes resources, layered confirmations increase wait times. Pre‑approved rules can let low‑risk routine changes auto‑execute, concentrating human effort on rule changes and high‑consequence issues.

Effectiveness is measured by: whether disputes get evidence‑based arbitration faster, critical defects recur, changes can be notified and implemented to consumers. If only more signatories are added but problems still have no receiver and no re‑verification, the decision and authorization split should be redesigned — not simply add more co‑sign columns.

Summary

To judge whether a high‑quality dataset has someone responsible, trace from an online error: who receives the ticket, who has arbitration authority, who arranges the fix, who independently verifies, who confirms the consumer has handled it. If any step can only answer "everyone looks together," responsibility has not landed on an actionable person.

Next article discusses another concrete boundary: data legally obtained — can it be used for training, evaluation, retrieval, and long‑term retention? Source, license, and usage restrictions need separate confirmation.

References

Source: CCSA TC601 "High‑Quality Dataset Practice Guide (1.0)", medical scenario, PDF page 31 (printed page 24). The numbers are the guide's specific project results; the responsibility table, signature matrix, and contract risk scenario are designed by this article, not universal templates from the guide.