Demo helper GRI Catalog Admin · Admin wireframes (spec ii) Decision exhibit · Sidebar navigation options Invented data · Bluefin Foods Group (fictional tenant)

Sidebar navigation options · six candidate left panels, side by side

Ordered by the PM on 2026-08-24 to support his navigation decision. Each panel below draws the complete left panel of the GRI-enabled admin view, in the product's real sidebar styling. This page compares left-panel structures only; there is no page content behind any of them. In every option, legacy tenants without GRI keep today's sidebar unchanged, and the view the data-entry role sees is stated in each panel's note.

Annotation · DECIDED 2026-08-24The PM chose Panel 3. His reasoning on record: the shareability answer (none of the four added items is GRI specific) killed Panel 2, which made Panel 3 the stronger minimal option; the discoverability cost of folding Stakeholder Groups into the Reporting Cycles surface is mitigated by a hover affordance on the Reporting Cycles menu item that reveals its inner destinations. The exhibit stays as built for the record. Panels 5 and 6 draw the two external reviewer trees exactly as recorded in the blind critique round of 2026-08-24. Panel 2 draws the PM's own idea. Panels 3 and 4 are workspace syntheses prepared for this exhibit. Panel 1 is the baseline: the accepted wireframe set as drawn.
Annotation · what is fixed in every optionExisting production items are never renamed and never moved: every difference between the six panels touches only the flag-gated GRI additions (Reporting Cycles, Stakeholder Groups, Value Chain, Frameworks and Access). Both external reviewers, blind and independently, direct KPI Configuration back to its original three members and file the same P1 against Panel 1; Panels 2 to 6 each resolve that crowding in a different way. The spec fixes no menu placement, so any of these trees is a wireframe-and-build change, not a spec change.
Legend
Itemmoveddiffers from Panel 1 (moved here, or a new group) proposedthe reviewed set's tag for its three additions, kept where an item sits in its Panel 1 place Itemnot a menu item; reached from inside a surface
Panel 1As drawn today
Note to the PMSource: the accepted spec ii wireframe set, exactly as drawn and reviewed; it follows the existing product structure, so nothing new has to be learned. Both external reviewers, blind and independently, filed the same P1 against it: Value Chain is entry work filed as configuration, and the entry role that writes value-chain facts cannot reach it there. Entry role sees: ESG Data Entry only; Value Chain is unreachable, or depends on a permission exception.
Panel 2The PM's idea: one GRI group
Note to the PMSource: the PM's own idea, 2026-08-24. The whole GRI flow lives in one named place, easy to explain and easy to flag-gate as a unit. Costs: the group is named after one framework, so a second framework delivered this way needs a second group or a rename, and Value Chain inside an admin-flavored group still leaves the entry-role reachability question to a permission exception; a sub-choice is open on whether Frameworks and Access joins the group (drawn staying under Administration). Entry role sees: ESG Data Entry only; Value Chain depends on that exception.
Panel 3Idea 1: promote the hub, fold the registryCHOSEN by the PM · 2026-08-24
Note to the PMSource: workspace synthesis prepared for this exhibit, 2026-08-24. Only two items are added to the sidebar, and the cycle hub carries its own stakeholder registry the way the journey actually uses it, since snapshots are taken from the registry at activation. Cost: Stakeholder Groups loses direct discoverability and depends on the Reporting Cycles surface exposing it well. Entry role sees: ESG Data Entry plus Value Chain.
Panel 4Idea 2: one new item, entry work stays where entry is
Note to the PMSource: workspace synthesis prepared for this exhibit, 2026-08-24. The minimal change with the biggest flow payoff: the entry role finds all of its entry work in the one place it already goes, which dissolves the reviewers' shared P1 with zero entry-role navigation change. Cost: the entry surface grows a second content type, and admins confirm value-chain facts from inside the entry surface rather than a dedicated page. Entry role sees: ESG Data Entry only, and that suffices because value-chain entry lives inside it.
Panel 5External reviewer A (Codex)
Note to the PMSource: External reviewer A (Codex), blind critique round of 2026-08-24, tree drawn verbatim. The reporting prerequisites are grouped in journey order with the access status first, and the group name is framework-agnostic, so it scales to later frameworks without a rename. Cost: a second setup group to learn, and the access card leaves the Administration home where entitlement-type things live. Entry role sees: ESG Data Entry plus Value Chain.
Panel 6External reviewer B (Grok)
Note to the PMSource: External reviewer B (Grok), blind critique round of 2026-08-24, tree drawn verbatim. No new groups at all and everything is one click; the reviewer keeps Frameworks and Access under Administration and pairs it with an in-page pointer from the cycle surface when access is disabled. Cost: the ESG Data Management section grows to eight top-level rows, and stakeholder work sits in the main section despite being rare admin work. Entry role sees: ESG Data Entry plus Value Chain.
Annotation · how to read the entry-role lineThe entry role's sidebar is not drawn separately because it is derivable from each panel: the role sees ESG Data Entry, plus Value Chain wherever Value Chain is a top-level item (Panels 3, 5, 6). In Panels 1 and 2, Value Chain sits inside a configuration-flavored group the entry role does not see, so its reachability rests on a permission exception that would have to be designed. In Panel 4 the question dissolves, because value-chain entry is an area inside the entry surface itself.