Demo helper GRI Catalog Admin · Admin wireframes (spec ii) Page 7 of 12 · Data entry · written answer (structured) Invented data · Bluefin Foods Group (fictional tenant)
English
Daniel Ong
Site Manager

FY2025 GRI report · Bluefin Processing TH

Bluefin Foods Group / Processing / Thailand · FY2025 (Jan 2025 - Dec 2025). One question of the cycle, opened for entry. Written answer, built from blocks.
cycle active methodology lock provisional
GRI 3-3 (c) How this site manages its energy use Written answer, in blocks Required by this edition Omission allowed answered 3 blocks
Composed guidance (placeholder) Describe how the site decides on, tracks, and reviews its energy use, and who is accountable for it. Write what actually happens rather than what is intended, and name the review forum and its rhythm.
Enter an answer Report an omission instead
Heading
Who owns energy at this site
Paragraph
Energy use at Bluefin Processing TH is owned by the site technical team and reviewed each quarter by the plant management committee, working from monthly meter readings.
Bulleted list
  • Monthly meter reading, reconciled against the utility invoice
  • Quarterly review with the plant management committee
  • Annual efficiency plan agreed with group technical services in Singapore
Add blockHeadingParagraphBulleted list
Formatting is limited to three kinds of block: a heading, a paragraph, and a bulleted list. No font, size, color, table, image, or link formatting exists here. Pasting is allowed and never refused: the editor converts what you paste into these three blocks, keeping the words and dropping the formatting, and tells you what it dropped. A pasted table becomes paragraphs, one paragraph per table row.
One or the other, never both. A question holds either an answer or an omission. Switching to "Report an omission instead" clears these blocks when you save the omission, and switching back clears the omission. Nothing is cleared until you save.
Cancel Save answer
Question and cycle details the standard edition this question comes from, its answer format and omission rule, when the blocks were last saved, and where this question sits in the reporting cycle Show details
Layout · the PM's part 1 ruling R2-6Data entry is the main function of this page, so it is now the main visual area. Before this pass the question reference card and the cycle context card filled the whole first screen and the block editor started below the fold. Nothing was deleted. The facts a person needs WHILE writing sit in the question strip under the page header: question code, composed question title, answer format, reporting status, whether an omission is allowed, the answered status, and the block count. Everything else moved into the collapsed "Question and cycle details" section under the entry area, one press away, and the state gallery below draws that section OPEN so the review can confirm every row of both former cards survived. The alternatives the PM offered were a card on the right and a card below. The right-hand card was rejected because it takes width the table answer on page 6 of this wireframe set needs, and the four entry pages have to share one layout; it would also narrow the writing column here, which is the worst place to lose width. A plain card below was rejected because it keeps the full reference block permanently in the scroll for detail a writer rarely needs mid-sentence. Wireframes are static, so the expander is drawn closed here and open in the gallery rather than toggled.
Annotation · not proposed UIStorage format, decided (ruling D-ii-3, 2026-08-24; spec ii 3.9). A written answer of this kind is stored as RESTRICTED BLOCK-STRUCTURED JSON in the structuredValue slot: an ordered list of typed blocks, each block a small closed shape. Raw HTML is never stored, and a native write carrying raw HTML is REFUSED SERVER-SIDE, not sanitized in the browser and hoped for (test 9.2 names the raw-HTML rejection case). Output is serialized with escaping at render time, so nothing a user typed can execute anywhere the answer is later displayed or exported. The three block kinds drawn here are the reviewable consequence of that decision: a closed block set is what makes the stored shape validatable.
Annotation · not proposed UIWhat this drawing does and does not fix. Ruling D-ii-3 deferred the EDITOR CHOICE to the UX round, so the concrete component is a later decision and nothing here commits to one. This page fixes the INTERACTION SHAPE only: blocks are discrete and reorderable, the block kinds are a short closed list shown to the user, adding a block is an explicit act, and the limits are stated in plain words instead of being discovered when something is silently dropped. Everything inside the block frames is a placeholder for whatever component is chosen.
Annotation · not proposed UIWhat identifies this answer (spec ii 6.4 and 3.8). A native answer is keyed by cycle, clause logical id, topic instance (null throughout I1), organization scope, and period. Native rows carry clauseLogicalId and do NOT populate disclosureId; they never pass through the legacy assignment and entry resolvers. The clause is resolved through the cycle's frozen edition set, so a question outside that edition set refuses with CLAUSE_NOT_IN_ASSEMBLY rather than rendering.
Annotation · not proposed UIExclusivity is structural, not a screen convention (spec ii 3.9 and 3.10). The answer payload is a closed set with exactly one legal slot per answer format: this question uses structuredValue. Every native write is one atomic update that sets the legal slot and unsets the others plus omission, or sets omission and unsets every payload slot. A written answer converted to an omission therefore retains no stale payload; test 9.2 walks the whole transition matrix. The screen copy states the rule in plain words because the user has to know the switch clears, not because the storage needs the warning.
Annotation · not proposed UIOmission contract (spec ii 3.10). Stored shape is {reason, explanation, expectedAvailability} with four reasons. I1 validates SHAPE ONLY and refuses a bad reason with OMISSION_REASON_INVALID; whether an omission is PERMITTED for a given question is enforced in I3, so this screen never claims an omission here is acceptable to a reviewer. SETTLED, and drawn as settled: the I1 shape is the single free-text explanation plus expectedAvailability. The 2026-08-21 plan-review adjudication (GF8.2) recorded per-reason required subfields for the "information not available" case (what is missing, why, steps taken, timeframe); spec ii 3.10 as amended states that the subfield split lands WITH the I3 enforcement work, not in I1, so neither record contradicts the other. One item is still open for the PM and it is only wording: the four reason labels drawn here are composed in our own words, because the spec fixes the enum values and not their display text.
Annotation · not proposed UIOpen items for the PM on this surface. (1) SETTLED: the refusal code is RICH_STRUCTURE_INVALID, 422, named in spec ii 3.9 and listed in the 6.6 error contract, so the gallery state quotes it rather than going codeless. An earlier draft of this page said no code existed; that was true of the spec text this page was first drawn against. (2) The block set is drawn as heading, paragraph, and bulleted list. The spec says "restricted block-structured JSON" without enumerating the blocks, so the three drawn here are a proposal; a numbered list is the obvious fourth candidate and is deliberately left out until the PM rules. (3) Whether a heading block may nest below another heading level is likewise unspecified and drawn flat.
Annotation · not proposed UIRole. Daniel Ong holds ENTRY access. Spec ii 6.2 gives the entry role read access to the two cycle catalog reads (GET /v1/reporting-cycles/:id/catalog and .../catalog/clauses/:logicalId) and 403 on every cycle mutation route; the full matrix is test 9.3. That is why no cycle action appears on this page. The application shell around the page stands in for existing NxStart chrome and is drawn identically on all twelve pages of this wireframe set so the surfaces can be compared; which menu items an entry-role user actually sees is existing product behavior this wireframe set does not restate, and it is not the mechanism that stops the write. The server is.
State gallery · written answer · annotation · not proposed UI
The same question in its paste-refusal, omission, and untouched states. White cards are the proposed rendering; the amber frames are review scaffolding.
The "Question and cycle details" section, opened · nothing was lost in the move
Question and cycle details Hide details
Question codeGRI 3-3 (c)the code the standard edition gives this question; use it when you ask for help
QuestionHow this site manages its energy use
Standard editionGRI 3 (2021 edition)fixed at activation from this cycle's publication date 2026-06-30
Answer formatWritten answer, in blocksheadings, paragraphs, and bulleted lists; no other formatting
Reporting statusRequired by this edition
OmissionAlloweda reason and an explanation are required when you omit
Last saved2026-06-14 16:07 by Daniel Ong
FrameworkGRI (native)
Reporting cycleFY2025 GRI reportbound to its edition set when the cycle was activated; the edition set no longer moves (spec ii 6.1)
Organization unitBluefin Processing THBluefin Foods Group / Processing / Thailand
PeriodFY2025 (Jan 2025 - Dec 2025)
Answer belongs toDaniel OngSite Manager, entry access
This is the same section drawn closed under the entry area on the page above, here opened so the review can check the move row by row. Every row of the two former cards is present and unedited. The question code, the answer format, the reporting status, and the omission rule are deliberately DUPLICATED between this section and the question strip: they are the facts a writer needs without opening anything.
State 2 · two different things, drawn together: what a paste does, and what the server refuses
Pasting, in the editor. A paste is converted, never refused. What came in as 1 heading, 2 paragraphs, and 1 table becomes 1 heading and 5 paragraphs: the table's rows are kept as text, one paragraph each, and the table itself is dropped. The editor says so in the line below, so the loss is visible at the moment it happens rather than after a save.
Pasted content added as 1 heading and 5 paragraphs. Formatting was dropped and a table was flattened into 5 paragraphs. Check the wording before you save.
The server refuses an answer that is not built from these blocks

This answer was sent with a block kind this question does not allow. Nothing was saved and nothing you had written was lost. Reload the question and build the answer from the block buttons.

Block kind sent: "html". Allowed block kinds: heading, paragraph, bulleted list. Server refusal 422 RICH_STRUCTURE_INVALID.

A user cannot reach the red state through the editor above, because the editor only ever produces the three allowed blocks. It is reachable when a stale browser tab holds an older version of the question, or when something writes to the interface directly. The check that matters therefore runs on the server, not in the browser.

One story, drawn in one place, because the earlier draft told two. Paste is an EDITOR behavior: converted, never refused, with the loss reported. Refusal is a SERVER behavior on a payload outside the grammar, and it carries the spec's own constant, RICH_STRUCTURE_INVALID (spec ii 3.9 and 6.6), which is also what a typed block smuggling markup gets: an unknown block type, refused, not escaped and stored.
State 3 · the omission tab, selected
Enter an answer Report an omission instead
Not applicable to this organization
Not applicable to this organization
Reporting it is prohibited by law
Held back under a confidentiality restriction
The information is not available or is incomplete
Bluefin Processing TH does not set its own energy management approach. The site follows the group approach reported at Bluefin Foods Group level, and the group answer covers this question for this site.

Say what is missing and why, in your own words. This text is read by whoever reviews the report.

Format YYYY-MM-DD. Leave empty if you cannot give a date.

Saving this omission clears the answer on this question. A question holds an answer or an omission, never both. Nothing is cleared until you press Save omission.
CancelSave omission
Switching away from blocks that are already saved raises the SAME confirmation drawn on page 5 of this wireframe set, naming what is saved, who saved it, and Keep against Continue; that confirmation is one pattern for every answer type, drawn once. Saving an omission clears every block in the same atomic write; no structuredValue survives (spec ii 3.9). Whether this reason is ACCEPTABLE for this question is not checked in I1 (spec ii 3.10), and the screen makes no claim that it is.
State 4 · nothing written yet
Enter an answer Report an omission instead

No blocks yet

Build the answer from blocks. Start with a paragraph, or add a heading first if the answer has more than one part.

Add blockHeadingParagraphBulleted list
The empty block editor names the three block kinds too, so the limit is met before the first keystroke rather than after a paste is stripped.
State 5 · the answer as it reads back after saving
Who owns energy at this site
Energy use at Bluefin Processing TH is owned by the site technical team and reviewed each quarter by the plant management committee, working from monthly meter readings.
  • Monthly meter reading, reconciled against the utility invoice
  • Quarterly review with the plant management committee
  • Annual efficiency plan agreed with group technical services in Singapore
Recorded byDaniel OngSite Manager, Bluefin Processing TH
OmissionNone on this question
The read-back is the same block list rendered without the editing frames, word for word: heading, paragraph, and bulleted list above are byte-identical to the three blocks in the editor at the top of this page. Nothing is added, reworded, or summarized between edit and display. Every piece of text is escaped at render time (spec ii 3.9), so nothing a user typed can act as markup here, in a report preview, or in an export. This is the state a reviewer reads, which is why the block set has to stay small enough to render predictably everywhere.