How to Review an Implementation Against Official Documentation and Standards

Step-by-step workflow for checking code, configuration, API usage, or design materials against official documentation, standards, and vendor guidance.

Purpose

This guide explains how to run a standards-backed implementation review. Use it when implementation choices must be validated against official documentation, standards, or primary vendor guidance. The workflow requires concrete implementation materials, explicit constraints, and authoritative sources or permission to browse for them. It is designed for real review scenarios where code, configuration, API usage, runtime behavior, or design material may be correct only under specific version, platform, framework, or vendor rules.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

  • Use case
    Implementation must match official guidance
    Use this when code, configuration, API usage, runtime behavior, or design material needs to be checked against official documentation, standards, or primary vendor guidance.
  • Use case
    The issue may be version-sensitive
    Use this when the implementation depends on a specific framework, library, runtime, API version, platform, protocol, or compatibility target.
  • Use case
    Findings must be evidence-bound
    Use this when every finding must be tied to supplied implementation evidence and inspected authoritative sources.
  • Use case
    A concrete changeset is needed
    Use this when the output should identify specific files, configuration entries, excerpts, or implementation deltas rather than broad advice.

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Step 1 · State the implementation review target

    Identify the implementation choice that needs validation: code, configuration, API usage, runtime behavior, platform behavior, protocol handling, or design material.
    Provide the review goal and define the exact implementation surface under review.
    Check: The target is implementation correctness, not architecture classification or broad redesign.

  2. Step 2 · Provide the implementation materials

    Attach or paste the relevant files, excerpts, configuration, API calls, logs, design material, or documentation excerpts.
    Keep the materials concrete enough that findings can cite exact files, excerpts, or configuration entries.
    Check: The review has inspectable implementation evidence.

  3. Step 3 · Provide constraints and applicability details

    State the language, framework, library, runtime, platform, API version, deployment target, compatibility target, or non-functional constraint.
    Include version and runtime details when the guidance may be version-sensitive.
    Check: The review can evaluate whether each source applies to the supplied implementation.

  4. Step 4 · Provide authoritative sources or browsing permission

    Supply official documentation, standards, primary vendor references, or explicit permission to browse for them.
    Do not rely on memory, informal summaries, or unsupported best-practice claims.
    Check: The review has an authoritative source boundary.

  5. Step 5 · Run the implementation-review prompt

    Open the public prompt and replace the MATERIALS block with the goal, implementation materials, constraints, and authoritative sources or browsing permission.
    Ask for context snapshot, sources and applicability, implementation findings, changeset plan, and confidence.
    Check: The prompt is applied only to implementation correctness against authoritative guidance.

  6. Step 6 · Verify source applicability

    Check whether each cited source actually applies to the supplied version, framework, runtime, platform, protocol, or vendor context.
    Mark version-sensitive or unmatched guidance as NOT VERIFIED.
    Check: No finding depends on a source whose applicability was not established.

  7. Step 7 · Accept only source-bound findings

    Check that every finding has implementation evidence and authoritative-source support.
    Reject unsupported findings, speculative improvements, invented source content, and remediation that is not tied to the reviewed material.
    Check: The output separates supported findings, missing evidence, required changes, and confidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

  • Inputs
    Goal, materials, constraints, and sources are present
    If any required input is missing, the workflow must stop with insufficient evidence.
  • Evidence
    Findings are tied to supplied implementation material
    Each finding cites a concrete file, excerpt, configuration entry, API usage, log, or design material that was actually supplied.
  • Sources
    Recommendations are backed by authoritative guidance
    Every non-trivial recommendation is supported by official documentation, standards, or primary vendor guidance.
  • Applicability
    Version and runtime applicability are checked
    Version-sensitive guidance is applied only when the supplied constraints and inspected source support it.
  • Scope
    The review stays inside implementation correctness
    The output does not drift into architecture classification, speculative redesign, full security review, or unrelated code-quality review.
  • Output
    The response follows the required section order
    The answer separates context snapshot, sources and applicability, implementation findings, changeset plan, and confidence.

Next steps