Frameworks and access
Bluefin Foods Group · which reporting frameworks this workspace has access to
AnnotationPage placement is a proposal. Spec ii 6.5 defines the read and its content, not where it sits in the menu. The three sidebar items marked "proposed" are the additions this wireframe set asks for; every other item is existing product navigation, unchanged
GRI (native)
Reporting framework access for this workspace
enabled
FrameworkGRI (native)
StateEnabled
Since12 Mar 2026
Enabling or disabling GRI (native) for a workspace is done by Evercomm in this phase. This card shows the current state.
Stand-in · existing settings content, not part of this proposal
The rest of this settings page stands in as a hatched block: the workspace's existing framework and module settings, drawn only so the card above is seen where a reviewer would actually meet it. This wireframe proposes one card, not a redesign of this page.
Annotation · not proposed UIThis card exists because of ruling D-ii-5, decided 2026-08-24. Granting and revoking stay script-only operations run by Evercomm in I1, with audited events, and the PM's amendment added one requirement on top: the access state must be VISIBLE on the platform in I1, because SG-side review starts in I1 and its non-technical reviewers need to see access as part of the flow rather than take it on trust. This card is that surface and nothing more. It has no buttons by design, and its absence of buttons is the proposal, not an unfinished state.
Variant · the same card after access is disabled · annotation frame only, the white card is the proposal
Same card, same read, later state. The card's job in this state is to explain what still works, because that is the question a reviewer actually has.
Disabled state · read from the latest access event
Plain words rather than a policy statement: the reader wants to know whether the report they are in the middle of is now stuck. It is not. What stops is starting new cycles and activating them, and the card now says the activation half out loud, because a draft plus a later revoke is exactly the case an administrator will hit and the case ruling D-ii-8(b) refuses. The card copy names the framework by its display name, "GRI (native)", the only framework wording a user ever sees. The operator sentence stays, moved to the card's muted help line: ruling D-ii-5 wants a reviewer to see who operates enabling, not to guess.
Explainer, not proposed UI · a workspace that was never granted access
Drawn only to make the masking rule visible to a reviewer, and it is the NEVER-GRANTED case specifically. There is deliberately no "GRI not enabled" card and no upsell state: a workspace that was never granted access does not learn that the framework exists from this page. A workspace whose access was granted and then revoked is the other tile, and it does see its card, as Disabled.
Explainer, not proposed UI · where this card sits in the flow
The ruling asked for the state to be visible as part of the flow, not filed somewhere a reviewer would have to be told about. This is the walk a non-technical reviewer takes, with the card as its first stop.
Explainer · the five steps a reviewer walks, drawn as plain steps and not as a screen
1
Access
This card. The workspace has GRI, and the state is visible rather than assumed.
2
New cycle
A reporting cycle is created as a draft with its period and intended publication date.
3
Edition set preview
While the cycle is a draft, the resolved editions are a preview and nothing is bound.
4
Activate
Activation checks access again, then binds and freezes the edition set with the cycle.
5
Entry and reporting
Every surface from here on resolves through the frozen edition set.
Spec ii 6.1 is the source for steps 3 and 4: while a cycle is a draft, resolution is computed on demand and never persisted; at activation, inside the cycle's critical section, access is re-checked and the edition set binds and freezes with the status transition. Disabling access later does not reach back into step 4, which is exactly what the disabled card's copy has to convey.
Explainer, not proposed UI · what disabled access looks like at step 2
The disabled card says new GRI cycles cannot be created. This is what that refusal actually looks like to the person creating one, and it is quieter than a refusal message.
Explainer · framework choice on the new-cycle step, access disabled
Select a framework
Stand-in · the frameworks this workspace already uses
The existing framework options stand in as a hatched block. They are unaffected by GRI access and are not part of this proposal.
no GRI option is present
Consistent with the masking rule in spec ii 3.7: a workspace with no active access does not see the framework, and asking the API for it directly gets the same answer as asking for a framework that does not exist. A greyed-out row would leak the framework's existence to a workspace that is not entitled to it, so this state is an absence rather than a refusal. Drawn as an explainer because the new-cycle step itself belongs to the spec i set.
Annotation · not proposed UISpec ii 6.5 · this reads current state only.
GET /v1/framework-entitlements is admin role and scoped to the requesting workspace. It returns, per native framework, the display name, whether access is currently granted or revoked, and the date that state took effect, derived from the latest access event. It exposes NO event notes and NO event history in I1, which is why this card carries three rows and no timeline. Read-only: no grant or revoke surface exists in the UI in I1, and the registry tool stays the only write path (spec ii 5.5).Annotation · not proposed UISpec ii 3.7 and 6.5 · masking, and the line between "never granted" and "revoked". Access is stored as append-only events per workspace and framework, and current state is the latest event. The two cases are deliberately different, and spec v2.2 states both. NEVER GRANTED: a workspace with no grant event for the framework receives NOTHING for it, so no card is rendered here, no option appears in any picker, and no menu entry exists; the framework stays undiscoverable, which is the third tile above. REVOKED AFTER A GRANT: the workspace DOES see the row, as state Disabled with its date, which is the second tile above, because that workspace already knows the framework exists and the ruling wants the state visible rather than the surface vanishing under them. Spec ii 9.3 tests the two cases separately. At the API boundary the same rule holds for the never-granted case: naming the internal registry code (
GRI-STANDARDS, never shown in the product) returns FRAMEWORK_UNKNOWN, byte-identical to naming a code that does not exist. A never-entitled workspace cannot discover the framework by probing.Annotation · not proposed UISpec ii 3.7 and ruling D-ii-8(b), decided 2026-08-24 · what disabling actually does. Revocation stops growth: new cycle creation and new activations for the framework are refused. It does not cut off existing cycles, because cycle-scoped catalog reads authorize against the access state captured AT THE CYCLE'S EDITION-SET BINDING, persisted on the cycle's binding record, not against current state. The PM's reasoning is recorded with the ruling: historical data should stay understandable and exportable. A hard read cutoff remains available as a future licensing decision and is not I1 behavior, so the disabled card must not imply one.
Annotation · not proposed UIRe-enabling, and why there is no history list. Access events are append-only, so re-granting after a revoke is a new grant event and the enable, disable, enable sequence is representable by construction. The card always shows the latest state and its date. The history exists in the events and in the audit trail; I1 deliberately does not surface it here, per spec ii 6.5. If the PM wants a history strip on this card, that is a scope addition to 6.5, not a drawing change.
Annotation · question for the PMOne thing the spec does not settle: who can open this page. Spec ii 6.5 makes the read admin role, so the page is drawn for an administrator. It does not say what an entry-role user meets if they reach the URL: a 403 page, or the settings area simply not listing this item. Drawn as an admin-only item that a non-admin never sees in the menu, which is the quieter of the two and consistent with masking, but this is a ruling and not a fact yet. A second, smaller one: the card shows a date with no time and no time zone, where the underlying event carries a full timestamp. Drawn as a date because a reviewer is being asked whether access exists, not when in the day it changed.
Annotation · not proposed UIVocabulary in use on this page. "Edition set" is this wireframe set's proposed user-facing word for the frozen collection of standard editions a cycle was activated against (internally the assembly). It appears in the disabled card's copy because that sentence is the one place a reviewer needs it. The internal names, and the registry code, stay out of the product surface entirely.