GRI Catalog Admin · wireframe set (spec ii)

The catalog and data surfaces that sit underneath a GRI reporting cycle. The cycle itself, its list, its create wizard, and its detail tabs are drawn in the companion wireframe set; this wireframe set draws what the cycle is filled with.

What this wireframe set covers

A GRI reporting cycle is an empty container until something tells it which version of each standard the report is built from, and what the people filling it in are actually asked. This wireframe set draws that layer. The first three pages show the edition set: the list of standard editions a cycle resolves from its intended publication date, the two ways that resolution can refuse, and the draft-only control for adopting a newer edition ahead of the date it becomes required. The next four pages show data entry for the three new answer shapes a GRI clause can ask for, plus what a data collector sees when a clause asks for something this build cannot draw. The last four pages show the two supporting registries GRI needs, value chain facts and stakeholder groups, and the read-only card that says this workspace has GRI at all.

Companion set, already reviewed and closed: GRI Reporting Cycles admin wireframes (spec i). Read that wireframe set first if you have not seen it. Every page here reuses its page chrome, its wizard and detail framing, and its annotation conventions.

How to read these pages

Anything drawn in plain product styling is proposed UI. Anything amber-tinted with a dashed border is review scaffolding and would never ship:

Annotation · not proposed UIBlocks like this one carry the spec citation behind a drawn behavior, the refusal constants, and open questions for you. They are notes to the reviewer, not screen copy. Every page carries at least one.

Demo helperBlocks tagged this way are navigation aids and stand-ins: the dark bar at the top of every page, the cross-page links, the state labels that separate two drawings of one screen, and the invented-data callouts.

Inline markers use the same style: Annotationlike this, attached to a single row, chip, or field. The application shell is identical on all eleven wireframe pages so the surfaces can be compared, and it carries the existing product navigation unchanged. The three items this wireframe set asks to ADD are the only ones tagged proposed in the sidebar: Stakeholder Groups, Value Chain, and Frameworks and Access. Where each of them belongs in the menu is a proposal you can move.

The tenant is Bluefin Foods Group, a fictional multi-entity food producer with sites in Singapore, Thailand, and Malaysia. Every organization, person, count, date, and identifier is invented. The people are Mei Tan (Sustainability Admin), Priya Nair (a second Sustainability Admin), and Daniel Ong (Site Manager, the data-entry role). No real client, company, or colleague appears anywhere in this wireframe set.

Standard numbers and clause codes are identifiers and are drawn as they really are (GRI 305-1-a). Standard, disclosure, and clause titles are composed in our own words throughout: close enough to be recognizable, deliberately not the published wording. Guidance text on the entry pages is a labelled placeholder for the same reason. Do not review the titles as copy; review the surfaces.

Pages

Twelve pages in the reviewed round: this index, then the eleven wireframes below. Prev and next links at the top of each page walk them in order. One supplement, page 8b, was added after the round closed, at the PM's order; it is marked as such below and changes nothing on the other pages.

The edition set · what a cycle is built from
01Edition set preview (resolved)
The resolved list of standard editions in the cycle wizard review step, with counts, effective windows in plain words, and the line that says when the edition set locks.
02Edition set preview (blocked and unresolvable states)
The same surface refusing, twice: a newer edition is required for the chosen publication date but is not published in the platform catalog, and a publication date no edition covers at all.
03Early adoption of a newer edition (draft only)
Choosing a published newer edition before the date it becomes required, what that changes in the edition set, why an unpublished edition cannot be chosen, and the confirmation that records the decision.
Data entry · the three new answer shapes and the error state
04Data entry: date answer
A clause whose answer is a single date: the input, its validation, and the omission alternative.
05Data entry: table answer
A clause whose answer is a table: fixed columns, required cells, row-level validation, and the omission alternative.
06Data entry: written answer (structured)
A clause whose answer is written text with structure: the allowed blocks, what is not allowed, and how it is stored.
07Data entry: unsupported answer type (error state)
What a data collector sees when a clause asks for an answer shape this build cannot draw. An explicit dead end, never a guessed numeric box.
Supporting registries · the two schema bones GRI needs
08Stakeholder groups and cycle snapshots
The tenant's stakeholder-group registry, and the dated snapshots each cycle keeps of it, one version per take.
8bIntro overlay pattern (supplement) supplement · added after the round closed
Ordered by the PM in his part 2 review of 2026-08-24: the first-entry introduction overlay and its About this page reopen control, drawn once on the Stakeholder groups surface as the one pattern reused by Value Chain and Frameworks and Access. Redrawn the same day after a three-concept round: it now carries the final blended design, the page-in-miniature base with the Codex headline and connector labels grafted in (decision exhibit). Not part of the reviewed round; existing pages are unchanged and unrenumbered.
09Value chain facts (list and entry)
Facts recorded about the parts of the value chain outside the reporting boundary: the fact list, the revision history, and the entry form.
10Value chain facts: confirmation by a second person
Confirmation by someone other than the person who entered the fact, what confirmation freezes, and why the button can be unavailable.
Access
11GRI access card (read-only)
The read-only card that shows this workspace has GRI, whether it is on, and since when. No controls.

Decision exhibit, not part of the reviewed set: Sidebar navigation options, six candidate left panels drawn side by side to support the PM's navigation decision (2026-08-24).

Decision exhibit, not part of the reviewed set: Intro overlay designs, three candidate first-entry introductions drawn beside the rejected page 8b baseline to support the PM's intro presentation decision (2026-08-24).

Proposed vocabulary for this wireframe set

Annotation · proposal, PM can veto · spec ii 3.6 and 3.4 Spec ii 3.6 calls the resolved list of standard versions an assembly, and spec ii 3.4 calls each member a standard version. Neither word survives contact with a sustainability manager. Proposed user-facing words, used consistently on every page here:

edition setthe whole resolved list a cycle is built from (spec: assembly)

editionone version of one standard, for example the GRI 302 2016 edition (spec: standard version)

If you veto either word, say what replaces it and this wireframe set is redrawn; nothing else depends on the choice. Internal terms (assembly, assemblyKey, catalogEpoch, catalogAssemblyId) stay inside annotations like this one and never appear on a screen. The internal framework registry code stays out of the interface entirely; the only framework wording a user sees is the display name "GRI (native)", and only where the framework itself is named.

What this wireframe set is drawn against

Source of record. Build spec ii, versioned catalog and gate (c) bones, v2.2 of 2026-08-24, with all eight D-ii rulings decided. This wireframe set was first drawn against v2.1 and then corrected against v2.2; four gaps this drawing exposed (the unit inside the attestation digest, the per-type format refusal code, the value-chain payload rule, and the omission route on an unknown answer format) were written into the spec as a result, so the pages now quote the contract rather than proposing around it. This wireframe set exists to satisfy the remaining wireframe round named in that spec's section 8 surface list. Every drawn refusal, role, and freeze point traces to a numbered section; the citation sits in the annotation next to it.
Surfaces the spec names, and this wireframe set draws. The edition set preview inside the wizard and cycle detail, including its blocked states (spec ii 8, 6.1); the early-adoption control writing through its own draft-only endpoint (6.1); the three new answer shapes and the explicit unsupported-type error state (3.9); typed omission alongside them (3.10); the stakeholder registry with snapshot versions (4.2); the value chain fact surface with revisions and second-person confirmation (4.1); and the read-only access card (6.5).
What decides the edition set. The cycle's intended publication date, plus any early-adoption choices. Nothing else. While the cycle is a draft the edition set is a preview, worked out on demand and not stored. At activation it is resolved once more and frozen onto the cycle, and every later screen reads the frozen list (spec ii 2.5, 6.1).
Forward content, drawn but not reachable in I1. Page 03's eligible row needs a newer edition to be published in the catalog. That content is an I2 workstream, so in I1 the list of editions available to adopt is normally empty; the empty state is drawn on the same page. The control itself is an I1 surface and is reviewed here.
The two cycles this wireframe set uses. One workspace, one active cycle and one draft, and every page shows one of them. Active: FY2025 GRI report, period Jan 2025 to Dec 2025, intended publication date 30 Jun 2026, activated 12 May 2026 by Mei Tan, methodology lock provisional, stakeholder snapshot version 1 taken at activation and version 2 refreshed 15 Jun 2026. Pages 05 to 11 all show it. Draft: FY2026 GRI report, period Jul 2025 to Jun 2026, intended publication date 30 Nov 2026. Pages 01 to 03 show it, because edition-set preview, its refusals, and early adoption are draft-only states; page 02 changes only the date, as a labeled what-if, to draw the two refusals. The access grant on page 11 is dated 12 Mar 2026, before both, which is the order spec ii 6.1 requires: a cycle cannot bind before the grant it is checked against.
Dates. Every valid publication date in this wireframe set is 1 Jan 2026 or later, per the decided position that I1 supports truthful publication dates from that day onward (spec ii 7.1, ruling D-ii-6). Reporting periods can be much earlier; historical onboarding is a supported case. The one earlier publication date in this wireframe set, on page 02, is deliberately invalid and exists only to draw the refusal.

Open items for your review

Vocabulary. "Edition set" and "edition", per the annotation above. Yours to veto.
Cycle naming in this wireframe set. Cycles are referred to by readable names here ("FY2025 GRI report", "FY2026 GRI report") because a five-line label is unreadable in a wireframe. Spec i builds the real label from persisted fields and has no free-text name field. The readable names are a drawing convention, not a proposal for one; each page also shows the real label. Say the word if you want the labels drawn verbatim instead.
Guidance naming the earliest usable publication date. Spec ii 6.1 requires the unresolvable-date refusal to name the earliest supported publication date, without fixing which date that is. Page 02 draws one reading and states the alternative. Ruling needed there, not here.