CRP Scenario Analysis

Versions

• v6 # Changelog ## 7.3.0 The fixed deep dive examines purchased goods and services, upstream and downstream transportation and distribution, and waste generated in operations, leaving out any the emissions report does not carry. ## 7.2.0 The scenario analysis document is kept in memory beside the scenario on every write, where the Carbon Reduction Plan reads it; `--document` writes it for a scenario already in memory, with no model call. "Generate carbon reduction plan report" accepts every sign-off automatically. The Scope 3 deep dive reads the emissions report's own categories: products and suppliers come from purchased goods and services alone, and waste generated in operations has its own table. Two more versions of the deep dive, focused and broad, take the largest Scope 3 categories until they cover 95% and 99% of Scope 3; the document shows all three, and memory keeps each as its own document. Each line is read by how the emissions report names it -- "Type: Activity (unit)" as type, activity and unit; "Item (counterparty)" as product and supplier, or goods moved and vehicle; anything else whole -- and the fixed categories and the counterparty labels are one setting each. `--document` brings a scenario already in memory up to date, rebuilding its deep dive from the figures. A share prints with one decimal place, or two or three when fewer would show it as zero, and below that as "<0.001%". A supplier or product whose name differs only in spacing is counted once. ## 7.1.0 When the user chose automatic sign-off at the start of the run, the scenario checkpoint and each delivery pathway are accepted without a card, the pathway questions take their defaults, and each acceptance is named in one line. The tracking task is still proposed on its own card and does not hold up the run. The closing message says the Carbon Reduction Plan is being prepared now. ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/29/2026
• v5 # Changelog ## 7.2.0 The scenario analysis document is kept in memory beside the scenario on every write, where the Carbon Reduction Plan reads it; `--document` writes it for a scenario already in memory, with no model call. "Generate carbon reduction plan report" accepts every sign-off automatically. The Scope 3 deep dive reads the emissions report's own categories: products and suppliers come from purchased goods and services alone, and waste generated in operations has its own table. Two more versions of the deep dive, focused and broad, take the largest Scope 3 categories until they cover 95% and 99% of Scope 3; the document shows all three, and memory keeps each as its own document. Each line is read by how the emissions report names it -- "Type: Activity (unit)" as type, activity and unit; "Item (counterparty)" as product and supplier, or goods moved and vehicle; anything else whole -- and the fixed categories and the counterparty labels are one setting each. `--document` brings a scenario already in memory up to date, rebuilding its deep dive from the figures. A share prints with one decimal place, or two or three when fewer would show it as zero, and below that as "<0.001%". A supplier or product whose name differs only in spacing is counted once. ## 7.1.0 When the user chose automatic sign-off at the start of the run, the scenario checkpoint and each delivery pathway are accepted without a card, the pathway questions take their defaults, and each acceptance is named in one line. The tracking task is still proposed on its own card and does not hold up the run. The closing message says the Carbon Reduction Plan is being prepared now. ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/29/2026
• v4 # Changelog ## 7.2.0 The scenario analysis document is kept in memory beside the scenario on every write, where the Carbon Reduction Plan reads it; `--document` writes it for a scenario already in memory, with no model call. "Generate carbon reduction plan report" accepts every sign-off automatically. The Scope 3 deep dive reads the emissions report's own categories: products and suppliers come from purchased goods and services alone, and waste generated in operations has its own table. Two more versions of the deep dive, focused and broad, take the largest Scope 3 categories until they cover 95% and 99% of Scope 3; the document shows all three, and memory keeps each as its own document. Each line is read by how the emissions report names it -- "Type: Activity (unit)" as type, activity and unit; "Item (counterparty)" as product and supplier, or goods moved and vehicle; anything else whole -- and the fixed categories and the counterparty labels are one setting each. `--document` brings a scenario already in memory up to date, rebuilding its deep dive from the figures. Shares print to three decimal places. A supplier or product whose name differs only in spacing is counted once. ## 7.1.0 When the user chose automatic sign-off at the start of the run, the scenario checkpoint and each delivery pathway are accepted without a card, the pathway questions take their defaults, and each acceptance is named in one line. The tracking task is still proposed on its own card and does not hold up the run. The closing message says the Carbon Reduction Plan is being prepared now. ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/29/2026
• v3 # Changelog ## 7.2.0 The scenario analysis document is kept in memory beside the scenario on every write, where the Carbon Reduction Plan reads it; `--document` writes it for a scenario already in memory, with no model call. "Generate carbon reduction plan report" accepts every sign-off automatically. ## 7.1.0 When the user chose automatic sign-off at the start of the run, the scenario checkpoint and each delivery pathway are accepted without a card, the pathway questions take their defaults, and each acceptance is named in one line. The tracking task is still proposed on its own card and does not hold up the run. The closing message says the Carbon Reduction Plan is being prepared now. ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/28/2026
• v2 # Changelog ## 7.1.0 When the user chose automatic sign-off at the start of the run, the scenario checkpoint and each delivery pathway are accepted without a card, the pathway questions take their defaults, and each acceptance is named in one line. The tracking task is still proposed on its own card and does not hold up the run. The closing message says the Carbon Reduction Plan is being prepared now. ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/28/2026
• v1 # Changelog ## 7.0.0 A projection more than 10% from what its own percentage implies takes the implied figure, and none is larger than the baseline of the line it applies to. No page marks a projection for checking, and the approval card no longer counts flagged projections. ## 6.0.0 The scenario is measured from the baseline. Each goalpost requires the whole committed reduction from the baseline, whatever the scope emits now; initiatives are proposed against the baseline's own sources, and a projection is checked against its percentage of the baseline line it applies to, and flagged when it exceeds that line's baseline. Pathway shortfalls are measured the same way. The checkpoint shows today's emissions beside each goalpost for reference. New scenarios record `"basis": "baseline"`; a working scenario without it is refused, and the checkpoint must be run again. Scenarios already signed off are left as they were agreed. ## 5.0.0 The scenario is kept in memory under `organization/me/carbon-reduction-scenarios/`, one file per tier, beside the organisation's identity and targets. ## 4.0.0 The scenario is kept in memory as one file per tier, `carbon-reduction-scenarios/<period>-sbti-least-ambitious.json` and `<period>-sbti-most-ambitious.json`. Both carry the same scenario and initiatives; each keeps only its own tier's delivery pathway. Nothing is written under `emissions/crp/`. ## 3.4.0 A proposal whose phase the model names with its year -- "Intermediate, 2030" -- now finds its goalpost instead of disappearing, and a pathway addition's scope is matched the same way; the prompts quote the exact names. A scope whose proposals could not be used, or a pathway whose reply held steps that could not be placed, now says so on the page rather than reading as if nothing was proposed. Once a tier is signed off, the agent adds its steps to the organisation's action plan as tasks for the team, one per step and tagged by commitment, and the pathways record each task so a later run never adds it twice. One yearly agent task can be set up to report progress against the pathways; the plan's id and the tracking decision are kept with the organisation's stored answers, so rebuilding the scenario never offers the tracking task again. The shared constraints keep action-plan tasks and the tracking task's notifications outside the savings-figure exceptions, and allow the page to state, in plain words, that a scope's proposals could not be used. ## 3.3.1 An agreed initiative whose sentence states a figure the scenario checkpoint sourced -- a breakdown line's tonnage at today's level, say -- no longer stops the pathways. A step naming it admits exactly the figures its sentence states that the checkpoint sourced. The agreed initiative's basis and rationale no longer source figures on the pathways page, which prints neither. Answers are checked as they arrive, with a draft or with a response to one: each needs a question, an answer given as a number is kept as its text, and each is marked assumed or not. Anything else is refused before the model is called or anything is written, so an answer stored from now on can no longer stop a later run. An answer an earlier version stored as a number still stops the run until it is written as text. ## 3.3.0 A fourth phase builds one delivery pathway per commitment tier once the initiatives are agreed: the agreed initiatives sequenced in time, paced by the maturity assessment's gaps, with any additions a tier needs to reach its targets. The agent asks the organisation at most three questions first, keeps the answers for later runs, and takes a sign-off for each tier on its own. Pathways are stored with the scenario, each tier marked draft or signed off. Each sign-off card carries the answers its pathway assumes and the legend for its marked projections. A tier whose drafting failed cannot be signed off until it is redrafted. Once pathways exist, changing an agreed initiative means running the scenario checkpoint again from the start. The shared constraints name the pathway sign-off as the second place a figure for what a measure saves may be stated. ## 3.2.1 The approval card points at the scenario analysis document by name rather than by its file name. Every CRP skill now carries the rule behind it: the user is told what their data shows, never the files, paths or fields it is kept in. ## 3.2.0 The approval card states the intermediate phase's required and projected totals side by side and no longer divides one by the other. Coverage is not fungible across scopes: a scope over-delivering against a requirement of nothing read as covering another scope's gap, so the card could say 155% covered above a scope with its whole requirement still to find. What each scope still has to find carries that judgement instead. ## 3.1.0 The Scope 3 deep dive reaches the model stated at today's level, the same as the Scope 1 and 2 breakdown, so a projection taking the stated share of a stated line is no longer flagged by the ratio between the base year and the current period. A measurement or governance step states no percentage and a tonnage of zero: it now projects nothing and prints `-`, rather than reading `0.0 (unchecked)` and being counted among the projections the approval card says need checking. `(unchecked)` marks a stated tonnage with no percentage to compare it against -- no `abatement` at all, or one whose `appliesTo` resolves to no line. A group's summary states how much of its total comes from projections the document flags, the card's clause names the intermediate phase it counts, and a scope standing at zero says so. Each note is a bullet carrying its row number, so the number that feedback names survives rendering. ## 3.0.0 `scenario.json` carries `scenario`, a flat list where one entry is one initiative with the goalpost it was made against, the line it acts on, the tonnage it projects, the basis for that figure and why the organisation can do it. The `analysis` array, `plannedReduction`, `remainingReduction` and `coveragePct` are gone, and so is the compounding behind them: the model states each projection and `analysis.project` marks it `(check)` when it sits more than 10% from what the entry's own percentage implies. One broker call per scope covers both phases, so the net-zero set builds on the intermediate one. Scope 1 and Scope 2 carry a category-and-line breakdown built from `crp-data.json`'s new `scope1Sources` and `scope2Sources` -- the ten largest lines of each category, stated at both the base year's and today's level, whether or not the commitment covers that scope. `appliesTo` resolves against any scope's own lines. Feedback names the row number the document printed, and an abatement edit re-projects the entry it changed from the percentage the reviewer gave. A projection larger than the scope emits today is flagged whether or not its `appliesTo` resolves, and the approval card's headline says how many of the intermediate phase's projections the document flags. ## 2.1.0 The scope-and-phase table states the base-year figure a scope's required reduction is measured against, in place of what is still to cut from today's reading; each cell's own initiative section already states what is left to cut, and states it beside the measures planned against it. Both Scope 3 deep-dive tables name the GHG Protocol category each line is booked under, taken from the source's own key -- a product met under two categories names both. ## 2.0.0 Replaced material-family ranking with the scope-and-phase table `crp-assemble-figures` now builds: one cell per scope per target phase, each on its own committed rate. `contributors.py` ranks only the ten largest Scope 3 products and suppliers by source name, for `appliesTo` to resolve against; `analysis.py` settles each cell's `plannedReduction`, `remainingReduction` and `coveragePct`; `propose.py` judges every cell with one broker call, proposing up to three initiatives that may state an estimated reduction, since a human reads it at the checkpoint before anything downstream uses it. There is no growth assumption and no projection: `scenario.json` carries `period`, `generatedAt`, `informedBy`, `scopes`, `targets`, `scope3`, `analysis` and `degraded`, nothing else. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the table and every initiative before it is agreed; re-run with their feedback, it applies the initiative, abatement and strike changes and exits 0, with no further broker call. Before either path writes, every figure the checkpoint document and the approval card state is checked against `crp-data.json`; one with no source stops the run and is named, and nothing is stripped or dropped. An `appliesTo` is matched with its whitespace collapsed, the form the prompt shows a source name in; one that resolves to no line carries no abatement claim in the document at all. A figure has two provenance roots: `crp-data.json`, and an approved suggestion's own stated abatement with the figures inside its basis text. The registry assessment is not a third -- the scenario keeps its maturity label, never a score -- so `validate_figures` no longer takes a `maturity` widening. ## 1.0.0 Added the skill: `contributors.py` groups named scope 3 sources by material family and emission category, keeps families and categories at or above a 1% materiality threshold, and orders them by tonnage, deterministically. A family spanning two emission categories splits into two rows rather than being summed into one. `propose.py` then judges each contributor with one broker call, adding how readily it can be moved and up to three suggestions. `scenario.py` writes the result to the organisation's memory and exits 2, the checkpoint where a human reviews the ranked contributors before any measure is selected; re-run with their feedback, it applies the strike/suggestion changes and exits 0. 9/22/2026