OpenVINO Code Review

Purpose

Provide a concise, evidence-based review of the proposed diff. Review changed code and the directly affected neighboring code; do not perform a broad audit of unrelated legacy code.

Review workflow

1. Read the diff, commit or pull request description, and relevant surrounding code.
2. Identify the affected component, public APIs, runtime paths, input boundaries, and expected tests. Load the relevant component references from the table below.
3. Check for functional regressions first, then input safety, performance, compatibility, test coverage, and maintainability.
4. Before reporting a finding, confirm that the claimed problem exists in the source code. Distinguish source content from diff markers, line numbers, and other review annotations. Verify the failure against the configured behavior or documented requirements; do not assume additional triggers, unsupported usage, or stricter rules. If the available evidence does not establish a defect, omit the finding.

Conditional review modes

Revert pull requests

Treat a pull request that reverts a previously merged change as a regression review rather than as entirely new functionality:

• Identify the original pull request or change from the title and description.
• Determine what behavior, bug, or risk the original change addressed.
• Check whether the revert reintroduces that issue or creates a new compatibility problem.
• Avoid requesting new tests, refactors, or style changes for restored code unless they are needed to prevent a concrete regression.
• If the original change and its rationale cannot be identified, state that as a validation gap rather than guessing.

External contributions

For pull requests from external contributors, keep the review evidence-based and focused on merge-blocking or materially risky behavior:

• Prioritize required CI results, buildability, changed-path risk, and correctness of the submitted diff.
• Verify that all commits stay within the scope described by the pull request. Call out unrelated component changes as an out-of-scope risk.
• Do not request extra local validation when required checks already cover the changed behavior and are passing.
• When checks fail, inspect the available evidence and distinguish change-induced failures from infrastructure, network, resource, or pre-existing test failures.
• Do not infer lower quality from external authorship; report only issues supported by the diff, tests, or CI evidence.

Priority checklist

Correctness and compatibility

• Check shape, element type, attributes, dynamic behavior, state, error paths, and cross-device behavior where relevant.
• Check backward compatibility for existing public APIs and serialized models.
• Check that generated code, bindings, documentation, and registrations remain consistent when an API or user-visible behavior changes.

Safety

• Treat model metadata, file contents, and user-provided values as untrusted.
• Check bounds, overflow, signed/unsigned conversions, narrowing conversions, ownership, lifetime, and resource cleanup.
• Require validation before unsafe arithmetic or memory access, and prefer fail-fast errors over warning-only handling of invalid input.

Performance

• Look for unnecessary tensor or container copies, allocations in hot paths, repeated invariant work, synchronization changes, and altered memory reuse.
• Require evidence before claiming a measurable performance regression.

Tests and validation

• Expect regression coverage for bug fixes and behavioral changes when an existing test suite can express the scenario. Do not request a new test when equivalent coverage already exists.
• Check architecture, frontend, plugin, and dynamic-shape coverage where the changed behavior depends on them.
• Consider required CI and build metadata only when the diff changes those surfaces.

Component guidance

Load only the references relevant to the changed behavior. Paths below are relative to the repository root and include tests within each component. Apply multiple references when a change crosses boundaries; for shared tests or documentation, select by the behavior exercised or described.

Review output

Report all material, high-confidence, actionable findings in descending order of practical impact. Each finding should include:

• the exact changed location, linked when the review interface supports it;
• the failure mode and its impact on OpenVINO users, builds, or runtime; and
• a minimal, concrete fix direction.

Keep one issue per finding and use one representative location for a repeated root cause. Omit speculative issues, style preferences enforced by tooling, and unrelated refactor requests. Separate confirmed issues from questions, assumptions, and validation gaps. Do not include secrets or sensitive data.

If no actionable issue is found, say so explicitly and summarize the areas reviewed, tests or checks run, and any validation that remains unavailable.