# Evaluation dataset lineage／ownership／provenance contract

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-741-evaluation-dataset-lineage-ownership-provenance-contract
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-741-URL-6E48BCC4A04D, EVD-EA-741-URL-D3595FE80F52, EVD-EA-741-URL-FBB23EC2F8C6, EVD-EA-741-URL-C27529936E9E, EVD-EA-741-URL-5E2E7DFF8940, EVD-EA-741-URL-96B69F4F00C3, EA-741-CURRENT-APPROVAL, EA-741-CURRENT-BODY-READBACK
UNKNOWN_IDS: EA-741-UNKNOWN-01
OPS_IDS: none

## Summary
「評価データは、dataset/versionの識別子とdigestだけでなく、source・derivation・作成/承認責任・rubric・split・利用runを追跡し、後から評価結果の再現と影響範囲の逆引きができるようにする。PROV-O、MLflow、OpenLineage等はその一部を実装するための基盤になり得るが、権利・同意・削除・case-level approvalまで自動的に保証するものではない。」

## Current judgment
「評価データは、dataset/versionの識別子とdigestだけでなく、source・derivation・作成/承認責任・rubric・split・利用runを追跡し、後から評価結果の再現と影響範囲の逆引きができるようにする。PROV-O、MLflow、OpenLineage等はその一部を実装するための基盤になり得るが、権利・同意・削除・case-level approvalまで自動的に保証するものではない。」

## Scope
Evaluation dataset lineage／ownership／provenance contract

## Confirmed

## UNKNOWN
- EA-741-UNKNOWN-01: - case単位で保持すべきprovenance粒度は、データ種別・契約・privacy要件・再評価コストに依存します。
- dataset digestのcanonical serialization方式は実装ごとに異なり、ツール横断の単一標準値は確定できません。
- consent、copyright、database right、個人情報削除等の法的要件はjurisdictionと契約条件に依存します。
- LLM生成・synthetic eval caseでは、生成model/version/prompt/source groundingをどこまで保存すべきかはrisk tierごとに決める必要があります。

## Evidence
- EVD-EA-741-URL-6E48BCC4A04D (RESEARCH): W3C, PROV-O: The PROV Ontology: — https://www.w3.org/TR/prov-o/
- EVD-EA-741-URL-D3595FE80F52 (RESEARCH): MLflow, Dataset Tracking: — https://mlflow.org/docs/latest/ml/dataset/
- EVD-EA-741-URL-FBB23EC2F8C6 (RESEARCH): MLflow, `mlflow.data` API: — https://mlflow.org/docs/latest/api_reference/python_api/mlflow.data.html
- EVD-EA-741-URL-C27529936E9E (RESEARCH): OpenLineage, Object Model: — https://openlineage.io/docs/spec/object-model/
- EVD-EA-741-URL-5E2E7DFF8940 (RESEARCH): OpenLineage, Lineage Dataset Facet: — https://openlineage.io/docs/spec/facets/dataset-facets/lineage/
- EVD-EA-741-URL-96B69F4F00C3 (RESEARCH): OpenLineage, Ownership Dataset Facet: — https://openlineage.io/docs/spec/facets/dataset-facets/ownership/
- EA-741-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応
- EA-741-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合

## Failure / limits
評価datasetにlineage contractがないと、同名datasetの中身が変わっても評価結果が同じ系列として比較される、annotation rubric改訂後のcaseが旧版へ混入する、削除要求を受けたsource由来caseを逆引きできない、第三者データの利用条件が不明なまま再配布する、評価runから使用datasetを再構成できない、といったfailureが起こります。

一方、lineageを細かく記録すれば自動的に品質が上がるわけでもありません。誤ったsource URI、再現不能な変換、owner名だけの形骸化、hash対象範囲の不一致、case-level lineage欠落があれば「記録がある」だけで追跡可能性は成立しません。provenance graphの存在と、証拠としての完全性・正確性は分けて監査します。
## Failure / limits
content digestは同一性確認に有効ですが、hash algorithm、serialization、row order、normalization、excluded fieldsが異なれば比較できません。digest contractを固定しない限り「hashが違う＝意味のあるdataset変更」とは限りません。

source lineageが追えても、元source自体が誤っている、権利情報が更新されていない、annotation rationaleが失われている場合があります。また、OpenLineage等の自動収集はpipelineで観測できる関係に強い一方、人手での選定理由・承認・同意・adjudicationは別途入力しなければ欠落します。
## Failure / limits
汎用provenance規格を法的適法性の証明として扱わず、digestを完全なdataset identityと断定せず、特定ツールのmetadata captureをcase-level governanceの代替としません。
## 要点と前提
評価データセットは「固定されたCSV」ではなく、どの原資料から、誰の責任で、どの変換・選別・注釈・承認を経て、どの評価runに使われたかを再現できる統制資産として扱う必要があります。評価結果だけを保存しても、datasetの版・由来・加工履歴・ownerが追えなければ、後から数値の差がモデル差なのかdataset差なのかを切り分けられません。

## 主要claim
W3C PROV-Oはprovenanceを `Entity / Activity / Agent` を中心に表し、`used`、`wasGeneratedBy`、`wasDerivedFrom`、`wasAssociatedWith`、`wasAttributedTo` などで、データ、処理、責任主体の関係を記述できます。評価dataset lineageでは、dataset/versionや個別caseをEntity、抽出・変換・注釈・adjudication・split生成をActivity、作成者・承認者・運用主体をAgentとして対応付ける設計が可能です。ただしPROV-Oは汎用provenance ontologyであり、評価データの同意・利用許諾・削除義務・PII分類などを自動的に満たす規格ではありません。

MLflowの現行Dataset Trackingはdatasetのname、digest、source、schema、profileを追跡し、runへdataset inputを記録できます。training / validation / testを別contextとして記録でき、evaluation workflowにもDataset情報を接続できます。これは「どのdatasetをどのrunが使ったか」の実装例として有用ですが、digestだけで法的権利、case単位のauthor/approver、annotation provenance、削除伝播まで証明できるわけではありません。

OpenLineageはDatasetとJob/Runを軸にlineage eventを表現し、dataset version、schema、lifecycle state、ownership、dataset/field lineage等のfacetを持ちます。現行仕様のLineage Dataset Facetは入力dataset/jobとfield-level dependencyを記録でき、Ownership Dataset Facetはownerとtypeを記録できます。これも汎用lineage transportであり、eval-specificなrubric version、case approval、consent basis等は追加metadataとして設計する必要があります。

## 運用上の意味・failure
評価datasetにlineage contractがないと、同名datasetの中身が変わっても評価結果が同じ系列として比較される、annotation rubric改訂後のcaseが旧版へ混入する、削除要求を受けたsource由来caseを逆引きできない、第三者データの利用条件が不明なまま再配布する、評価runから使用datasetを再構成できない、といったfailureが起こります。

一方、lineageを細かく記録すれば自動的に品質が上がるわけでもありません。誤ったsource URI、再現不能な変換、owner名だけの形骸化、hash対象範囲の不一致、case-level lineage欠落があれば「記録がある」だけで追跡可能性は成立しません。provenance graphの存在と、証拠としての完全性・正確性は分けて監査します。

## concrete control / implementation implication
最低限、dataset versionごとに `dataset_id / version_id / content_digest / source_locator / created_at / owner / approver / license_or_usage_basis / retention_or_deletion_state / transformation_recipe / parent_version / rubric_version / split_definition` を保持します。評価case単位では `case_id / source_or_derivation / creator_or_annotator / approval_state / created_at / last_modified / sensitivity_or_restriction / inclusion_reason` を追跡し、評価run側には `run_id / dataset_id / version_id / digest / model_version / evaluator_or_rubric_version / executed_at` を固定します。

変換・filter・dedup・augmentation・annotation・adjudication・split生成は「dataset metadataを書き換える」のではなく、入力versionから出力versionを生成したActivityとして記録します。元versionを上書きせず、derivation edgeとrecipe/versionを残します。datasetを修正した場合、同じversion_idのままdigestだけ変える運用を避けます。

ownerとapproverは分離可能にし、少なくとも「保守責任者」と「利用承認者」を同一概念に固定しません。ownership metadataは責任所在の手掛かりであり、著作権・個人情報処理の適法性・同意の存在を意味しないため、権利根拠は別fieldまたは別registryへ接続します。

削除・利用停止が必要なsourceを受けた場合、source→derived dataset version→case→evaluation runの逆引きができることを受入条件にします。既に実行済みrunの履歴は改竄せず、dataset versionをREVOKED/RETIRED等の状態にして将来利用を止め、必要な再評価対象を列挙します。

## 適用境界
PROV-O、MLflow、OpenLineageはいずれも用途が異なります。PROV-Oは汎用provenance model、MLflowはML lifecycle内のdataset/run tracking、OpenLineageはjob/run/dataset間のlineage event交換に強みがあります。どれか一つを採用すればeval governance全体が完成する、という関係ではありません。既存基盤に応じて概念モデル・実装metadata・transportを分離して選択します。

case-levelの完全な原文保存が禁止されるデータでは、lineageのために機密情報を複製しません。stable opaque identifier、restricted source locator、digest、access-controlled registryを使い、provenance store自体を新たな情報漏えい源にしない設計が必要です。

## counterevidence / limitations
content digestは同一性確認に有効ですが、hash algorithm、serialization、row order、normalization、excluded fieldsが異なれば比較できません。digest contractを固定しない限り「hashが違う＝意味のあるdataset変更」とは限りません。

source lineageが追えても、元source自体が誤っている、権利情報が更新されていない、annotation rationaleが失われている場合があります。また、OpenLineage等の自動収集はpipelineで観測できる関係に強い一方、人手での選定理由・承認・同意・adjudicationは別途入力しなければ欠落します。

## OPEN_UNKNOWN
- case単位で保持すべきprovenance粒度は、データ種別・契約・privacy要件・再評価コストに依存します。
- dataset digestのcanonical serialization方式は実装ごとに異なり、ツール横断の単一標準値は確定できません。
- consent、copyright、database right、個人情報削除等の法的要件はjurisdictionと契約条件に依存します。
- LLM生成・synthetic eval caseでは、生成model/version/prompt/source groundingをどこまで保存すべきかはrisk tierごとに決める必要があります。

## SAFE_WORDING
「評価データは、dataset/versionの識別子とdigestだけでなく、source・derivation・作成/承認責任・rubric・split・利用runを追跡し、後から評価結果の再現と影響範囲の逆引きができるようにする。PROV-O、MLflow、OpenLineage等はその一部を実装するための基盤になり得るが、権利・同意・削除・case-level approvalまで自動的に保証するものではない。」

## Sources / provenance
- W3C, PROV-O: The PROV Ontology: https://www.w3.org/TR/prov-o/
- MLflow, Dataset Tracking: https://mlflow.org/docs/latest/ml/dataset/
- MLflow, `mlflow.data` API: https://mlflow.org/docs/latest/api_reference/python_api/mlflow.data.html
- OpenLineage, Object Model: https://openlineage.io/docs/spec/object-model/
- OpenLineage, Lineage Dataset Facet: https://openlineage.io/docs/spec/facets/dataset-facets/lineage/
- OpenLineage, Ownership Dataset Facet: https://openlineage.io/docs/spec/facets/dataset-facets/ownership/

## 運用上の停止・確認条件
汎用provenance規格を法的適法性の証明として扱わず、digestを完全なdataset identityと断定せず、特定ツールのmetadata captureをcase-level governanceの代替としません。

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.