Check implementation against official guidance

Rules for source-backed review of code and configuration changes against official framework, library, runtime, platform, or standards guidance.

What this policy enforces

Use this policy when the dominant question is whether an implementation is correct, compatible, and defensible against authoritative guidance.

Review type
Source-backed implementation review
This policy validates code or configuration changes against official framework, library, runtime, platform, protocol, standards, or vendor guidance.
It is evidence-bound and source-backed by design.
Scope boundary
Implementation correctness, not system shape
Use this policy for implementation correctness, compatibility, and defensibility against authoritative guidance.
Do not use it for broad architecture classification or generic brainstorming.
Output contract
Recommendations must stay source-bound
Non-trivial recommendations must be backed by inspected authoritative sources and translated into concrete implementation deltas when feasible.
No speculative remediation.

Scope

These are the review domains this policy is designed to cover.

Code or configuration review against official guidance
Use it when the question is whether implementation changes align with official guidance.
API usage and version-sensitive checks
Use it for API correctness, version applicability, and runtime-specific implementation decisions.
Supported quality findings
Compatibility, reliability, maintainability, performance, and security-control findings are in scope only when supported by inspected sources.
File-specific remediation planning
Concrete remediation tied to actual files and implementation deltas is in scope.

Rules (normative)

These rules define the minimum operating contract for a standards-backed implementation review.

R1
No simulation
Do not invent source content, version applicability, runtime details, or implementation behavior that was not evidenced.
R2
Source-bound recommendations
Every non-trivial recommendation must be backed by an authoritative source or be marked NOT VERIFIED.
R3
Applicability first
If the guidance is version-sensitive, state version or runtime applicability first.
If applicability cannot be established from the materials or inspected sources, mark the recommendation NOT VERIFIED.
R4
Implementation-only scope
Findings must stay within implementation, configuration, or API-usage scope.
Use the architecture-boundary review for system-shape questions.
R5
File-specific deltas
Recommendations must translate into concrete file changes such as MODIFY, ADD, or REMOVE with copy/paste blocks when feasible.
R6
Fail-closed on insufficient evidence
If goal, materials, constraints, or sources or permission to browse are insufficient, output only:
INSUFFICIENT_EVIDENCE: <what is missing>
R7
Confidence required
Output one 0–100 confidence score based on source quality, applicability, and evidence completeness.

Related libraries

Open the matching library when you need the broader policy set, the runnable procedure, or the linked prompt files.

Policies
Browse the broader policy library and adjacent evidence-boundary rules.
Open index
How-to
Browse the procedural library and adjacent review workflows.
Open index
Prompt library
Open the prompt files used to enforce this review policy in a runtime.
Open library