Overview

On the Requirement Documents tab of Rule Intelligence, you upload requirement documents and turn them into structured, approvable requirements. This is the walkthrough for the full loop: upload → Extract text → AI Parse → review and approve in the Extracted Requirements panel. Background: Understanding Rule Intelligence.

Before you begin

Open the workspace: in the project editor, click the Requirements tab (or open the standalone Rule Intelligence hub and select a project). The Requirement Documents tab is selected by default.
The header reads Requirement Documents with the note "Add BRD, PRD, Excel, Word, and other business requirement documents. (API specs — Swagger/WSDL/GraphQL — go in Setup → API Specs.)" and "Upload starts as soon as you choose files."
AI Parse requires an AI provider (Settings → AI). Uploading and Extract text work without one; AI Parse does not.
gRPC is adapter-only — the platform can extract facts from gRPC material but never runs gRPC at test time.

Step 1 — (Optional) set the document type

At the top-right of the header, above the upload button, is a document-type dropdown. It defaults to Auto-detect; the other options are API Module, BRD, and Generic. Leave it on Auto-detect unless a document is being misclassified — the value you pick is passed to the next AI Parse as a documentTypeOverride.

Step 2 — Upload documents

Click Choose requirement files.
Select one or more files. Accepted formats: .pdf, .doc, .docx, .xls, .xlsx, .csv, .html, .htm, .mht, .mhtml, .json, .yaml, .yml, .txt, .md, .markdown.
Upload begins immediately. The button reads Uploading... while it runs; on success you get a Document uploaded (or N document(s) uploaded) confirmation.

Each file becomes a row in the table with columns Name, Type, Status, Created, and Actions. New rows start at status Uploaded. If nothing is uploaded yet, the empty state lists the supported formats and points you back to Choose requirement files.

Step 3 — Run the three-step row workflow

Every requirement row exposes three always-visible, re-runnable buttons on the left of the Actions cell. Each is gated on the previous step:

Button	Icon	What it does	Enabled when
Extract text	green play	Pulls raw text out of the document	Always
AI Parse	blue sparkle	Sends the text to the AI to extract typed requirements	After text is extracted (disabled while status is Uploaded)
Show / Hide requirements	purple list	Opens or closes the Extracted Requirements review panel	Once status is Parsed

There are also Download and Delete buttons on every row. Delete asks you to confirm (Delete document, "This cannot be undone.").

3a. Extract text

Click the green play button. The status cell shows Extracting text... with a spinner, then settles on Text Extracted, and the row hint reads Ready to parse. You'll see a Text extracted successfully confirmation.

3b. AI Parse

Click the blue sparkle button. The status shows Extracting requirements..., then Parsing, then Parsed. On success the Extracted Requirements panel opens automatically and you'll see an N requirements extracted confirmation. While a document is Parsing Queued or Parsing, the list auto-refreshes every few seconds.

Once parsed, the row hint disambiguates the outcome:

No rules extracted — parsed cleanly but found no extractable rules.
N approved · N pending — how many requirements are approved vs. awaiting review.

Step 4 — Handle a partial or re-parse case

Partial parse. If some document sections fail, ambiguities are raised, or requirements can't be saved, a banner appears above the list instead of a plain success toast. It summarizes "N of M requirement(s) ready to approve" and how many sections were processed, and expands into buckets:

N requirement(s) could not be saved (blocking errors)
N item(s) need review
N item(s) auto-corrected (no action needed)
Show ambiguities and Per-section yield breakdowns

If sections failed during AI extraction, the banner offers Retry failed sections (the LLM is non-deterministic, so a retry often succeeds).

Re-parse guard. If you AI-Parse a document that already has approved or human-reviewed requirements, the platform stops and opens a Re-parse will replace reviewed requirements dialog, e.g. "…already has N approved and N human-reviewed requirement(s). Re-parsing wipes them and replaces with a fresh AI extraction. This cannot be undone." Choose Re-parse anyway to proceed or close the dialog to keep your reviewed set.

Step 5 — Review in the Extracted Requirements panel

The panel is headed Extracted Requirements. When a parse spanned multiple sections it also notes Processed N sections and Merged N duplicate(s).

Sort. When there's more than one requirement, a Sort by dropdown offers Confidence (low first) (the default, so likely-needs-review items surface at the top), Priority, Status, and Title. Requirements are grouped by their target endpoint (or General).

Read a row. Each requirement shows its title, description, and a set of chips:

Its type (e.g. Field Constraint, Business Rule, Error Handling).
The target entity and field: … it applies to.
The expected status code (→ 400) and any error code.
A status chip: AI Extracted, Reviewed, Approved, Rejected, or Deprecated.
Confidence: NN%. Below 70% confidence and still AI-extracted, it also shows a Needs review chip.
Low fidelity NN% when the structured constraint fields are thin, and Salvaged / N fields dropped when the AI emitted fields that failed validation.

Step 6 — Approve, reject, edit, or delete

On the right of each row:

Action	Result
Approve (green check)	Status → Approved. Approved requirements are the only ones that drive generation.
Reject (red X)	Status → Rejected. Ignored by the generator.
Edit (pencil)	Opens the inline edit form (see below).
Delete (trash)	Removes the requirement.

Every requirement stays selectable regardless of status, so you can flip an approved item back to rejected or vice versa at any time.

Step 7 — Bulk-approve or bulk-reject

Tick the checkbox on individual rows, or use Select all (N) in the panel header. A blue action bar appears showing N selected with:

Approve selected
Reject selected
Clear selection

Step 8 — Edit a requirement's fields

Click the Edit (pencil) button to open the inline form. Title and description are required.

Field	What it does
Title	Short name of the requirement (required).
Description	Full text of the rule (required).
Priority	Critical, High, Medium, or Low.
Target entity	The entity the rule applies to, e.g. `User`.
Target field	The specific field the constraint targets.
Operator	The constraint operator, e.g. `is_required`, `in`, `between`.
Value (JSON for arrays)	The constraint value, e.g. `100`, `"active"`, `["a","b"]`.
Expected status code	The HTTP status the requirement expects (100–599), e.g. `400`.
Error code	The expected error code, e.g. `ORD-002`.
Error message contains	A substring the error message should contain.
Max latency (ms)	Performance ceiling for the requirement.

Click Save changes (the button shows Saving… while it runs) or Cancel. The same server-side validation the parser uses runs on save, so an invalid value is reported immediately.

Step 9 — Scope a requirement to endpoints

Expand Applies to endpoints on a row. By default a requirement is set to All endpoints (auto-match). To narrow it, tick specific endpoints from the list; the summary updates to N endpoints selected. Un-ticking everything returns it to auto-match.

Notes

Status labels across the flow: Uploaded, Text Extracted, Parsing Queued, Parsing, Parsed, Review Pending, Approved, Failed.
Deleting a document also removes its extracted requirements and closes the review panel if it was open for that document.
Your edits, approvals, and rejections are learning signals — see Continuous learning insights.

Importing and Reviewing Requirements