Acceptance evidence: Implementation and evidence
Defines traceable acceptance evidence for privacy and compliance requirements, linking each claim to an applicable rule, implemented control, test result, configuration, reviewer, and residual limitation.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Accept a requirement only from a versioned evidence bundle that maps its exact scope to implementation and observed results. Separate technical pass, expert review, exception, and production observation; none alone becomes a blanket compliance claim.
Scope
- Requirement identity, applicability, control mapping, implementation references, tests, configuration snapshots, results, exceptions, approvals, and expiry.
- Release and periodic evidence for privacy/security-adjacent product behavior.
- Machine-checkable traceability plus human review.
Outside this block
- Legal certification or proof that no unknown issue exists.
- Screenshots without reproducible state, identity, date, and expected result.
Contract
- Every acceptance claim identifies requirement version, applicability decision, system/release scope, owner, and acceptance criteria.
- Evidence distinguishes design document, code/config reference, automated result, manual observation, and production monitor.
- Test evidence includes fixture, environment, command or procedure, time, result, artifact digest, and relevant redactions.
- Exceptions state affected criteria, compensating control, risk owner, expiry, and remediation link.
- A later release cannot reuse evidence when mapped code, configuration, dependency, policy, or test semantics changed materially.
- Status vocabulary separates not-applicable, not-tested, failed, exception-approved, and passed.
Implementation guidance
- Store a lightweight manifest pointing to protected evidence rather than copying secrets or personal data.
- Generate candidate mappings from repository ownership and CI, then require the responsible reviewer to confirm applicability.
- Sign or protect evidence records from alteration by the same role that implements the control when separation is required.
- Create an impact rule that invalidates evidence on mapped changes.
Failure handling and safeguards
- Missing evidence produces not-tested, never passed.
- A broken or unauthorized evidence link fails verification and triggers renewal.
- Expired exceptions revert the requirement to failed or blocked according to the release policy.
Verification and operations
- Measure requirement coverage, stale/broken evidence, failed criteria, exception count/age, review latency, and escaped control failures.
- Sample evidence for reproducibility and least-sensitive retention.
- Require qualified legal/privacy interpretation for jurisdictional conclusions.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.