Appearance
Crosswalk Lifecycle
Every mapping in OrviQ is governed. It is proposed by one person, reviewed by another, and its validity period is recorded so the mapping estate can be reconstructed at any past date.
Statuses
| Status | Meaning | Counts as active? |
|---|---|---|
proposed | Awaiting review | Yes — blocks a duplicate for the same pair |
review_required | Flagged as needing re-review | Yes |
approved | Authoritative | Yes |
rejected | Reviewed and declined | No |
retired | Previously valid, now ended | No |
"Active" here means the mapping occupies the obligation-and-control pair. A second mapping for the same pair is blocked while an active one exists — which prevents the register accumulating contradictory parallel claims about the same relationship.
The flow
Proposing
Anyone with mapping.propose can propose a mapping. A proposal records:
- The obligation and the control (or control element)
- The relationship type
- The rationale
- The mapping source and, where relevant, its provenance
Proposals arrive from four directions: a person working in the crosswalk, a bulk import, an AI suggestion pass, or an inspection or audit canonicalisation flow. All four enter as proposed. None can enter as approved.
Reviewing
Review requires mapping.review, and cannot be performed by the proposer. A reviewer can:
| Action | Effect |
|---|---|
| Approve | The mapping becomes authoritative and appears in the SoA and assurance |
| Reject | The mapping is declined with a recorded reason |
| Adjust | The reviewer changes the relationship type, rationale or target, retiring the prior version and recording the adjusted one |
| Retire | An existing approved mapping is ended with a validity end date |
Adjustment is the most useful of these. It lets a reviewer correct an over-claimed relationship — equivalent down to subset, or related to no_match — without discarding the analysis or forcing the proposer to start again.
Governed approval workflow
Mapping approval consumes the organisational workflow layer, using a four-eye maker-checker default:
Draft and propose then Independent mapping review then Approved or Rejected
Where your governance model needs more, six-eye and eight-eye chains are available through workflow template configuration. See Workflow Templates.
The review stage projects into the reviewer's Workbench with a deep link to the exact mapping, and dispatches a notification. Segregation of duties guarantees the task is never routed to the proposer.
Versioning and validity
Each mapping carries valid_from and valid_until timestamps.
| Field | Meaning |
|---|---|
valid_from | When this version of the mapping became active |
valid_until | When it was superseded or retired; unset while open-ended |
When a mapping is adjusted, the prior version is retired with a valid_until and the new version begins with a valid_from. Nothing is overwritten.
This is what makes historical reconstruction possible: asking what the crosswalk looked like in March returns the versions valid in March, not the current ones.
Retiring a mapping
Retire a mapping when the relationship stops being true — the control is decommissioned, the requirement changes, or analysis shows the mapping was wrong.
Retirement records an end date. It does not delete the mapping, and it does not delete its history.
Retire mappings when you retire controls
Retiring a control does not automatically retire the mappings pointing at it. Until the mappings are retired, the obligations they served still appear mapped. Make mapping retirement part of your control decommissioning procedure.
The end-date discipline
A mapping in a terminal status with no recorded end date is displayed as "Ended, date not recorded" rather than being given a fabricated date or shown as open-ended.
This is deliberate. A retired mapping with no end date cannot be placed on a timeline, so historical reconstruction cannot honestly include or exclude it. Showing the gap is better than filling it with a guess.
Governed links
When a mapping is approved, OrviQ maintains a corresponding governed relationship between the obligation and the control. Retiring the mapping retires that relationship — targeted precisely at the pair concerned, so manually created links between the same entities are unaffected.
Permissions
| Action | Permission |
|---|---|
| View mappings and their history | mapping.read |
| Propose | mapping.propose |
| Approve, reject, adjust, retire | mapping.review |
| Import as proposals | mapping.import |
| Export | mapping.export |
Example
A quarterly crosswalk review at a bank covers 1,847 approved mappings.
Findings and actions:
| Issue | Count | Action |
|---|---|---|
| Mappings to controls retired in the last quarter | 23 | Retired with end dates; three obligations dropped to unmapped and findings were raised |
equivalent mappings that reviewers judged subset on re-reading | 11 | Adjusted; each produced a visible coverage gap |
| Duplicate proposals from an AI pass re-suggesting rejected relationships | 8 | Recorded as no_match to stop recurrence |
| Imported catalogue mappings never reviewed | 140 | Prioritised for review; the import had been sitting in proposed for two quarters |
The last row is the one to watch for. Imported proposals do nothing until reviewed. An import that is never reviewed is not a crosswalk — it is a queue.
Troubleshooting
"I cannot propose a mapping — it says one exists." An active mapping already covers that obligation and control pair. Adjust the existing one.
"An approved mapping disappeared from the SoA." It was retired, or its validity window no longer covers the date you are viewing.
"I approved a mapping but requirement assurance did not change." Correct. Mapping is not compliance. Assurance moves when evidence is evaluated and effectiveness derived. See The Requirement Pipeline.
"A reviewer adjusted my mapping and now it shows two versions." That is versioning working. The prior version is retired with an end date; the adjusted version is current.