Fidelity Validation

Fidelity Validation

Sanitization removes source code identifiers. But aggressive sanitization can also remove behavioral detail that an implementor needs. This skill detects information loss.

Why This Exists

The sanitization pass rewrites raw specs into output specs. Each rewrite risks:

• Dropped behaviors: A feature or edge case described in the raw specs that doesn't appear in the output specs
• Lost constants: A numeric threshold, timeout, limit, or size that was accidentally removed or changed during rewriting
• Diluted precision: A specific behavioral rule replaced with vague language ("the system handles errors" instead of "the system retries with configured backoff — N attempts, base delay, maximum delay, and jitter")
• Missing decision trees: A conditional behavior with multiple branches that was simplified to just the happy path
• Dropped error conditions: Error handling that was described in the raw specs but omitted from the output specs
• Feature gaps: Entire features or sub-features present in the raw specs but missing from the output domain spec

When to Run

Run this AFTER:

1. Sanitization (Layer 5) is complete
2. Contamination audit (Layer 6) passes — output specs are confirmed free of source identifiers
3. All remediation/rewriting rounds are done

This is the final quality gate before handing the output to the implementer.

The Principle

Every behavioral claim in the raw specs must have a corresponding claim in the output specs — with equal or greater precision.

The output specs may use different words (that's the point of sanitization), but it must convey the same behavior. If the raw spec says "retry N times with a specific base, cap, and jitter", the output specs must say the same — not just "the system retries on failure."

Process

Phase 1: Build the Source Claim Inventory

For each raw module spec (workspace/raw/specs/modules/*.md), extract:

1. All numeric constants — timeouts, limits, sizes, counts, thresholds, intervals, percentages
2. All behavioral rules — "when X happens, the system does Y"
3. All error conditions — what errors occur and how they're handled
4. All state transitions — state machines, mode changes, lifecycle events
5. All decision trees — if/else branches, priority orders, cascades
6. All features — distinct capabilities described

Write this inventory to workspace/raw/audit/fidelity-inventory.md.

Phase 2: Cross-Validate Against Output

For each item in the source claim inventory, search the corresponding output domain spec(s) for a matching behavioral claim.

Match criteria:

• The output specs describes the same behavior (possibly with different words)
• Numeric constants match exactly (no rounding, no approximation)
• Decision branches are all present (not just the happy path)
• Error conditions are all present
• State transitions are complete

Report format per item:

### [RAW-SPEC: section-name] Claim: "description of the behavioral claim"
- Constant/Rule/Error/State/Decision/Feature
- Raw value: [exact value from raw specs]
- Output location: [file:section where it appears in the output] or MISSING
- Output value: [exact value from output specs] or N/A
- Status: MATCH | WEAKENED | MISSING | CHANGED
- Notes: [if WEAKENED/MISSING/CHANGED, explain what was lost]

Status definitions:

• MATCH: Output spec conveys the same behavior with the same precision
• WEAKENED: Output spec mentions the behavior but with less precision (e.g., "retries on failure" instead of "retries with specific backoff params")
• MISSING: Output spec does not mention this behavior at all
• CHANGED: Output spec describes different behavior for the same scenario

Phase 3: Also Validate Cross-Cutting Artifacts

Repeat Phase 2 for:

• Journey specs: raw journeys vs output journeys
• Contracts: raw contracts vs output contracts
• Protocol specs: raw protocols vs output protocols
• Test vectors: raw test vectors vs output test vectors (constants must match)
• Acceptance criteria: raw ACs vs output ACs (criteria must be present)