Define policy pack contribution and quality standards

[arthurpanhku]

Why this matters

Policy packs are where DocSentinel turns generic security review into actionable governance. They also carry a high risk of becoming opaque, stale, or biased if contribution rules are not explicit.

From first principles: a policy rule is only useful if contributors can inspect its source, version, rationale, applicability, and test coverage.

Community help wanted

We need a contribution model and quality bar for public policy packs.

Suggested scope

• Define a policy pack manifest contract: framework, version, source references, license, control IDs, applicability, and maintainer metadata.
• Add validation tests for public policy packs.
• Document how to contribute new controls without introducing confidential or vendor-private content.
• Add examples for common frameworks such as OWASP ASVS, NIST SSDF, SOC 2-style controls, or ISO 27001-style mappings where licensing allows.
• Define review expectations for updates when upstream standards change.

Acceptance criteria

• A contributor guide for policy packs exists.
• Policy pack validation can run in CI.
• At least one example policy pack demonstrates the expected metadata and tests.
• The guide explicitly rejects proprietary, confidential, or customer-specific content.

[arthurpanhku]

Roadmap update: policy packs need verifiable coverage, not broad labels

Please extend the quality contract to require:

• exact upstream framework/specification version;
• canonical source URL and license/provenance metadata;
• control-level citations and stable IDs;
• explicit coverage percentage, exclusions, and unsupported areas;
• checksum/signature and compatibility metadata;
• conformance fixtures and CI validation;
• upgrade/diff guidance when an upstream standard changes.

Claims such as “covers all controls” must be generated from validated coverage data rather than prose. Community-ready follow-up: #50 adds an OSPS Baseline pack and a DocSentinel self-assessment. OSCAL conformance is tracked in #47.