Run the standards-backed implementation review — procedure

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

Use this procedure for standards-backed implementation review

Choose this procedure when the task is about whether an implementation is correct according to official guidance and the output must stay source-backed.

Review scope
Implementation correctness against official guidance
Use this path for code or configuration review against official docs, API usage, version-sensitive checks, and source-backed implementation findings.
This is not an architecture-classification workflow.
Typical use
Get source-backed remediation instead of high-level advice
Use it when the change is framework, library, runtime, platform, or standards sensitive and you need a file-specific changeset plan.
The run must separate implementation review from architecture review.
Fail-closed rule
Missing sources or applicability stop the run
Required inputs are goal, materials, constraints, and authoritative sources or explicit permission to browse for them.
If a required input is missing, output only INSUFFICIENT_EVIDENCE: <what is missing>.

Canonical links

Open the linked policy and prompt files that implement this standards-backed review workflow.

Related
Policy and prompt files for this guide

Open the policy linked to this guide and any prompt files used with it.

Check implementation against official guidance — policy
Prompt files (7) Hide prompt files

What to load

Load the review stack in this order before you run the workflow.

Inputs required

Provide these inputs before the run can produce a source-backed implementation answer.

Required
Goal or intent of the review
State what should be evaluated and what implementation question matters.
Required
Materials to inspect
Provide code, config, file tree, or design excerpts that support implementation review.
Required
Constraints
Include language, framework, runtime, version, and any relevant non-functional limits.
Required
Authoritative sources or permission to browse
Provide the authoritative sources that justify recommendations, or explicitly allow browsing for them.
Optional: version pins
Useful when applicability depends on exact versions.
Optional: deployment or runtime details
Useful when guidance depends on environment-specific constraints.
Optional: compatibility constraints
Useful when the review must preserve backward or cross-platform compatibility.
Optional: diff scope
Useful when the review should stay bounded to a specific change set.

Run the procedure

Follow these steps in order.

Step 1
State the implementation surface
Specify what is being reviewed: code changes, configuration changes, API usage, runtime behavior assumptions, or framework and library integration.
Step 2
Load the authoritative-source boundary
Paste facts-only-authoritative-sources-required.system.txt.
Step 3
Load the web and citation contract
Paste web-verification-and-citations.system.txt so the run stays source-backed when external guidance is needed.
Step 4
Load the implementation review contract
Paste standards-backed-implementation-review.system.txt.
Step 5
Load the runner
Paste standards-backed-implementation-review.user.txt and append the goal, materials, constraints, and authoritative sources or browsing permission.
Step 6
Add optional components only when needed
Use deep-search.user.txt when source discovery quality matters and deep-scan.user.txt when the materials span many files.
Step 7
Run the review
The output must follow this exact section order:
A) CONTEXT SNAPSHOT · B) SOURCES & APPLICABILITY · C) IMPLEMENTATION FINDINGS (SOURCE-BOUND) · D) CHANGESET PLAN · E) CONFIDENCE
Step 8
Check the result boundary
Confirm that the output names the authoritative sources actually used, states version or runtime applicability when relevant, keeps findings inside implementation scope, and provides file-specific remediation instead of generic advice.

Verify the setup

Use these smoke tests to confirm that the procedure is behaving correctly.

Smoke test 1
Provide a goal, code or config excerpts, constraints, and at least one authoritative source.
Expected: outputs sections A through E in order.
Smoke test 2
Omit sources and do not grant permission to browse.
Expected: output only INSUFFICIENT_EVIDENCE: <what is missing>.
Smoke test 3
Provide version-sensitive guidance but omit the relevant version or runtime.
Expected: the affected recommendation is NOT VERIFIED or the run fails closed if the missing version blocks the review.

Common failure modes

These are the main failure modes this procedure is intended to block.

Using it for architecture classification
This procedure is not for deciding system shape or boundary classification.
Treating link-only references as inspected evidence
Providing links without browsing permission or inspected source content does not satisfy the evidence requirement.
Using the wrong version or runtime
Guidance applied to the wrong version, runtime, or platform invalidates applicability.
Drifting into generic best-practice advice
Do not produce broad redesign advice or unsupported best-practice claims without authoritative support.

Related libraries

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

Policies
Browse the broader policy library and adjacent implementation review boundaries.
Open index →
How-to
Browse the procedural library and adjacent engineering-review workflows.
Open index →
Prompt library
Open the prompt files used by this implementation review procedure.
Open library →