Orca ORCA v0.174.2
Documentation navigation

Impact Review Guide

This guide explains how to fill the Impact Review table on a Production release PR using /impactreview comments. You do not edit the table directly — you post comments, and CI updates the table for you.

How It Works

When Orca creates a Production release PR, it seeds an empty Impact Review table into the PR description. The table has a fixed set of rows (domains and impacted areas) that come from a QMS-controlled template. Every row starts with placeholder values:

Column Placeholder Meaning
Affected? {} Not yet reviewed — CI fills this in
Notes/Actions - Blank until you write a note
Current Version {} Blank until you record the current version

You declare impact by posting /impactreview comments on the PR. CI reads your comments, updates the table in the PR description, and a blocking check prevents the PR from merging until every row has been declared.

Command Reference

Declare a row affected

/impactreview <area> <message>

Marks the matching row as affected (Yes) and records your note in the Notes/Actions column.

Declare a row affected with a version bump

/impactreview <area> <message> <current version>

Same as above, plus records the affected document's current version.

Declare nothing affected

/impactreview none

Clears every row to unaffected (No) with blank notes and blank versions (shown as - in the rendered table). Use this when the release does not impact any of the listed domains or areas.

Writing the Area

The area must match a row's Impacted Area column (the second column). Areas in the template are kebab-case: lowercase, with hyphens instead of spaces. You type the area as the first word after /impactreview, and the domain is inferred automatically.

Examples (using the default template)

Impacted Area in the table Command prefix
label /impactreview label ...
ai-models /impactreview ai-models ...
unit-testing /impactreview unit-testing ...
integration-testing /impactreview integration-testing ...
system-testing /impactreview system-testing ...
clinical-risk /impactreview clinical-risk ...
information-security-risk /impactreview information-security-risk ...
software-requirements /impactreview software-requirements ...
integration-and-system-verification /impactreview integration-and-system-verification ...
release /impactreview release ...
verification /impactreview verification ...
sbom /impactreview sbom ...
udi /impactreview udi ...
user-instructions /impactreview user-instructions ...

Note: The Impact Review table for API, doesn't contain the udi row. The example table for the API would look the following way:

Impacted Area in the table Command prefix
label /impactreview label ...
ai-models /impactreview ai-models ...
unit-testing /impactreview unit-testing ...
integration-testing /impactreview integration-testing ...
system-testing /impactreview system-testing ...
clinical-risk /impactreview clinical-risk ...
information-security-risk /impactreview information-security-risk ...
software-requirements /impactreview software-requirements ...
integration-and-system-verification /impactreview integration-and-system-verification ...
release /impactreview release ...
verification /impactreview verification ...
sbom /impactreview sbom ...
user-instructions /impactreview user-instructions ...

Case insensitivity

The matcher is case-insensitive, so these all match the same row:

/impactreview unit-testing added coverage
/impactreview Unit-Testing added coverage
/impactreview UNIT-TESTING added coverage

Underscore tolerance

Underscores are treated as hyphens, so this also works:

/impactreview user_instructions reworded the onboarding step

Whitespace tolerance

Extra spaces in the command are collapsed automatically:

/impactreview   unit-testing   added   coverage

This works the same as the tidy version.

Writing the Message

The message is everything between the area and the optional version at the end. It becomes the Notes/Actions cell.

With versions

When you include version at the end, the parser peels it off and uses it for the Current Version column. The rest is the note:

/impactreview unit-testing added coverage for the formatter path v12.23.0
  • Note: added coverage for the formatter path
  • Current Version: 12.23.0

Without versions

When the line does not end in a version number, the entire text after the area is the note, and the version column is left blank (shown as - in the rendered table):

/impactreview user-instructions reworded the onboarding step
  • Note: reworded the onboarding step
  • Current Version: - (blank)

This is the correct way to declare a row whose document is N/A (no document to version).

Message is required

A command with a matching area but no message is silently skipped. This is wrong:

/impactreview unit-testing

It has no message, so nothing happens. Always include a description of what was done or reviewed.

Writing Current Version

Writing the current version is optional and follows the message segment, of the comment, at the end of the line.

Accepted formats

All of these record 12.23.0 in the Current Version column:

v12.23.0
v.12.23.0
v 12.23.0
12.23.0

The v prefix (with or without a dot or space) is stripped. The table records the numeric form only, so it looks the same no matter how you typed it.

When to include the current version

Row's Document(s) column Include versions?
REC-001-003 Label Design Yes — the document has a version
RPT-001-005 Software Summary Report Yes
N/A No — there is no document to version

What happens if you omit current version on a later comment

If you first declare a row with version and then post a correction without version, the earlier version is kept:

/impactreview unit-testing added coverage v12.23.0
/impactreview unit-testing corrected wording
  • Note: corrected wording (replaced)
  • Current Version: 12.23.0 (kept from the first comment)

Multiple Declarations

Multiple lines in one comment

You can post several declarations in a single comment. Each /impactreview line is processed independently. Lines that are not commands (prose, discussion) are ignored:

Impact review for this release:

/impactreview unit-testing added coverage for the formatter path v12.23.0
/impactreview software-requirements new endpoint documented v3.1
/impactreview release regenerated release report v2.0

Shipping once CI is green.

The prose lines ("Impact review for this release:" and "Shipping once CI is green.") are ignored. Only the three /impactreview lines are applied.

Multiple comments

You can post declarations across multiple comments over time. Each time you post a new comment, CI re-reads all comments on the PR and re-applies them in order. The last declaration for a given row wins.

Comments apply in order

Commands are processed in the order they appear across all comments. A later command always overrides an earlier one for the same row.

The /impactreview none Command

/impactreview none

This is the shortcut for "I reviewed the release and nothing is affected." It clears every row to No with blank notes and blank versions (shown as - in the rendered table).

When to use it

  • The release is a routine version bump with no QMS-relevant changes.
  • You reviewed all rows and none are impacted.

What it does to the table

Column Before After
Affected? (any) No
Notes/Actions (any) -
Current Version (any) -

After none, you can still declare rows

Since commands apply in order, a declaration posted after none still takes effect:

/impactreview none
/impactreview release regenerated report v2.0 v2.1

Result: every row is No except Documentation / Release, which is Yes.

Edge Cases

Command that names an area not in the table

/impactreview smoke-testing looks fine

If smoke-testing is not an area in the table, the command is silently skipped. The table is not changed. No error is shown to the author.

Typo in the marker

/impact-review unit-testing added coverage

The marker must be exactly /impactreview (case-insensitive). A hyphen or other variation is not recognised. The line is treated as prose and ignored.

Words that start with the marker

/impactreviewers should look at this

The parser requires a space (or end of line) after /impactreview. Since /impactreviewers runs the marker into another word, this is not recognised as a command.

Comment that is not a command

LGTM, shipping this.

Non-command lines are ignored. You can freely write discussion around your commands.

Comment with a different slash command

/ra-justification not used by customers

Other slash commands are ignored by the impact review parser.

What You Cannot Change From a Comment

Column Changeable via comment?
Domain No — comes from the template
Impacted Area No — comes from the template
Document(s) No — comes from the template
Affected? Yes — set by your declaration
Notes/Actions Yes — your message
Current Version Yes — your version

If the domain, area, or document list needs to change, the template in the deployments repo (templates/compliance/ImpactReview.md) must be updated. That is a QMS-controlled change, not a PR comment.

Blocking Check

A CI check runs on every PR update. It reads the table from the PR description (not your comments) and fails if any row still has {} in the Affected? column.

This means:

  • You must post at least one comment — either /impactreview none or a row declaration. Without any comment, CI never updates the table, and the check stays red.
  • CI must update the table before the check passes. After you post a comment, CI runs the update tool, which modifies the PR description. The check then reads the updated table. If CI has not run yet, the table still has placeholders and the check fails.
  • A row declared No counts as declared. The check only fails on placeholder {} values. A row that CI has set to No (because you posted /impactreview none) passes.

Complete Examples

The examples below use a simplified 5-row table for readability. The actual template may contain more rows — the command syntax is the same regardless.

Example 1: Nothing affected (most common)

The release is a routine bump. You reviewed it and nothing needs documenting.

Comment:

/impactreview none

Resulting table:

Domain Impacted Area Affected? Notes/Actions Document(s) Current Version
Product Design label No - REC-001-003 Label Design -
Testing unit-testing No - RPT-001-005 Software Summary Report -
Documentation release No - RPT-001-003 Software Release Report -
Documentation software-requirements No - REC-001-009 System and Software Requirements and Traceability Matrix -
Documentation user-instructions No - N/A -

Example 2: One row affected with a version bump

The release adds unit test coverage and the Software Summary Report needs a version bump.

Comment:

/impactreview unit-testing added coverage for the dictation toolbar focus fix v3.1

Resulting table (only the affected row shown):

Domain Impacted Area Affected? Notes/Actions Document(s) Current Version
Testing unit-testing Yes added coverage for the dictation toolbar focus fix RPT-001-005 Software Summary Report 3.1

All other rows would be No (assuming no other declarations were made).

Example 3: Multiple rows in one comment

The release touches testing, documentation, and risk assessment.

Comment:

Impact review for this release:

/impactreview unit-testing added coverage for the dictation toolbar focus fix v3.1
/impactreview system-testing full sanity suite re-run for this release v3.1
/impactreview software-requirements new /api/public endpoints documented v3.5
/impactreview sbom regenerated after the drizzle-orm bump v2.8
/impactreview clinical-risk reviewed with CSO, no change to the risk file

Shipping once CI is green.

Example 4: Declaring a row without a document

The user-instructions row has N/A in the Document(s) column — there is no document to version.

Comment:

/impactreview user-instructions reworded the onboarding step

No version needed. The Current Version column is left blank (shown as - in the rendered table).

Example 5: Correcting an earlier declaration

You posted a declaration, then realised the wording was wrong.

Comment 1:

/impactreview unit-testing added coverge v3.1

Comment 2 (correction):

/impactreview unit-testing corrected: added coverage for the dictation toolbar fix v3.1

The second comment replaces the note and version from the first. The final table shows: corrected: added coverage for the dictation toolbar fix, 3.1.

If you omit the version on the correction, the earlier version is kept:

Comment 2 (correction without version):

/impactreview unit-testing corrected: added coverage for the dictation toolbar fix

The note is replaced, but the version from comment 1 (3.1) is kept.

Example 6: Changing your mind — nothing is affected after all

You declared a row affected, then after a revert, nothing is affected.

Comment 1:

/impactreview unit-testing added coverage v3.1

Comment 2:

Actually nothing is affected after the revert:
/impactreview none

none clears every row, including the one you declared earlier. The table shows all rows as No.

Quick Reference

What you want Command
Declare a row affected /impactreview <area> <message>
Declare a row affected with version /impactreview <area> <message> <version>
Declare nothing affected /impactreview none
Declare multiple rows One /impactreview line per row in a single comment
Correct an earlier declaration Post a new comment with the corrected command
Keep earlier version, change the note /impactreview <area> <new message> (no version)

Version format cheatsheet

You type What the table records
v12.24.0 12.24.0
v.12.24.0 12.24.0
v 12.24.0 12.24.0
12.24.0 12.24.0