Appearance
Smart Extract
Where to find it: Regulatory Compliance, then Regulatory Library, then Smart Extract (/smart-extract).
Smart Extract reads a regulatory document and proposes the discrete requirements inside it. A person reviews every proposal and decides what becomes an obligation.
Why it exists
Regulatory documents are written to be read by lawyers, not parsed by systems. A single paragraph routinely contains three duties; a table of thresholds may contain forty. Decomposing a hundred-page circular by hand takes days and produces inconsistent granularity between analysts.
Smart Extract compresses the mechanical part of that work while leaving the judgement where it belongs.
The four stages
1. Upload
Upload the source document. OrviQ converts it to text through the shared document processing pipeline and creates an extraction session.
The original document is retained as the provenance artefact — every candidate can be traced back to the text it came from.
2. Extract
The extraction job runs asynchronously. The session moves through extracting while the job is queued and running.
Progress is visible while the job runs; you do not need to keep the page open.
3. Review
When extraction completes the session moves to review, and the candidate requirements are presented for human decision. This is the substantive step.
For each candidate you can:
| Action | Use when |
|---|---|
| Accept | The candidate is a genuine, correctly bounded obligation |
| Edit | The substance is right but the title, code or boundary needs adjusting |
| Merge | Two candidates express the same duty |
| Split | One candidate actually contains two duties |
| Reject | It is not an obligation — a definition, a recital, a cross-reference |
You can also set metadata across candidates: framework, clause codes, applicable activities, owning departments and ownership.
4. Publish
Publishing writes the accepted candidates into the library as requirements. The session moves to published.
Publication is the only step that creates obligations
Nothing before publication changes your requirement set. Extraction output is a proposal set, and an unpublished session has no compliance effect whatsoever.
Session states
| State | Meaning |
|---|---|
ready | Document uploaded, extraction not yet started |
extracting | Extraction job queued or running |
review | Extraction complete; candidates awaiting human decision |
published | Accepted candidates written to the library |
failed | Extraction did not complete; see the recorded error |
Reviewing well
Read the source text alongside the candidate. Each candidate shows the text it derived from. If the two do not correspond, reject.
Watch the boundaries. The most common extraction error is granularity: an obligation split too finely becomes unownable; one left too coarse becomes unassignable. Aim for units a single accountable person could reasonably complete.
Reject definitions and recitals. "For the purposes of this circular, material outsourcing means..." is a definition, not a duty. It belongs in the source text of the obligations that use the term, not as an obligation of its own.
Watch for restated duties. Many documents restate obligations in a summary section. Merge rather than publishing both.
Capture deadlines. Where a clause carries a date, record it so it reaches the GRC Calendar. This needs deadline.configure.
What the AI does, and does not do
| AI does | AI does not |
|---|---|
| Read the document text | Decide what applies to you |
| Propose discrete candidate obligations | Publish anything |
| Suggest titles and boundaries | Assign owners |
| Retain the source text for each candidate | Determine compliance |
See AI Requirement Extraction for provenance detail and AI Limitations for the authority boundary.
Permissions
| Action | Permission |
|---|---|
| Run the wizard, upload, extract, publish | library.smart_extract |
| Import structured framework catalogues instead | library.import |
| Edit published library content | regulatory_library.manage |
| Capture requirement deadlines | deadline.configure |
| Use AI features | ai.use plus the AI entitlement |
Example
A compliance analyst receives an updated outsourcing circular via the change feed and sends it to Smart Extract.
Extraction proposes 47 candidates. On review:
- 31 accepted as published, several with adjusted titles
- 6 merged into 3 — the circular restates its core duties in an executive summary
- 7 rejected as definitions or cross-references
- 3 split into 6 — each contained a "maintain and review" pairing better held as two obligations
Final publication: 40 requirements. Two carry the transitional compliance date from the circular, captured as deadlines so they appear on the GRC Calendar.
Elapsed time: under two hours, against roughly a day and a half by hand — and every published requirement is traceable to the paragraph it came from.
Troubleshooting
"Extraction failed." The session records an error code. The most frequent causes are an unreadable document (a scanned image without a text layer) and an AI provider that is unavailable or unconfigured. See AI Provider Diagnostics.
"Extraction returned very few candidates." Usually a document conversion problem rather than a model problem. Check the converted text in the session artefact — if the text is garbled, the source was not machine-readable.
"Candidates are too granular." Merge during review. Granularity is a judgement call, and the review step exists precisely to make it.
"Smart Extract is not in the menu." You need library.smart_extract and the compliance core entitlement.
"Published requirements have no owner." Ownership is assigned separately, through the Requirements register or the Workbench. Publication creates the obligation; it does not assign it.