What Is Data Lineage for AI Training Data?

A trained model carries whatever its data carried. If a buyer cannot say which contributor, site, consent basis and processing pass sit behind an episode, then a legal question, a quality complaint or a deletion request becomes a search through files instead of a lookup. Lineage is what turns a pile of footage into a dataset a legal team and an ML team can both sign off on, and it matters more as the same collection is delivered in repeated batches.

The site does not use the word lineage or offer a lineage tool. It states the records a lineage would be built from: a signed release before capture, a six-checkpoint consent chain, per-episode identifiers in meta.json, consent artefact IDs listed per episode in a per-batch data card, and a reject log. These are collected fast, on demand and to a written skill spec. Any lineage graph or audit trail beyond those records is not stated.

Data lineage is the history of a piece of data: where it originated, what happened to it on the way, and where it ended up. In analytics it usually means tracing a number in a report back through the tables and transformations that produced it. The idea is the same for a training dataset, only the objects are episodes of video and sensor streams rather than rows.

Two properties make a lineage useful. It is specific, meaning it points at one episode or one batch rather than at the dataset as a whole. And it is checkable, meaning a buyer can verify a claim against a record rather than take it on trust. A statement that all data is consented is an assertion. A consent artefact ID tied to each episode is a lineage.

For egocentric training data the useful links run from the contributor to the delivered file. They are the person and the signed release, the site and jurisdiction of capture, the processing applied to the footage, the checks the episode had to clear, and the specification and batch it belongs to. Each link answers a different buyer question: can we use it, was it cleaned, was it checked, and is it the same as last time.

This page uses lineage as the general term. The site speaks of provenance, consent chain, data card and versioning, and the sections below map each to the lineage question it answers. The table that follows sets out each stage against what the site states.

Provenance is the record of where data came from and how it got from capture to delivery. Lineage is the broader habit of keeping that trail unbroken and traceable through every later step, including processing and versions. In practice the two overlap heavily, and this site states provenance rather than lineage.

A consent chain is one link in that trail, the documented proof that each person granted the rights the buyer needs. A data card is the per-batch summary that carries several links together: jurisdictions of capture, the consent basis, the de-identification pass and the reject log. The second table compares the four terms side by side.

The site documents a set of identifiers in each episode meta.json. An episode_id ties every artefact for one episode together. A skill_id and site_id say what task and location it was captured for. A participant_id links it to its signed release without exposing identity. A license field holds the terms attached to that episode, and reject_flags records why an episode was excluded, if it was.

At batch level, consent artefact IDs are listed per episode in the data card at delivery, alongside the jurisdictions of capture. Together these let a buyer walk from a delivered file to its release and its capture jurisdiction. The third table lists each field and the lineage question it helps answer.

The consent chain has six checkpoints. Before capture a written release is signed, identity is verified and the rate is agreed. At capture, site permission is on file and bystander signage is posted where the site is semi-public. At ingest, faces, plates and screens are detected automatically and speech is scrubbed of identifiers. At review, a human confirms no un-consented person is identifiable in any frame. At delivery, consent artefact IDs are listed per episode in the batch data card. After delivery, withdrawal requests are honoured for undelivered footage, and delivered footage cannot be recalled.

The site states that any break at any checkpoint discards the footage instead of downgrading it. For lineage this matters, because a discarded clip leaves no ambiguous record behind: an episode either completed the chain or is not in the dataset.

Versioning answers the question of which dataset you actually hold. The site describes a version as five things that each carry their own record: the written skill spec, the batch, the data card, the episode schema and the delivery format. Tracking a version means knowing where each lives and keeping them aligned when one changes.

In an ongoing collection, the spec is described as additive: new tasks or environments are added as new cells rather than rewriting the document, so an earlier batch stays valid against the spec version it was captured under. The site also says every batch passes through the same calibration, sync and label review. That consistency is what lets a buyer treat two batches as comparable rather than just newer. Version numbers themselves are not stated.

The site does not state a lineage tool or platform, a graph of transformations, checksums of delivered files (sha256 checksums are stated at ingest only), an audit log a buyer can query, a third-party audit of its records, or any certification or compliance attestation. It states one retention rule, that field copies are deleted after acceptance, and no other retention periods, so how long any record is kept is not stated. The privacy and data processing pages are drafts, and the signed agreement controls.

It also does not state a de-identification version number or timestamp in the glossary or provenance pages beyond what the batch data card is described as listing. Read this page as general information, not legal advice, and ask for a data card from a real batch if your reviewers need to see the records themselves.

Custom and on-demand collections are scoped by a written skill spec, so the tasks, settings and fields are written down before capture. If your reviewers need specific lineage records, list them in the request: the per-episode identifiers, the consent artefact IDs in the data card, the jurisdictions of capture and the reject log. Request a custom dataset and say which of these your procurement or legal team will ask for.

What is data lineage?

The traceable record of where a dataset came from and what happened to it between capture and delivery. For training data it links an episode to its contributor, consent, processing, checks and version.

Is data lineage the same as data provenance?

They overlap heavily. Provenance is the record of where data came from and how it reached the buyer. Lineage is the broader practice of keeping that trail traceable through later steps and versions. The site states provenance rather than lineage.

Does Firsthand provide a data lineage tool or audit log?

No. The site states no lineage tool, platform or queryable audit log. It states the records a lineage would use: per-episode identifiers, consent artefact IDs in a per-batch data card, jurisdictions of capture and a reject log.

How can I trace an episode back to its consent record?

Each episode carries a participant_id that links to its signed release, and consent artefact IDs are listed per episode in the batch data card at delivery. Ask for a data card from a real batch to see the format.

Does the site state a certification or third-party audit of its records?

No. The site states no certification, compliance attestation or third-party audit. The signed agreement controls, and this page is general information, not legal advice.

Can I request specific lineage records in a custom dataset?

Yes. Custom and on-demand collections are scoped by a written skill spec. Request a custom dataset and list the records your reviewers need, such as per-episode identifiers, the data card fields and the reject log.