Methodology — contract-first + falsifier-driven

CCPA is governed by a single methodology, applied uniformly: every behavior gate is an assertion in a YAML contract; the assertion exists before the code that proves it; CI mechanically validates both.

The cycle

1. Behavior identified              →  written prose
2. Falsifier composed               →  "this is exactly the assertion that would
                                       prove the gate WRONG if it failed"
3. Contract entry added             →  contracts/claude-code-parity-apr-v1.yaml
                                       (status: PROPOSED at first)
4. pv validate the contract         →  syntax + schema gate
5. Test that exercises the falsifier→  crates/ccpa-{differ,arena,...}/tests/
                                       (links the gate ID by name)
6. CI hard-blocks                   →  status flips ACTIVE_ALGORITHM_LEVEL
                                       once the test passes deterministically
7. Empirical evidence on file       →  flips ACTIVE_RUNTIME once a real
                                       measured discharge is recorded

No step is optional. No step happens in a different order. The cycle is enforced by FALSIFY-CCPA-012 (pre-commit + CI pv validate) and FALSIFY-CCPA-007 (corpus coverage).

Status flow for any gate

PROPOSED  ──── algorithm-level test passes deterministically ────→  ACTIVE_ALGORITHM_LEVEL
                                                                              │
                                                              measured discharge on file
                                                                              ▼
                                                                       ACTIVE_RUNTIME

PROPOSED: defined in the YAML, not yet asserted by a passing test.
ACTIVE_ALGORITHM_LEVEL: a deterministic test asserts the gate, but no real-world measurement has been recorded yet.
ACTIVE_RUNTIME: a real measured bench run (operator-dispatched, evidence captured) discharged the gate.

See Status flow for the exhaustive transition table.

Three sources of truth

Concern	Lives in	Why
Contract YAML	`paiml/aprender/contracts/claude-code-parity-apr-v1.yaml` (canonical), pinned here via `contracts/pin.lock`	aprender is the org-wide single-source-of-truth for paiml contracts
Spec text	`docs/specifications/claude-code-parity-apr-poc.md`	This repo since M1
Implementation, fixtures, CI, coverage, pmat-comply	this repo	The harness IS the implementation

The split mirrors aprender's monorepo policy: aprender stays canonical for contract TEXT (the shared schema across all paiml contracts), while this repo is canonical for runtime ENFORCEMENT (the tests, fixtures, CI, and pmat comply posture).

Forbidden tools

cargo tarpaulin — slow, unreliable. Use cargo llvm-cov only.
bash re-implementations of pv / pmat / cargo-llvm-cov checks — if pv validate rejects a contract, fix the contract or extend aprender-contracts/src/schema/; do not duplicate validation logic in bash.

Code search policy

pmat query over grep for any Rust code search. pmat query returns quality-annotated, semantically ranked results (TDG grades, complexity, fault patterns). grep / rg returns lines.

grep is acceptable only for non-Rust files (TOML, YAML, Markdown) or quick one-off debugging.