Your labels should leave with you.

A document AI project can change vendors in a week and still spend a year starting over. The models move. The API client moves. The labelled examples do not, because nobody decided who owned them, what an export had to contain, or whether reviewer decisions were part of the deliverable.

The expensive asset is not the annotation interface. It is the agreed record of what the document means. Every accepted field, rejected suggestion, document class, bounding region and reviewer decision narrows the space of future mistakes. Treating that record as disposable implementation exhaust gives away the part of the system that becomes more valuable with use.

This is a narrower question than the data flywheel. A flywheel asks how production corrections improve a running system. Dataset ownership asks what the customer can possess, inspect and carry elsewhere before, during and after that loop. One is about learning velocity. The other is about control of the evidence that made learning possible.

Define the asset before arguing about ownership

“The training data belongs to the customer” sounds reassuring and resolves almost nothing. A usable ground-truth dataset is not one folder of PDFs and one CSV of final values. It is a connected record with at least five layers:

• Source identity — a stable document and page identifier, content hash, class, tenant boundary and the lawful source of the sample.
• Annotation payload — fields, normalised values, regions, relationships, table structure and an explicit representation of absence.
• Schema version — the definition each label was judged against, including type, cardinality, validation rule and deprecation history.
• Decision provenance — who or what proposed the value, who reviewed it, what changed and when the decision became accepted.
• Evaluation partition — train, validation and held-out test membership, fixed so an export does not quietly contaminate the benchmark.

Omit any one of these and the export becomes harder to reuse. Values without source hashes cannot be tied back to evidence. Labels without schema versions are ambiguous after a field changes meaning. Final answers without review history erase the distinction between an untouched model suggestion and a correction made by a qualified operator.

Ownership needs three separate rights

Contracts often compress possession, use and portability into one sentence. They are different controls and should be reviewed separately.

These controls also need to distinguish customer data from provider tooling. A customer can own its documents, labels and reviewer decisions without claiming the provider's generic annotation software, base model or orchestration code. Precision protects both sides better than a broad sentence neither side can operationalise.

Put the export obligation in executable language

The following is an engineering-oriented example for counsel to adapt, not legal advice:

Customer Ground Truth means Customer Content together with annotations, normalized values, document and page identifiers, evidence coordinates, schema versions, reviewer decisions, timestamps and train/validation/test assignments created for Customer. Customer owns Customer Ground Truth. During the term and for 30 days after termination, Provider will make it available on request in the documented export format, without proprietary encryption, within 5 business days. The export will include a manifest, content hashes, schema definitions and relationship keys sufficient to associate every annotation with its source evidence.

The useful words are not the ownership declaration. They are the inventory, time boundary, format constraint and test of sufficiency. They turn an abstract right into something an acceptance test can evaluate.

Add the boundaries that match the actual service: whether raw documents may be exported, whether personal data must be redacted, what happens under legal hold, which reviewer identifiers are pseudonymised, and whether provider-generated synthetic examples are included. The right answer depends on the deployment. Leaving the question undefined does not.

Choose an export format another team can open

A portable package does not need a universal standard. It needs a documented, lossless structure built from ordinary formats. One workable shape is a directory of original or policy-approved source files, newline-delimited JSON annotations, JSON Schema definitions and a manifest:

{
  "document_id": "doc_01842",
  "source_sha256": "…",
  "schema_version": "invoice-3.2",
  "split": "held_out_test",
  "annotations": [{
    "field": "invoice_total",
    "value": "1842.75",
    "page": 2,
    "evidence": {"x": 0.61, "y": 0.78, "w": 0.19, "h": 0.04},
    "status": "accepted",
    "proposed_by": "model:v7",
    "reviewed_by": "reviewer:pseudonymous-31",
    "reviewed_at": "2026-08-18T14:42:03Z"
  }]
}

Coordinates should state their unit and origin. Relationships should use stable keys rather than array position. Tables need row, column and span information, not only flattened cell text. Character encoding, timestamp format and null semantics belong in the specification. If two independent teams cannot reconstruct the same evaluation set from the package, it is not yet portable.

Price annotation by accepted work, not clicks

“Cost per labelled document” is convenient and usually misleading. One document may contain five scalar fields. Another contains three pages of line items, nested tables and cross-page relationships. The unit that travels with the asset is the accepted annotation.

Track cost per accepted field as a minimum:

cost per accepted field =
  (review labour + adjudication + annotation operations + allocated tooling)
  / accepted fields that pass quality control

Report the denominator beside the result. A lower cost can mean better pre-annotation, or it can mean the team stopped labelling difficult fields. Segment by field type and document class so those cases remain visible. For tables, add accepted cells and accepted relationships. For classification, use accepted document decisions. Do not force unlike work into one number merely to produce a dashboard tile.

The number is most useful as a planning instrument. If a new field requires 8,000 accepted examples and the observed cost is $0.18 per accepted field, the initial annotation budget is $1,440 before adjudication and expected rework. That is a transparent assumption, not a promise. Publish the expected disagreement rate and the quality threshold beside it.

Provenance is what makes the dataset defensible

An accepted answer without provenance is a value. An accepted answer with provenance is evidence. The difference matters when a regulator, customer or model owner asks why the label changed.

Keep an append-only decision trail even if the operational view shows only the latest state. Record the proposal, review action, reason code, prior value and schema in force. Use pseudonymous reviewer identifiers where direct identity is unnecessary, and keep access to the mapping separate. If an automated rule performs the adjudication, name the rule and version it.

Provenance also reveals quality problems that accuracy alone hides: one reviewer overturning peers disproportionately, one field with persistent disagreement, or a model version whose suggestions increase review time despite stable final accuracy. Those are dataset findings, not merely workforce metrics.

Test portability before the exit event

An export clause first exercised after termination is an untested recovery plan. Run a portability drill while the relationship is healthy:

• Request a bounded export — one document class, one schema version and all associated review history.
• Validate integrity — recompute hashes, resolve every source reference and reject orphan annotations.
• Rebuild a metric — reproduce one held-out evaluation result using only the export and its documentation.
• Import elsewhere — load the package into a neutral script or a second annotation tool without vendor assistance.
• Measure elapsed time — record how long the request, delivery, validation and import took against the contract.

The drill finds the practical lock-in: undocumented enums, missing source files, coordinates tied to a proprietary renderer, reviewer events stored outside the export path. It also gives the provider a precise defect to fix before the relationship is under pressure.

Keep the held-out set out of the flywheel

Portability does not mean every labelled example should train the next system. The held-out set is valuable because it has not been used to choose prompts, thresholds or models. Preserve its partition in the export and restrict who can move examples across the boundary.

This is the sharp distinction from a data flywheel. Production corrections can feed improvement after governance checks. Held-out ground truth measures whether the improvement was real. Mixing them makes the curve look better while weakening the evidence behind it.

The durable advantage is not a file count. It is a corpus whose rights are explicit, whose decisions can be traced, whose quality can be reproduced and whose format does not depend on the system that created it. That asset lowers the cost of the next model, the next vendor and the next audit. If the labels cannot leave, the customer never really had that advantage.