Explainer, not proposed UI
GRI standards are versioned. Each standard carries a publication date, and standards get superseded; part of the emissions standard is already scheduled to be replaced by the new climate standard. A GRI report must remain reproducible under the rules it was written against, even after GRI updates those rules. That is the first thing an auditor asks: can you reproduce the number you published?
NxStart today cannot answer that question. Data is keyed to plain year numbers, and the framework catalog is a single flat list that updates in place. Nothing records which edition of the standards, which reporting boundary, or which emission-factor set produced a report. This has been fine for the current frameworks because their catalogs never change. For GRI it breaks the first time GRI publishes an update: history would silently recalculate under the new rules.
A Reporting Cycle closes this gap. It is one durable record per reporting period that pins four things: the catalog edition, the reporting boundary, the emission-factor set, and the methodology conventions. While the cycle is open, data entry works as usual. When reporting is complete, the cycle locks: its numbers freeze and the published report stays reproducible on demand, permanently.
Nothing. The page and everything behind it is switched on per tenant. Existing customer accounts keep exactly the screens and workflows they were trained and UAT-cleared on, and an automated regression suite verifies that before every release.
Reporting Cycles are the audit backbone that makes GRI reports reproducible after the standards change, invisible to every customer who does not use GRI.