Requirement review

Requirement review is the first gate in the flow: before any test is written, AI checks the story for ambiguity, missing acceptance criteria and contradictions, and compares it with the application’s code and data. Every finding carries evidence, the analyst decides what each finding means, and the product owner approves the corrected story in Jira.

Pulling a requirement

A requirement enters the platform in one of two ways.

• From Jira. The analyst opens Requirements and pulls stories from the configured project. The platform reads Jira with a dedicated read-only account. The story appears with its description and acceptance criteria, and its link points back to the issue in Jira.
• As free text. The analyst pastes a requirement that does not live in Jira. In this case the product owner confirms the final text in the portal instead of in Jira.

Acceptance criteria are the anchors for everything that follows: every test case must reference at least one of them. The platform recognises an “Acceptance Criteria” heading in the description followed by numbered lines such as AC1: .... If your Jira site keeps acceptance criteria in a separate custom field, plan a short adaptation during setup.

In the example used throughout this documentation, the analyst pulls STORY-142 Order cancellation from the Acme Retail project, with acceptance criteria AC1 to AC4.

Pre-review (Demonstrated)

The pre-review is an AI reading of the story on its own terms. It looks for:

• Ambiguity: words that two readers could interpret differently, such as “shortly” or “as usual”.
• Missing acceptance criteria: behaviour described in the text but not covered by any criterion, or obvious negative and boundary cases that nobody wrote down.
• Contradictions: two criteria that cannot both be true.

For STORY-142, a typical pre-review finding is that AC1 allows cancellation “until the order ships”, while the description says “within 24 hours of payment”. Both cannot be the rule. Another is that no criterion says what happens when only part of an order has shipped.

Story content, comments and attachments are treated as untrusted data. They are passed to the model inside labelled data blocks, and instructions found inside them are not followed. Model output must match a JSON schema. Output that does not match is rejected; the model is asked again with the validation error a limited number of times, and then the item goes to a human.

The pre-review prompt bundle has been evaluated against a live model. The current maturity label for this capability is listed on the Capabilities page.

Code and data consistency check (Demonstrated)

The consistency check compares the story with the application itself, using read-only access.

• Code: the agent reads the application repository with a read-only token and looks for the logic the story describes.
• Data: the agent can query the application database only through a dedicated read-only role. That role can read only allowed tables and columns. Each request is a single SELECT with row and time limits, and results are masked. There is no general-purpose SQL tool.

For STORY-142, the check might report that orders/cancel.py allows cancellation only before the order is packed, and that a settings table stores a cancellation window of 12 hours, while the story says 24. It might also report that the confirmation email in AC3 does not exist in the code.

Each finding cites its evidence: a file and line, or a query and its result. The platform re-verifies that evidence deterministically before showing it. A finding whose evidence cannot be confirmed is never displayed. The live model evaluation for this capability is pending.

Deciding on findings

The analyst reviews each finding and makes one of two decisions.

Decision	Meaning	What happens next
Fix the document	The story is wrong or unclear; the code is right	The analyst accepts or edits the proposed text change
Code or data is wrong	The story describes the intended behaviour; the application does not match it	A bug draft is created for the tester

This decision matters later. When a finding is marked “code or data is wrong”, the story keeps the intended behaviour. Test cases are generated against it, and the generated test is expected to fail on today’s code. That failure appears as a defect candidate during code generation, and the tester can link it to the same bug.

Each decision is an audited human action. The analyst can see the proposed diff for every document fix before accepting it.

Writing fixes back to Jira

After deciding, the analyst selects Write fixes to Jira. The platform then:

1. Applies the accepted document changes to the story description through a separate write account that is limited to the project.
2. Runs a second check round on the corrected text, to make sure no blocking finding remains.
3. Marks the document as final and adds a “pending approval” label for the product owner.
4. Posts a question comment for the product owner with any open points.

Every comment the platform writes starts with a fixed AI Testing Probe: marker, so readers can tell it apart from human comments even when the write account belongs to a person. Role accounts configured during setup can be mentioned in these comments. A mention is only a notification: it grants no rights and does not count as approval.

Writes are idempotent. Retrying a write finds the existing comment instead of creating a second one.

Product owner approval

Test case generation cannot start until the product owner approves the final story.

For Jira stories, the product owner approves in Jira itself: they answer the question comment and add the approval label to the story. The platform checks Jira’s change history to confirm who added the label and accepts it only from an account on the configured product owner list. Two safeguards apply:

• The platform never adds the approval label itself. If the label is added by the platform’s own write account, the approval does not count, and the platform removes the label and notifies the product owner.
• The approval is bound to the approved content. If the story text changes after approval, the approval is no longer current and must be given again.

The portal checks for approval at a short, fixed interval, so the analyst sees “PO approved” shortly after the label is added. For free-text requirements, the product owner role confirms in the portal.

What the analyst sees on screen

The requirement detail page brings the stage together in one place.

• Story panel: description and acceptance criteria as they were when the review ran.
• Finding cards: one card per finding, with its type, the evidence (file and line, or query and result), the proposed text change and a REPLAY badge when the output came from a recorded run.
• Decision buttons on each card, and a single Write fixes to Jira action once every finding has a decision.
• Approval status: pending, approved by the product owner, or invalidated because the content changed.
• Live events: progress of the review and of Jira writes streams onto the page, so the analyst does not need to refresh.

A manual baseline time can also be entered per story, with the person entering it and a source note. Savings are calculated only from measured baselines; without one, the platform shows “not measured”.