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