← Back to Home Legitimacy & Evidence Independent Review

RFC Process

Protective Computing now has a public process for proposing changes. The purpose is to make disagreements inspectable, evidence-gated, and version-bound rather than founder-routed or ad hoc.

What requires an RFC

Changes to normative wording in the specification.
New or revised threat boundaries.
Framework-crosswalk changes that materially widen or narrow public claims.
PLS rubric changes affecting scoring behavior.
Governance changes that alter how review or acceptance works.

Proposal Classes

Class	Examples	Minimum evidence	Version impact
Documentation clarification	Sharper wording, better examples, narrower non-claim language	Confusion source and exact proposed clarification	Minor or no version bump
Threat-boundary correction	New threat class, out-of-scope correction, evidence correction	Reproducible scenario or evidence packet	Usually v1.1+
Control or mapping adjustment	Crosswalk change, audit evidence requirement update, rubric logic refinement	Artifact diff plus rationale and reviewer impact	Minor or release-note tracked
Normative change	New MUST/SHOULD behavior, level criteria change, principle-level change	Strong evidence plus review and dissent handling	Potential major version impact

Workflow

Open an RFC issue using the public template.
State proposal class, scope, evidence, and exact affected artifacts.
Collect at least one reviewer response or record that none arrived within the stated review window.
Close as accepted, rejected, deferred, or superseded with written rationale.
Bind accepted RFCs to versioned docs and release notes.

Release Binding

Accepted RFCs are not complete until they are recorded in the public release trail. Every accepted RFC should produce a visible release-history entry or update an existing one.

Use Release History as the public changelog surface.
Record the RFC identifier, the affected artifacts, and the release or date where the change landed.
If a proposal is accepted but deferred, note the target release and keep the release-history row pending until it lands.

Review States

State	Meaning
Draft	Proposal opened but evidence or scope still incomplete.
Review	Open for external or internal critique.
Accepted	Approved with rationale and bound to a version target.
Rejected	Not accepted; rationale published.
Deferred	Valuable, but postponed to a later cycle.
Superseded	Replaced by a later RFC.

Acceptance Criteria

Scope is explicit and narrow enough to review.
Evidence exists for factual or threat-model claims.
Affected files and public claims are named.
Dissent or uncertainty is recorded, not silently removed.
The change can be tied to a release note, changelog line, or versioned artifact update.

Evidence Sources

Open RFC Proposal Release History Review Template