Read the diff, commit or pull request description, and relevant surrounding code.
Identify the affected component, public APIs, runtime paths, input boundaries, and expected tests. Load the relevant component references from the table below.
Check for functional regressions first, then input safety, performance, compatibility, test coverage, and maintainability.
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.

Changed paths or behavior	Reference
`src/core/`, `src/inference/`	Runtime and core
`src/common/transformations/`, `src/common/low_precision_transformations/`, `src/common/offline_transformations/`, `src/common/snippets/`, `src/core/src/pass/`, `src/core/src/pattern/`, `src/core/include/openvino/pass/`, transformation passes and tests under frontends or plugins, `src/bindings/python/tests/test_transformations/`	Transformations, plus the owning component's guidance
`src/plugins/`, including plugin-local tests	Plugins
`src/tests/functional/` shared operator and inference behavior tests	Runtime and plugins, as exercised
`src/frontends/`, `src/bindings/python/src/openvino/frontend/` (including PyTorch and JAX decoders), `src/bindings/python/src/pyopenvino/frontend/`, framework conversion tests in `tests/layer_tests/` and `tests/model_hub_tests/`	Frontends; also apply bindings for Python API and language-boundary changes
`src/bindings/`, public API changes under `src/core/include/` or `src/inference/include/`	Bindings and public APIs
`.github/workflows/`, `.github/actions/`, `.github/scripts/`, `.github/dockerfiles/`, Smart CI and dependency configuration under `.github/`, `cmake/`, `CMakeLists.txt` and `*.cmake` at any depth, dependency manifests and integration changes	CI, build, and dependencies

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.

code-review

OpenVINO Code Review

Purpose

Review workflow