validation-methodology

Validation Methodology

Specifications are claims. Claims require proof. This skill defines how the pipeline transforms claims into proof.

Acceptance Criteria Format

Every module spec receives formal acceptance criteria during Layer 4. Criteria use Given/When/Then format:

### AC-CONFIG-001: Config File Load
**Given** a valid config file exists at the documented path
**When** the application starts
**Then**
- The application reads every declared key from the file
- Unknown keys are logged as warnings, not errors
- Missing optional keys fall back to documented defaults

**Source:** official-docs, source-code, runtime-observation
**Confidence:** confirmed
**Priority:** P0
**Verification:** Automated test

ID Format: AC-{DOMAIN}-{NNN}

• {DOMAIN}: Short uppercase token for the behavioral domain (matches the spec's domain tokens — e.g., CLI, CONFIG, API, AUDIO, PARSER)
• {NNN}: Zero-padded three-digit sequence (001, 002, ...)
• IDs are immutable — retired, never reused

Field Rules

Given/When/Then:

• Use observable terms, not implementation details
• "Given a valid config file exists" not "Given the ConfigLoader is initialized"
• Each Then outcome must be verifiable without implementation internals
• Describe observable state, not UI mechanisms — "system rejects malformed input" not "error banner is visible." Criteria must be testable across any frontend platform.

Priority:

• P0: Must pass. Blocks pipeline. Implementation cannot ship without satisfying.
• P1: Should pass. Reported as warnings. Divergence requires documented rationale.
• P2: Nice to pass. Advisory.

Verification: One of the 5 methods below.

Output Location

workspace/raw/specs/validation/acceptance-criteria/
    _index.md                   # Summary with counts and links
    config-loading.md           # AC-CONFIG-001 through AC-CONFIG-NNN
    cli-flags.md                # AC-CLI-001 through ...
    ...

Verification Methods

Every acceptance criterion specifies how the implementer will verify it: