Appearance
The Requirement Pipeline
The Requirement Pipeline is the spine of OrviQ. It describes how a sentence published by a regulator or standards body becomes an obligation your organisation can be held to, and then becomes a defensible statement about whether that obligation is met.
Every stage in the pipeline is a separate, individually auditable fact. Nothing in OrviQ collapses two stages into one, and no stage is reached by inference from an earlier one.
The pipeline at a glance
Stage 1 — Regulatory Source
Question answered: Where does the obligation come from?
A Regulatory Source is a monitored publication point: a regulator circulars page, a standards body document feed, or a manually curated source. Sources are registered in Regulatory Sources (/reg-intel/sources) with an authority, a source type (webpage, document_feed, manual) and a status (active, paused, retired).
Sources produce Regulatory Changes — detected updates that appear in the change feed for triage. A detected change is information, not an obligation. A person triages it before anything downstream happens.
Boundary: A source publishing a document does not create requirements. Detection is separate from adoption.
Stage 2 — Framework / Regulatory Content
Question answered: What is the authoritative text?
Regulatory content lives in the Regulatory Library as frameworks and their clause structure. This is the library layer — a reference record of what the authority actually wrote.
A critical property: library content is never mutated by a tenant compliance decision. Your judgement that clause A.8.1 does not apply to you does not edit A.8.1. It creates a separate, governed decision record that points at A.8.1.
Boundary: Library content is the text. It carries no ownership, no status and no applicability.
Stage 3 — Extraction
Question answered: What discrete obligations does this document contain?
Long regulatory documents are prose. OrviQ turns prose into discrete, addressable requirements via:
- Smart Extract (
/smart-extract) — an AI-assisted wizard that reads an uploaded document and proposes candidate requirements together with the source text they came from. - Framework import — loading a structured framework catalogue.
- Manual authoring — writing requirements directly.
AI extraction proposes. Every candidate carries its provenance and must be reviewed and published by a person before it becomes a requirement. See AI Requirement Extraction.
Boundary: An extracted candidate is not a requirement until a human publishes it.
Stage 4 — Requirements
Question answered: What are we required to do?
A Requirement is a single rule, clause or statutory mandate. It carries the framework, the clause code, the title, the source text and its structural position. It is the unit everything downstream attaches to.
Requirements are viewed and worked in the Requirements register (/requirements) and its per-requirement workspace.
Boundary: A requirement existing in your library says nothing about whether it applies to you, whether anything addresses it, or whether you comply.
Stage 5 — Obligations
Question answered: Who has to do what, specifically?
A single regulatory clause frequently contains several distinct duties. "The institution shall maintain an access control policy, review privileged access quarterly, and retain review records for five years" is one clause and three obligations, likely owned by three different people.
OrviQ decomposes requirements into obligations — the ownable, assignable, individually completable units. Obligations surface as Compliance Activities (/activities) and flow into the Workbench.
Boundary: Decomposition changes granularity, not authority. The requirement remains the regulatory fact; obligations are how work is organised beneath it.
Stage 6 — Scope
Question answered: Where does this apply, and across what population?
Scope is declared before assurance, not derived after it. A Declared Scope (SCP-YYYY-NNNN) is a named boundary — "Payment Gateway Production Environment", "EU Employee HR Data", "Group Treasury Function".
Scopes are one of two kinds:
| Scope type | Denominator | Example |
|---|---|---|
population | The count of effective-dated members at the evaluation instant | 412 production servers |
qualitative | 1 — a single governance fact | The annual board risk-appetite review |
Scope membership is effective-dated: members carry valid_from and valid_until and are never destructively deleted. This is what makes historical assurance reproducible — asking "how many systems were in scope in March?" returns the March answer, not today's.
See Scope Registry and Assets & Inventory.
Boundary: Assets are what exists. Scope is where something applies. Different questions, different registers.
Stage 7 — Applicability
Question answered: Does this obligation actually apply in this scope?
Adopting a framework for a scope creates a Framework Adoption (FAD-YYYY-NNNN) and seeds an Applicability Record (APP-YYYY-NNNN) for every obligation in that framework.
Each applicability record carries two independent states:
- Applicability state —
Applicable,Not Applicable,Under Review - Governance state —
draft,pending_review,approved,rejected
Marking something Not Applicable requires a written justification, and the decision only takes authoritative effect once approved by someone other than the person who made it.
See Framework Adoption and Scope & Applicability.
Boundary: Applicable means "we are on the hook for this." It does not mean anything is implemented.
Stage 8 — Control Mapping
Question answered: What in our organisation is meant to address this?
A Crosswalk mapping is a governed statement that a specific control bears a specific semantic relationship to a specific obligation — equivalent, subset, superset, intersection, compensating, supporting, related or no_match.
Mappings are proposed (by a person, by an import, or by an AI suggestion) and approved by a different person before they are authoritative.
See Control Crosswalk.
Boundary — the single most important one in the platform: mapping is not compliance. Declaring that your privileged access control addresses a privileged access requirement asserts a design intention. It asserts nothing about whether the control exists in practice, operates, or works.
Stage 9 — Evidence
Question answered: What proves the control actually operates?
Evidence enters OrviQ through two paths:
- Manual — documents, reports and attestations uploaded into the Evidence Register and linked to controls and requirements.
- Automated — external Connections feed Collectors, whose Collector Runs produce Evidence Assertions carrying an observed state (
pass,fail,partial,info,inconclusive) about a specific subject at a specific time.
See Evidence Register and Evidence Fabric.
Boundary: Evidence existing is not evidence coverage. One passing MFA report proves something about the systems it covered — not about the other 400.
Stage 10 — Control Effectiveness
Question answered: Is the control working, across the whole population, right now?
Indicators (IND-YYYY-NNNN) are deterministic rules attached to a control. Each evaluation produces an immutable Indicator Result (INR-YYYY-NNNN) recording expected count, observed count, fresh count, pass and fail counts, coverage percentage, the rule applied and a plain-language explanation.
Control effectiveness is then derived — never carelessly averaged:
| Condition | Effectiveness |
|---|---|
| No active indicators | not_assessed |
| Any mandatory indicator fails | ineffective — cannot be averaged away |
| No usable evaluated evidence | not_assessed |
| All pass, nothing stale or missing, coverage ≥ 100% | effective |
| Genuine passing evidence with coverage gaps, staleness, or a non-critical failure | partially_effective |
See Control Effectiveness and Indicators.
Boundary: Effectiveness is about the control. It is not yet a statement about the obligation.
Stage 11 — Requirement Assurance
Question answered: Is the obligation satisfied?
The Requirement Assurance engine combines the preceding facts into an explicit satisfaction status — satisfied, partially_satisfied, not_satisfied or not_assessed — alongside the dimensions that produced it and an explanation you can put in front of an auditor.
It also supports obligations that have no control at all. A duty to file a return by a date is satisfied by evidence of filing, not by a control. OrviQ evaluates these through direct evidence assertions rather than fabricating a placeholder control.
Boundary: Satisfaction is the objective answer. It is not yet your organisation's position.
Stage 12 — Compliance Determination
Question answered: What is our governed, defensible position — and who signed it?
Determination adds the organisational layer on top of objective satisfaction: the governance disposition (compliant, accepted_deviation, remediation_required, unassessed), any approved exception covering the gap, and the review state recording who signed off and when.
Worked example: privileged access
A regulation contains: "Institutions shall restrict, monitor and periodically review privileged access to critical systems."
| Stage | What exists | What it does not yet mean |
|---|---|---|
| Source | Circular published on the authority site, detected in the change feed | Nothing yet applies to you |
| Requirement | PA-4.2 — Privileged access restriction and review in the library | You may not be in scope |
| Obligations | (a) restrict, (b) monitor, (c) review periodically — three ownable units | Nobody has been assigned |
| Scope | SCP-2026-0004 — Core Banking Production, 38 systems, effective-dated | The obligation may still not apply |
| Applicability | APP-2026-0117 = Applicable, approved by the Compliance Manager | Nothing is implemented |
| Mapping | Control CTL-2026-0041 — Privileged Access Management mapped as equivalent, approved | The control may not exist in practice |
| Evidence | Quarterly access-review report plus a daily collector reading the PAM platform | It may cover only 31 of 38 systems |
| Effectiveness | Indicator IND-2026-0009 — mandatory, rule all_pass, 31/38 fresh, coverage 81.6%, two subjects failing → ineffective | — |
| Assurance | Requirement satisfaction = not_satisfied, because a mapped control is ineffective | — |
| Determination | Governance disposition = remediation_required; a finding is raised and an action plan opened. Had an approved exception EXC-2026-0012 been in force, disposition would read accepted_deviation — while satisfaction would still read not_satisfied | — |
Every row is a separate record with its own reference, owner, history and approval trail. That is the point.
The stages are not interchangeable
These substitutions are structurally impossible in OrviQ
You cannot reach a later stage by asserting an earlier one harder.
- Adding a mapping does not produce evidence.
- Adding evidence does not produce coverage.
- Reaching coverage does not produce effectiveness.
- Reaching effectiveness does not produce satisfaction.
- Reaching satisfaction does not produce a governed determination.
- Approving an exception does not produce satisfaction — it records an accepted deviation.
This is deliberate. A platform that lets a mapping turn a dashboard green is a platform that will eventually tell a regulator something untrue.
See Separation Principles for the full list and the reasoning behind each one.