# Trace Commitment Identity Policy Evaluation
## Current Implementation (v0.1)
**Formula**: `C_trace = H(sorted(C_span_i, "|"))` (set-only, content hash)
**Behavior**:
- Two traces with identical span sets produce the same commitment, regardless of `trace_id`
- Order-independent (spans sorted before hashing)
- Versioned (adding spans creates new commitment)
## Proposed Change (Identity-Bound)
**Formula**: `C_trace = H(canonicalize({trace_id, span_commitments:[...]}))` (identity-bound)
**Behavior**:
- Includes `trace_id` in canonical form
- Prevents aliasing: two traces with identical spans but different origins have different commitments
- Stronger provenance guarantees
## Evaluation
### Pros of Identity-Bound
1. **Prevents Aliasing**: Two traces with identical spans but different origins no longer collide
2. **Enforces Per-Trace Uniqueness**: Each trace instance has a unique commitment
3. **Stronger Provenance**: Commitment binds to specific workflow instance, not just content
### Cons of Identity-Bound
1. **Breaking Change**: All existing trace commitments will change
2. **Migration Required**: Existing systems using trace commitments will need updates
3. **Content Deduplication**: Cannot use commitment to detect duplicate work sets across traces
### Current Use Cases Analysis
**Set-Only (Current)**:
- Useful for: Content deduplication, detecting identical work sets across different traces
- Problem: Two different workflows with same spans collide
**Identity-Bound (Proposed)**:
- Useful for: Audit trails, settlement, provenance tracking
- Problem: Cannot deduplicate identical work sets across traces
## Recommendation
**Defer to v0.2** with proper migration plan:
1. **Current v0.1**: Keep set-only as primary commitment
2. **v0.2 Enhancement**: Add optional `trace_identity_root` field alongside `commitment` (content root)
3. **Migration Path**:
- v0.1 receipts continue to work
- v0.2+ receipts can include both `commitment` (set-only) and `trace_identity_root` (identity-bound)
- Systems can migrate gradually
## Rationale
- v0.1 is stable and in use
- Breaking changes require careful migration planning
- Dual-field approach provides flexibility for both use cases
- Can be implemented as additive change in v0.2
## Decision
**Status**: Deferred to v0.2
**Action**: Document current behavior, plan v0.2 enhancement with dual-field approach