Edition set cannot be built
The two ways the edition set on the review step can refuse, drawn on the same edition set card as page 2 of this wireframe set. Both are refusals from the server, aggregated into the activation checklist; neither stops the draft cycle from being saved.
Demo helper · state labelState 1 of 2 · a newer edition is required for this date and is not published in the platform catalog. Same card, wizard review step. One cycle throughout this page: the draft FY2026 GRI report from page 2 of this wireframe set, with its intended publication date changed to 15 Feb 2027 to draw the refusal. The draft itself is unchanged; only the date is a what-if.
Edition set
Wizard review step, draft cycle
cannot be built
CycleFY2026 GRI report draft
Reporting periodJul 2025 to Jun 2026
Intended publication date15 Feb 2027what-if date for this drawing, in place of the draft's 30 Nov 2026; this date decides the edition set, and this date is the problem
No edition set can be built for a report published on 15 Feb 2027.
Reports published on or after 1 Jan 2027 must use newer editions of two standards in this edition set: GRI 302, energy, whose newer edition is numbered GRI 103, and GRI 305, emissions, whose newer edition is numbered GRI 102. Neither of those newer editions is published in the platform catalog yet, so there is nothing to build those two parts of the report from.
What you can do
- Press Back to return to the step that holds the intended publication date, and set a date earlier than 1 Jan 2027 if that is when you will really publish. Any date up to 31 Dec 2026 builds an edition set today.
- Or press Save as draft and come back once the newer editions are published in the platform catalog. Everything you have set up is kept, and the draft reopens later from Reporting Cycles.
- Do not enter a date you will not publish on. This date decides which editions your report is built from, so it has to be the truth.
| Standard | Edition for 15 Feb 2027 | Status | Why |
|---|---|---|---|
| GRI 2 | GRI 2 2021 edition | resolved | In force from 1 Jan 2023 onward, with no newer edition scheduled. |
| GRI 3 | GRI 3 2021 edition | resolved | In force from 1 Jan 2023 onward, with no newer edition scheduled. |
| GRI 302 | None available | blocked | From 1 Jan 2027 this standard must be reported under its newer edition, GRI 103, which is not published in the platform catalog. The 2016 edition cannot be used after that date. |
| GRI 305 | None available | blocked | From 1 Jan 2027 most of this standard moves to its newer edition, GRI 102, which is not published in the platform catalog. 305-6 and 305-7 would have carried on under the 2016 edition. |
| GRI 101 | GRI 101 2024 edition | resolved | In force from 1 Jan 2026 onward, so it applies to this date. |
There is no way to accept this message and start entering data anyway, and that is deliberate rather than something missing from the screen. The data entry screens your team fills in are built from the edition set, one question per clause it contains. Until the edition set can be built there is nothing for them to enter against, so activation stays unavailable until the intended publication date is settled or the newer editions are published.
Server refusal 422 PUBLICATION_BLOCKED · standards 302, 305 · missing successors 103, 102
This cycle cannot be activated yet
Everything that has to be settled first:
- The edition set cannot be built for 15 Feb 2027, because GRI 302 and GRI 305 need newer editions that are not published in the platform catalog.
The activation checklist holds every unmet condition in one place, and it is checked again from scratch each time you press Activate cycle. Fixing the intended publication date and pressing Activate cycle again re-runs the whole check.
Back
Back is the route to the intended publication date
Activate cycle is disabled while the edition set cannot be built
Cancel
Save as draft
Activate cycle
Demo helper · state labelState 2 of 2 · no edition covers the publication date at all. Same card, same draft cycle, with the intended publication date changed again, this time to a historical date. Drawn because historical onboarding puts an old date in front of a real admin.
Edition set
Wizard review step, same draft cycle, historical publication date
cannot be built
CycleFY2026 GRI report draft
Reporting periodJul 2025 to Jun 2026an old period would be legal too; periods go back to 1980
Intended publication date30 Jun 2009what-if date for this drawing, in place of the draft's 30 Nov 2026; this date decides the edition set, and this date is the problem
No edition set can be built for a report published on 30 Jun 2009.
The platform catalog holds one edition of each GRI standard it covers, and the earliest of them applies to reports published from 1 Jul 2018 onward. Nothing in it covers a report published in 2009, so four of the five standards have no edition to use.
What you can do
- Press Back to return to the step that holds the intended publication date, and set it to 1 Jan 2023 or later. That is the earliest date from which every standard in this edition set has an edition in force.
- An old reporting period is fine. A reporting period may go back as far as 1980; only the intended publication date has to be one the platform catalog can build an edition set from.
- If you are loading an old reporting year now, set the intended publication date to the date you will publish this report, not the date the original report went out.
- Or press Save as draft and settle the intended publication date later. Everything you have set up is kept, and the draft reopens from Reporting Cycles.
| Standard | Edition for 30 Jun 2009 | Status | Why |
|---|---|---|---|
| GRI 2 | None available | no edition | The only edition here is the GRI 2 2021 edition, in force from 1 Jan 2023 onward. |
| GRI 3 | None available | no edition | The only edition here is the GRI 3 2021 edition, in force from 1 Jan 2023 onward. |
| GRI 302 | None available | no edition | The only edition here is the GRI 302 2016 edition, in force from 1 Jul 2018 onward. |
| GRI 305 | None available | no edition | The only edition here is the GRI 305 2016 edition, in force from 1 Jul 2018 onward. |
| GRI 101 | Not in this edition set | not required | This standard joins a report only when it is published on or after 1 Jan 2026, so it is not part of a 2009 report and is not a problem here. |
Server refusal 422 ASSEMBLY_UNRESOLVED · standards 2, 3, 302, 305
Activation is refused while this stands, and this reason appears in the same activation checklist that state 1 shows. The draft cycle itself is fine: press Save as draft and it can be edited and picked up later from Reporting Cycles.
Back
Back is the route to the intended publication date
Activate cycle is disabled while the edition set cannot be built
Cancel
Save as draft
Activate cycle
Annotations for this page · not proposed UI
Both states above are real server refusals with their own constants. Every drawn behavior traces to a numbered spec section below.
Two refusals, kept apart by construction · spec ii 3.6The selection function walks the standards the framework registry says take part, and can stop for two different reasons. First, a transition is already due: the succession schedule says this standard moves to a newer edition on a date that has passed relative to the publication date, and that newer edition is not published, so the refusal is
PUBLICATION_BLOCKED naming the standard and the missing successor. Second, nothing matches: no published, non-withdrawn edition of that standard has a window covering the date, so the refusal is ASSEMBLY_UNRESOLVED naming the standard. The spec makes the two cases distinct by construction, which is why the screen can always tell the user which of the two happened instead of showing one vague failure. Both constants appear here only in small muted text. THIRD CASE, same constant as the first: a conditional edition whose rule triggers for the publication date but which is not published in the platform catalog is PUBLICATION_BLOCKED, not unresolved, because the conditional rule is itself the evidence that the standard is required (spec ii 3.6 step 1). Concretely: the biodiversity 2024 edition against a date on or after 1 Jan 2026, before it is published, refuses BLOCKED. Spec v2.2 states this; the earlier text left it open.Where state 1 comes from · spec ii 3.3The transition calendar is data, seeded through the registry tool, so a block is derivable before anyone has authored the newer content. The seeded rows: standard 302 moves to 103 on 1 Jan 2027, replacing the whole standard; standard 305 moves to 102 on 1 Jan 2027, replacing 305-1 to 305-5 while 305-6 and 305-7 carry on; standard 304 moves to 101 on 1 Jan 2026, which is how 101 enters a set at all since 304 is never authored here. State 1 is the 2027 pair firing while their successors are unpublished. The 305 row's "two disclosures would have carried on" wording comes from that partial map, and page 2 of this wireframe set shows the same map as an exclusion list when the successor does exist.
Refusals reach the user through activation · spec ii 6.1While the cycle is a draft, resolution is a preview and is not stored, so a blocked preview is information, not damage. At activation the resolution runs again inside the cycle critical section and any of the three assembly refusals, blocked, unresolved, or a bad early-adoption choice, joins the single activation checklist alongside every other unmet condition, per spec i's aggregation rule. That is why state 1 draws the activation checklist with one entry rather than a lone toast: the same checklist carries a missing methodology lock or an empty scope when those apply. Activation re-checks every precondition from scratch, so nothing is remembered from a previous attempt.
Question for the PM · which date should the guidance name? Spec ii 6.1 and 7.1Spec ii 6.1 requires the unresolvable-date refusal to carry "guidance naming the earliest supported publication date" and does not fix which date that is. Two readings. Drawn here: 1 Jan 2023, the earliest date from which every standard in the authored set has an edition in force, so the earliest date a COMPLETE set can be built. Alternative: the earliest date any edition exists at all, 1 Jul 2018 in the platform catalog, which would still refuse because GRI 2 and GRI 3 are missing, making the guidance actively misleading. A third value, 1 Jan 2026, is not a candidate: ruling D-ii-6 supports truthful publication dates from that day onward and explicitly imposes no artificial date constraint, so it is a content fact, not a floor. Ruling needed. Nothing else in this wireframe set depends on it.
Who publishes the newer editions, and the affordance not drawn · the PM's ruling R2-4"Come back once the newer editions are published" is an operator-side dependency, not something the tenant can act on. Catalog editions are authored and published by the platform operator (Evercomm) through the registry tool, so the admin looking at this refusal has no control over when GRI 102 and GRI 103 appear in the platform catalog. That is why the second recourse is Save as draft rather than a task the admin can finish. Deliberately not drawn: a "tell me when these editions are published" affordance on this refusal. It is a plausible later nicety and it would need a notification channel, an operator-side publish event to hang it on, and a decision about who receives it, none of which spec ii settles. Flagged here rather than sketched, so the review sees the gap as a choice. The PM's related question, whether the blocked state is an I1 limitation, is answered in the workspace record rather than on this drawing: the refusal is permanent mechanics, and the specific 2027 case is a content gap because GRI 102 and GRI 103 sit outside I1's authored content scope (spec ii 7.1). When they are authored is an open planning decision; the deadline arrives with the first client cycle that publishes on or after 1 Jan 2027.
Why the wizard footer is drawn on both refusals · the PM's ruling R2-4The bar under each state card is the STANDARD wizard footer from the review step, the same one page 2 of this wireframe set draws on the resolved case. It is repeated here because the PM asked which button or link a user presses to follow each recourse: a refusal that names a recourse without showing its control is a dead end in practice. Nothing new is proposed. Back and Save as draft are the existing wizard controls; Activate cycle is drawn present but disabled, because removing it would hide the action the admin came to this step for and would leave them unsure whether the refusal is temporary. Each recourse in the "What you can do" list now names the control that carries it out.
Dates in this wireframe set · convention noteEvery valid publication date in this wireframe set is 1 Jan 2026 or later, per the decided position in spec ii 7.1. The 30 Jun 2009 date in state 2 is deliberately invalid and exists only to draw the refusal; it is not a proposal that such dates be offered. Both states are the SAME draft cycle with a what-if publication date, so this wireframe set carries no third cycle. Historical onboarding itself is supported: spec i puts the 1980 floor on reporting PERIODS, not on publication dates, so a cycle covering an old year is legal and its publication date simply has to be a date the platform catalog can build an edition set for. That interaction is specified, not accidental.
Vocabulary and severity · proposal, PM can veto"Edition set" and "edition" are proposed words; see the wireframe set index. Two smaller choices to confirm. Colour: both states are drawn in the destructive red used for real refusals rather than amber, because the user cannot proceed. Per-standard table: the refusals name only the standards that failed, but the per-standard table also shows the ones that resolved, so the admin can see the report is mostly buildable and exactly what is missing. The alternative is a bare error message with no table, which is shorter and less useful.