holdout-validation

Holdout validation separates test authorship from code authorship by storing behavioral acceptance scenarios in a restricted .copilot/holdout/ directory. This structural separation prevents implementation agents from seeing the tests, thereby stopping model leakage and test gaming.

Holdout-based spec integrity is a discipline where architects author intent-level behavioral scenarios independently from the code. Guardian then evaluates implementations against these hidden holdout scenarios to verify true intent without exposing the tests to the implementation agent.

Architects author 3 to 10 intent-based holdout scenarios per feature and save them under the .copilot/holdout/ path using a HOLDOUT.md naming convention. This isolates the acceptance criteria from the main codebase for independent Guardian review.

Do not use holdout validation for writing unit tests, performing code implementation, verifying general task completion, or designing general test strategy. It is strictly for enforcing holdout-set discipline and validating implementations against intent during specification and review workflows.

Yes, Guardian review compatibility allows Guardians to evaluate implementations strictly against holdout scenarios without needing access to the underlying code. This ensures the review process focuses entirely on behavioral intent rather than implementation details.

The workflow governance requires an Architect to author the holdout scenarios and a Guardian to evaluate them. This enforces structural separation between specification and review, ensuring the implementation agent cannot access or game the hidden acceptance tests.