Review type
Source-backed implementation review
This policy validates code or configuration changes against official framework, library, runtime, platform, protocol, standards, or vendor guidance.
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.
Scope boundary
Implementation correctness, not system shape
Use this policy for implementation correctness, compatibility, and defensibility against authoritative guidance.
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.
Canonical links
Open the linked procedure, prompt files, and companion policies that implement this review boundary.
Procedure
Run the review workflow
[Run the standards-backed implementation review — procedure](/how-to/standards-backed-implementation-review-procedure/)
Prompt files
System and user templates
Companion policy
Authoritative sources required
[Use cited public sources](/policies/facts-only-authoritative-sources-required/)
Companion policy
Web verification and citations
[Use web search for current or niche claims](/policies/web-verification-and-citations/)
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.
Non-goals
This section prevents the policy from being used outside its intended boundary.
Out of scope
Not an architecture classification workflow
Use the architecture-boundary path when the question is about system shape, layering, ownership, or boundary classification.
Out of scope
Not a speculative best-ideas review
Do not use this policy for generic brainstorming or unsupported “best ideas” recommendations.
Conditional scope
Not a full secure code review by default
A full secure code review is out of scope unless the review goal and inspected sources explicitly support it.
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.
R4
Implementation-only scope
Findings must stay within implementation, configuration, or API-usage scope.
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:
R7
Confidence required
Output one 0–100 confidence score based on source quality, applicability, and evidence completeness.