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 noneor 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
Nocounts as declared. The check only fails on placeholder{}values. A row that CI has set toNo(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 |