テキスタイルDPPのためのCIRPASS-2検証スタック
繊維 DPP を「文書があるだけ」ではなく検証可能にするのは何か？CIRPASS-2 互換の Reeco スタックは、schema・model・semantics・繊維ロジック・mass-balance 制御・conformity credentials・traceability events の7層バリデーションを適用し、パスポート発行前に本番データと照合して claim を確認する——発行後ではない。
エグゼクティブサマリー
テキスタイルDPPコンプライアンスは、データが収集されるだけで検証されない場合に失敗します。
CIRPASS-2互換のReecoスタックは7つの検証レイヤーを適用します：SCH、MDL、SEM、TXT、RCO、DCC、DTE。
マルチレイヤースタックが必要な理由
ほとんどのプラットフォームは「ドキュメント存在」で停止します。これは製品レベルのクレーム整合性を証明しません。
堅牢なDPPワークフローは、構造、セマンティクス、テキスタイルロジック、およびマスバランスの一貫性を検証する必要があります。
レイヤー概要
| レイヤー | スコープ | 典型的な出力 |
|---|---|---|
| SCH | スキーマ適合性 | 構造エラー（例：SCH001） |
| MDL | モデル整合性 | 欠落フィールドまたは不正形式のオブジェクト（MDL*） |
| SEM | セマンティック一貫性 | 矛盾する意味（SEM*） |
| TXT | テキスタイルロジック | テキスタイル固有のクレーム矛盾（TXT*） |
| RCO | Reeco制御レイヤー | ハード業務制御（RCO003マスバランス） |
| DCC | 認証化 | TC をUNTP DCC 0.6.1としてエクスポート |
| DTE | トレーサビリティイベント | バッチフローをTransformationEventとしてエクスポート |
検証パフォーマンスポスチャー
構造化ペイロードの決定論的チェックの場合、コア検証はミリ秒単位で実行できます（参考ベンチマーク：軽量実行で約1.6 ms/リクエスト）。
これは運用上関連性があります：制御はサブミッション時に同期的に実行でき、ラベル発行前に実行できます。
競合他社が通常見落とすもの
| 機能 | 典型的なDPP UI | Reecoスタック |
|---|---|---|
| ファイルアップロード | はい | はい |
| スキーマチェック | 部分的 | 完全なSCH + MDL |
| テキスタイルセマンティックルール | まれ | SEM + TXT |
| ハードマスバランスブロック | まれ | RCOハードブロック |
| UNTP DCCエクスポート | まれ | ネイティブ |
| UNTP DTEエクスポート | まれ | ネイティブ |
実装ノート
エンドポイント
POST /api/v1/dpp/validatePOST /api/v1/dpp/export/dccPOST /api/v1/dpp/export/dcc/jwtPOST /api/v1/dpp/export/dte
仕様バージョニング
- UNTPリファレンス：
0.6.1 - エビデンスモデル：W3C Verifiable Credentials
FAQ
スキーマ検証だけでコンプライアンスに十分ですか？
いいえ。スキーマチェックは形状を確認しますが、サステナビリティクレームの真実性は確認しません。
RCOは何が異なりますか？
RCOは、認証済み材料が枯渇したときのマスバランスブロックなどのハード運用制御を追加します。
DCCとDTEを同じスタックに含める理由は何ですか？
エクスポート可能なエビデンスを伴わない検証は、相互運用可能なコンプライアンスとは言えないためです。