Crosswalk
The Crosswalk view surfaces Gap, Covered, and Implemented states — making the difference between documented obligations and functioning governance visible at a glance.
The Crosswalk view is where the analytical purpose of Nexus becomes most legible. Switch to it from the board header.
It presents your artefact's structure in a table format, with each row corresponding to a section or clause and columns representing the controls those clauses map to. Most importantly, each row carries a coverage state — Gap, Covered, or Implemented — that tells you whether real operational governance exists behind each mapped obligation.
[Screenshot needed] PLACEHOLDER IMAGE: The Crosswalk view showing a table with EU AI Act articles listed on the left, their mapped controls visible, and coverage state badges (Gap in red, Covered in amber, Implemented in green) visible on each row
The three coverage states
These states are the core of what makes Balcony different from a static compliance register. They track the progression from "we know about this obligation" to "we have a functioning process behind it."
Gap
The control has mappings from one or more artefact nodes, but no mechanism has been linked to it in Mechanic. The obligation is documented; the operational reality behind it is not.
A Gap is not necessarily a problem — it might reflect work in progress, or a control that is genuinely not relevant to your context. But it is something that needs an account. An untended collection of Gaps is a compliance risk.
Covered
A mechanism exists in Mechanic and has been linked to this control, but has not yet been assessed as fully operational. The link has been made; the mechanism's components have not all been confirmed.
Implemented
The linked mechanism has been assessed and its components confirmed as present and adequate. This is governance that has moved from documented intent to demonstrated operational reality.
The Gap → Covered → Implemented progression is the central claim of the platform: that the difference between "we have a policy" and "we actually do this" can be made visible and tracked. See How it fits together for a full account of how this works across both tools.
Reading the table
The Crosswalk table organises your artefact hierarchically. Parent nodes (chapters, articles) show an aggregate indicator of the coverage states of their children — so you can read the compliance picture at multiple levels of detail.
- A parent node where all children are Implemented shows as fully covered.
- A parent node with any Gaps is flagged, making unmapped territory easy to spot even in large frameworks.
The table also shows the expectation types of each clause (Obligation, Requirement, Practice, etc.), so you can prioritise hard obligations over recommended practices when deciding where to focus mechanism work.
Filtering in the Crosswalk
The same domain filter and expectation type filter available in the Explore view also work in the Crosswalk view. Filtering to a specific domain narrows the table to controls within that domain, which is useful when reviewing a particular governance territory across all loaded artefacts.
Mapping lifecycle stages
Each mapping between an expectation node and a control moves through a lifecycle:
| Stage | What it means |
|---|---|
| Draft | Initial mapping, not yet reviewed |
| Reviewing | Under review — being validated for accuracy |
| Live | Reviewed and confirmed. This mapping is active. |
| Deprecated | No longer current. Kept for audit trail but not active. |
Only Live mappings contribute to the crosswalk's coverage picture. Drafts are captured as work in progress; they show in the table but are visually distinguished from confirmed mappings.
What next?
- Controls — see the controls view for a framework-first perspective on your crosswalk.
- How it fits together — understand how Gap → Covered → Implemented links Nexus to Mechanic.
- Building a mechanism — start work on a mechanism to move a Gap to Covered.