Item Re-verification Flagging

Overview

Item Re-verification Flagging provides automated change impact analysis by flagging downstream items when their upstream dependencies are modified. This ensures teams are aware of potential impacts to traced items and can take appropriate action to maintain system integrity.

When an upstream item ("design input") is changed and re-approved, Ketryx automatically flags all downstream traced items ("design output") that may be affected by the change. This creates a clear audit trail of impact assessment and ensures nothing falls through the cracks during change management.

What is Item Re-verification Flagging?

Item re-verification flagging is a Ketryx feature that:

• Detects when a controlled item has changed since a downstream item (e.g., a test case, child requirement, or design output) was last approved.

• Automatically adds a flag on each directly downstream item that traces to the changed item.

• Provides context and diff views so reviewers understand why the flag exists.

• Records how the flag was resolved in the item and project audit trails.

How It Works

A re-verification flag is created for a design output when all of the following are true:

1. Relationship exists

   • There is a direct traceability link between two items (e.g., “has parent”, “fulfills”, “tests”, or a custom relation), from the design output to the design input.

2. Design input was previously controlled

   • The design input item was in a controlled/approved state according to your project’s approval rules.

3. Design input is modified and re-approved

   • A new record of the design input item is created, and its content is changed.

   • The item is then moved through your workflow and re-approved, becoming the new effective controlled record.

4. Design output is still based on the previous version

   • The downstream item has not been changed and re-approved since this reapproval of the design input.

   • At that point, Ketryx marks the downstream item as “review required” (flagged for re-verification).

On the flagged item's record page in Ketryx

When you open an item record that has a re-verification flag, you’ll see a notification at the top of the page that says something similar to:

“Review required: design input has been updated. View flags to assess if this item needs to be updated accordingly. If so, move this item to an editable state and make changes. The flag will be resolved once this item is reapproved. If not, then you can dismiss the flag below.”

You can click in this notification to navigate down the page to the Re-verification flags section. This section typically includes:

• A link to the design input that was changed.

• An action to view the change that was made to the design input.

• An action to dismiss/clear the flag (if no change is needed).

In lists and filters

Flagged items can be surfaced globally so they can’t be missed during release preparation:

• On any page in Ketryx, you can filter for items with a re-verification flag by using the is:flagged KQL (which can also be used to configure a custom KQL filter or an invalid items filter)

Flag lifecycle

Re-verification flags follow a defined lifecycle:

• Creation: Flags are automatically created when a design input item is modified and re-approved

• Review: Team members can view the specific changes that triggered the flag

• Resolution: Flags can be resolved through:

  • Manual dismissal: A user with approval permissions for the flagged item explicitly dismisses the flag.

  • Automatic clearing: The flag clears automatically when the item is reopened, modified, and re-approved.

Example Scenario

Scenario: Parent requirement change and child impact

Given

• A Ketryx project “Project A”

• Requirements:

  • RQ 1

  • RQ 2

  • RQ 3

• Relations:

  • RQ 3 > "has parent" > RQ 2 > "has parent" > RQ 1

• All three items are controlled

When

• RQ 2 is:

  • Reopened

  • Edited (e.g., updated description or acceptance criteria)

  • Re-approved and returned to a controlled state

Then

• Only RQ 3 is flagged for re-verification, because it is the direct design output of RQ 2.

• The flag on RQ 3:

  • Provides context that the flag originates from RQ 2.

  • Allows the user to see how RQ 2 changed (redlines)

• A user in the approval rules for RQ 3 can dismiss the flag if no change is required, or

• Someone on the team can reopen RQ 3, update it, and the flag will be automatically cleared upon re-approval.

Blocking Releases with Flagged Items

Re-verification flags can be integrated into Ketryx’s release checks so you can ensure no flagged items are included in a release version by using the is:flagged KQL in an invalid items filter. As long as flagged items exist in the version when an invalid items filter is configured, approval of the release will be blocked by the Items valid release checklist item.