Verification and traceability

Each release qualification report should contain this evidence:

Minimum verification matrix

Requirement area	Verification method	Required evidence
Functional behavior	Unit and integration test	Trace fixtures, consumer call counts, SQL failure tests, configuration validation tests, and action default-state tests
Reliability and availability	Stress, endurance, and fault-injection test	Named workload and platform, event counts at every boundary, resource graphs, forced dependency failures, and recovery result
Serviceability	Operational scenario review	Log samples, health-check results, diagnostic catalog, and runbook links
Security and safety	Threat analysis, automated analysis, and platform test	Threat model, mitigations, residual-risk acceptance, sanitizer/static analysis reports, service security score, and action qualification log
Testability and maintainability	CI and design review	Test results, coverage, compiler/configuration matrix, API documentation, and review checklist
Portability and deployment	Compatibility, installation, upgrade, and rollback test	Executed platform matrix, package results, preserved configuration, and database schema/data comparison
Usability	User-centered task test	Participant role, scenario, completion rate, elapsed time, errors, and resulting documentation changes
Performance and resource usage	Idle observation and repeatable synthetic-burst test	Reference hardware/software, feature and database configuration, sampling interval, CPU time, resident-memory high-water mark and trend, thread and file-descriptor counts, event counts at controlled boundaries, workload generator, raw results, baseline, variance, and pass/fail decision
Supportability	Release audit	Versioned artifacts, SBOM/provenance, signatures where required, release notes, support statement, and known limitations

Evidence shall identify the source revision, build options, compiler, kernel, dependencies, test environment, commands, results, and retained logs. A requirement may be marked Pass, Fail, Not tested, or Not applicable. Not applicable requires an approved rationale. Release gates shall not treat Not tested as Pass.

Performance evidence shall be interpreted according to rasdaemon’s workload. RAS events are exceptional, so idle resource stability and correct behavior during a bounded burst are release concerns. Sustained high-throughput or hard-real-time latency is not a product objective unless a distributor adds such a requirement for a particular deployment.