# テキスタイルDPPのためのCIRPASS-2検証スタック

## エグゼクティブサマリー

テキスタイル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/validate`
- `POST /api/v1/dpp/export/dcc`
- `POST /api/v1/dpp/export/dcc/jwt`
- `POST /api/v1/dpp/export/dte`

### 仕様バージョニング

- UNTPリファレンス：`0.6.1`
- エビデンスモデル：W3C Verifiable Credentials

## FAQ

### スキーマ検証だけでコンプライアンスに十分ですか？

いいえ。スキーマチェックは形状を確認しますが、サステナビリティクレームの真実性は確認しません。

### RCOは何が異なりますか？

RCOは、認証済み材料が枯渇したときのビランシオ・マッシコブロックなどのハード運用制御を追加します。

### DCCとDTEを同じスタックに含める理由は何ですか？

検証なしのエクスポート可能なエビデンスは相互運用可能なコンプライアンスではないためです。