> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auth.energy/llms.txt
> Use this file to discover all available pages before exploring further.
# Consumer Consent - Issue Ledger
> Running log of identified problems, weaknesses, and unresolved gaps in RECCo's Consumer Consent Solution (CCS) programme, drawn from consultation documents, working group decks, and meeting transcripts. Updated as new material is reviewed. This is the single source of truth for open issues — the Organisation Position Tracker (separate document) tracks external stakeholder *positions*; this ledger tracks RECCo's own *design and process gaps*, regardless of who raised them.
First published: 17 July 2026 · Status: `LIVE`
AI generated, may contain errors.
**Legend — Category:** Process | Technical | Governance | Commercial | Communications
**Status:** Open | Watching | Resolved (superseded by later material) | Superseded
***
## Source Log
| # | Document | Date |
| --- | -------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| S1 | CCS Solution Group deck | 1 July 2026 (original pass) |
| S2 | CCS Solution Group meeting transcript | 17 June 2026 |
| S3 | RECCo Design Consultation main document + Annexes A–G | 11 Feb 2026 |
| S4 | CCS Solution Group deck | 1 July 2026 (re-read via proper text extraction, this session) |
| S5 | CCWG Topic Solution Group deck — Issue and Error Resolution | 29 Jan 2026 |
| S6 | CCS Solution Group (Topic-specific) deck — Spotlight on Governance | 12 Feb 2026 |
| S7 | CCS Solution Group (Topic-specific) deck — Spotlight on Technical Design | 26 Feb 2026 |
| S8 | CCS Solution Group deck — Spotlight on UX (incl. live Q\&A follow-up slides) | 12 Mar 2026 |
| S9 | CCS Solution Group deck — Design Consultation headline figures & emerging themes | 9 Apr 2026 |
| S10 | CCS Solution Group deck — Tariff Interoperability & CCS alignment | 22 Apr 2026 |
| S11 | CCS Solution Group deck — Wave 1 UX research findings & accessibility | 7 May 2026 |
| S12 | CCS Solution Group deck — Trust Framework Partner announcement | 21 May 2026 |
| S13 | CCS Solution Group deck — Consent Record Schema & Security Profile | 4 June 2026 |
***
## Issue Ledger
### ISSUE-01: "Hybrid Model B" funding conclusion presented with no visible options paper
* **Category:** Governance / Commercial
* **Source:** S1, Slide 14
* **Status:** Resolved (superseded by later material) — see S3 detail below
* **What happened:** Slide 14 states "Hybrid Model B to be adopted" and references "four options for ongoing funding" presented in the Feb 2026 Design Consultation — but the deck shown only the conclusion, never the options themselves.
* **Resolution:** S3 (the actual Feb consultation document) contains the full four-option comparison: Model 1 (RECCo Cost Recovery), Model 2 (User Pays), Model 3 (Hybrid A — transactional fee), Model 4 (Hybrid B — assurance-cost-only, selected). RECCo's rationale for rejecting Hybrid A is specific (avoids double-charging given SDR/DSI arrangements already funded via BSC Mod P494); rationale for Model B over pure RECCo Cost Recovery balances "commercial beneficiaries should bear some cost" against "phased rollout limits the user base who'd bear early transactional costs." This is genuinely reasoned, not just asserted.
* **Why it matters (historic):** Stakeholders were being asked to accept a funding decision without the comparison that justified it; this has since been made available in the source consultation pack itself.
### ISSUE-01b: Funding model review trigger is undefined — open-ended deferral
* **Category:** Governance / Commercial
* **Source:** S3, para 8.31
* **Status:** Open
* **What happened:** Para 8.31 explicitly asked respondents for views on "the initial time period or other pre-conditions before this position is re-considered" and whether a review requirement should be written into the REC or left flexible. As of the 1 July deck (S1/S4), no answer to this has been published — Model B is adopted with no stated sunset, review trigger, or re-opening mechanism. The 1 July deck (S4) repeats only that the approach will be "kept under review alongside other smart data initiatives" — still no date or trigger.
* **Why it matters:** No committed point exists at which non-paying beneficiaries (ATPs/EDPs benefiting from CCS without transactional cost exposure) will be revisited. "Initial time period" and "kept under review" both leave this open-ended in practice.
* **Open question for RECCo:** What is the actual trigger or date for revisiting the funding model, and will it be codified in the REC rather than left as RECCo's discretion?
* **Cross-reference:** Tracker notes ScottishPower, SEC Panel, and Auth Energy independently raised this same point in their Design Consultation responses.
### ISSUE-02: ISDP assessment costs are unjustified round numbers, used three times over
* **Category:** Commercial
* **Source:** S1/S4, Slide 11
* **Status:** Open
* **What happened:** Cost bands (\~£5k low / £8–10k medium / up to £15k high for new CCS Users; £1k–£10k for existing Enquiry Service Users extending to CCS; £5k–£15k for ongoing maintenance reassessment) are repeated across three different assessment scenarios with no stated methodology, comparator, or sensitivity basis — just "level of work is likely to vary by complexity."
* **Why it matters:** Real costs imposed on applicants before they can participate. Arbitrary-looking bands invite later disputes about what tier an applicant falls into.
* **Open question for RECCo:** What is the actual cost model behind these bands (e.g. day-rate × estimated hours by risk tier)?
### ISSUE-03: Risk classification criteria (low/medium/high) lack scoring or weighting
* **Category:** Governance
* **Source:** S1/S4, Slide 10
* **Status:** Open
* **What happened:** Six qualitative risk factors are listed (user type/purpose, downstream sharing, request volume, third-party reliance, security incident history, org maturity) with no indication of how they combine into a single risk tier.
* **Why it matters:** Without a scoring rubric, two assessors could plausibly place the same applicant in different tiers — and tier directly drives cost (ISSUE-02) and assurance burden.
* **Open question for RECCo:** Is there a scoring matrix behind this, and if so, why hasn't it been shared alongside the qualitative factors?
### ISSUE-04: REC/SEC duplication "addressed" with a still-in-progress plan, not a resolution
* **Category:** Governance
* **Source:** S1, Slides 8 & 12
* **Status:** Superseded — see ISSUE-17 for the fuller, sharper finding confirmed from source consultation text
* **What happened:** Slide 8 said duplication concerns "are addressed on the following slides." Slide 12's actual content was RECCo "working with SECCo to develop a complementary assurance framework" — i.e., a plan, not a completed resolution.
### ISSUE-05: Four slides in the deck contain no extractable content
* **Category:** Communications
* **Source:** S1, Slides 7, 13, 15, 22
* **Status:** Resolved — confirmed as a real (minor) defect, not a flaw in extraction
* **What happened:** Original text extraction returned nothing for slides 7, 13, 15, 22. Re-extraction this session (S4) confirms these are genuinely content-light: slide 7 is a section-break slide with only the standard footer/disclaimer text and no visible title; slides 13, 15, and 22 are the same. These function as visual section dividers (likely a title graphic with no alt-text/extractable layer) between agenda items (Governance → Access Agreement → Q\&A → Forward Plan), not missing or broken content.
* **Why it matters:** Low — cosmetic/structural only, no substantive content is missing.
### ISSUE-06: "CoCo" listed as Commercial Lead in formal team appendix
* **Category:** Communications
* **Source:** S1/S4, Slide 28
* **Status:** Watching
* **What happened:** All other team members are listed with full real names; "CoCo" reads as a nickname or unreplaced placeholder, repeated identically in the 1 July re-read.
* **Why it matters:** Minor, but undermines polish of a document meant to be circulated externally to industry.
### ISSUE-07: 12-hour outage policy set without consulting on the actual number
* **Category:** Process
* **Source:** S2, 14:41–14:44
* **Status:** Open
* **What happened:** Feb consultation (Q9) asked industry the abstract question — should EDPs keep sharing data during a CCS outage "unless it extends for a significant period" — with no number proposed at that stage. RECCo has since landed on **12 hours** internally (with ICO/legal sign-off) and presented it to the working group as a settled recommendation, without re-consulting on the specific figure. RECCo's own justification offered live: "the ICO didn't raise particular concerns" and "similar arrangements in other industries" — a sign-off, not a derivation.
* **Why it matters:** A meaningful operational commitment (how long the market loses new-consent capability) was decided one level more concretely than it was consulted on — industry never had the chance to push back on "12" specifically.
* **Open question for RECCo:** Will the 12-hour figure go out for explicit consultation, or is it being treated as already settled by virtue of having cleared the original abstract question?
### ISSUE-08: "No new consent during outage" is a centralisation consequence, framed as a neutral technical fact
* **Category:** Technical / Communications
* **Source:** S2, 14:44–14:48 (Camilla's question)
* **Status:** Open
* **What happened:** When pressed by Camilla, RECCo's answer reveals new-consent issuance halts during outage because token issuance is *only* centrally available — a direct consequence of the centralised token model, not an unavoidable technical limitation. Initially presented as simply "technically can't be created."
* **Why it matters:** The Feb consultation's hybrid-model table justified centralising token provision for audit/single-source-of-truth reasons — fair — but the corollary (market-wide new-consumer onboarding halts up to 12 hours per outage) is a real availability cost of that design choice and should be named as such.
* **Cross-reference:** ISSUE-07 (the cap itself); the Feb consultation's 99.9% availability target.
### ISSUE-09: PKI/certificate governance treated as still-open, but already foreclosed by the FAPI 2.0 + cert-bound-token decision
* **Category:** Technical / Governance
* **Source:** S2, 14:44–14:48 (Robin/George exchange); corroborated and pre-dated by S7 and S9
* **Status:** Open — escalated confidence, now with an earlier paper trail (see ISSUE-14)
* **What happened:** Robin points out that mandating certificate-bound access tokens (per FAPI 2.0, already committed to in the Feb consultation) effectively requires tokens tied to certificates issued through a PKI that RECCo controls or trusts — meaning "is PKI governance still open?" doesn't hold; the technical commitment has already constrained the answer. George's response: "low-level implications" still being worked out.
* **Why it matters:** Same structural pattern as ISSUE-01/07: present the architecture as settled, then treat its direct consequences as a separate open question. This pattern is now confirmed to run for at least four months before the 17 June exchange — see ISSUE-14 for the dated paper trail.
* **Open question for RECCo:** Will RECCo accept externally-issued (non-RECCo) certificates for cert-bound tokens, or is RECCo's own PKI the only viable trust anchor given the architecture already chosen?
### ISSUE-10: Same-legal-entity ATP/EDH scenario has no policy position, \~9 months from go-live
* **Category:** Governance
* **Source:** S2, 14:58–14:59 (Jeff's question)
* **Status:** Open
* **What happened:** Jeff asks whether the same legal entity can act as both Energy Data Holder and Authorised Third Party (a common real-world pattern — e.g. vertically integrated supplier with a consumer app). Sarah confirms this is still under discussion, including with legal advice "as recently as yesterday" (relative to 17 June).
* **Why it matters:** Not an edge case — a basic identity/role-model question the trust framework's role-based access structure (demoed in the same session) is already being built around. If the policy lands in a way requiring structural change to the role model, that's rework risk close to a March 2027 go-live.
* **Cross-reference:** ISSUE-11 (build-before-governance pattern).
### ISSUE-11: Working prototype demoed as near-final while underlying governance/policy questions remain open
* **Category:** Process
* **Source:** S2, throughout Raidiam demo (14:50 onward)
* **Status:** Open
* **What happened:** Multiple points in the Raidiam trust-framework demo surface undecided policy questions sitting underneath an already-built UI/flow: the "Omit from Ecosystem" field (governance undefined), external vs RECCo-only PKI (undecided — ISSUE-09), same-entity ATP/EDH roles (undecided — ISSUE-10), branding (undecided).
* **Why it matters:** Build-then-govern ordering risks the technical implementation calcifying answers to questions the working group is still meant to be deciding. The more functional the prototype looks, the harder it becomes politically to change the policy underneath it.
### ISSUE-12: 12-hour outage cap has an unaddressed tail scenario, mentioned once and dropped
* **Category:** Process
* **Source:** S2, 14:42
* **Status:** Open
* **What happened:** A speaker notes in passing that what happens *beyond* a sustained outage (longer than the BCDR-covered period) is still unresolved, then the meeting proceeds as though "Option 1, 12 hours" is the complete, finished recommendation.
* **Why it matters:** A recommendation with a known, unaddressed tail case shouldn't be presented as settled without flagging the gap explicitly in the recommendation itself.
### ISSUE-13: Live technical demo format excludes non-technical stakeholders from effective engagement
* **Category:** Communications
* **Source:** S2, 15:17 (Scorch Power request for recorded walkthrough)
* **Status:** Watching
* **What happened:** A supplier representative had to explicitly request a recorded video version of the demo because it was too technical to follow live, for sharing with less technical colleagues.
* **Why it matters:** Indicates the primary engagement channel (live working group demos) isn't reaching the full range of stakeholders RECCo says it wants input from.
### ISSUE-14: PKI architecture diagram confirms RECCo as the de facto certificate authority — corroborates ISSUE-09, with a dated paper trail now running to four months before the 17 June exchange
* **Category:** Technical / Governance
* **Source:** S3, Annex E, Figure 6 ("Full Proposed Solution Design"); same diagram and "CCS provides PKI services" label published earlier and independently in S7 (26 Feb, Slide 21, "Proposed Solution Design for CCS")
* **Status:** Open — escalated confidence, now dated
* **What happened:** RECCo's own published architecture diagram explicitly labels "CCS provides PKI services" on both the ATP-facing and EDP-facing interaction flows — stated directly on the official, consulted-on diagram, not an inference. This diagram (in materially the same form) was already presented to the working group on **26 Feb 2026**, nearly four months before Robin's 17 June question treating PKI governance as still open. Separately, industry's own Design Consultation responses (summarised in S9, 9 Apr) list "more clarity requested on PKI services, particularly extent to which certificates can be managed across frameworks" as one of the most common follow-up requests — meaning industry was already flagging the same unresolved question externally, in writing, five weeks before the same question was raised live in the 17 June working group.
* **Why it matters:** The question Robin raised live (17 June — "is PKI governance still open?") had effectively already been answered by RECCo's own published design on 26 Feb, and had already been raised by multiple Design Consultation respondents by 9 April. The "still looking at low-level implications" answer given in the 17 June meeting represents the third time this question surfaces without a definitive published answer — first in the architecture diagram itself (no FAQ/clarification attached), then in consultation responses (RECCo's own 9 Apr summary acknowledges the request for clarity but defers it to "this forum" with no date), then again live in June with the same "still looking" answer repeated.
### ISSUE-15: Dispute investigation SLA is a literal unfilled placeholder, including on the published business process diagram
* **Category:** Governance / Process
* **Source:** S3, para 8.73; Annex E, Figure 11 ("Queried Consent")
* **Status:** Open
* **What happened:** Para 8.73 states ATPs must respond to disputed-consent investigations "within (x) working days (value to be confirmed as part of REC drafting)." The official process diagram (Figure 11) likewise shows "\[X] days" as a literal placeholder at the relevant step.
* **Why it matters:** A core consumer-protection mechanism shipped to public consultation with no proposed value at all — not even a starting figure to react to. Compare ISSUE-07, where RECCo at least proposed a number; here there isn't even a draft figure.
* **Open question for RECCo:** What working-day figure is now being proposed, and will it go back out for explicit comment given it was blank in the original consultation?
### ISSUE-16: Right-to-restriction dispute mechanism can be used to weaponise disputes against valid consents
* **Category:** Governance
* **Source:** S3, paras 8.71–8.75
* **Status:** Open
* **What happened:** Where a consumer disputes a consent they don't recognise (e.g. multi-occupancy household), the CCS automatically terminates the consent and suspends data sharing immediately, before any investigation (para 8.72, Figure 11). RECCo's own para 8.75 acknowledges the concern — "a consumer could cease access to data where consent has been granted by another individual validly linked to the MPxN" — and defends it solely via Article 18 UK GDPR (right to restriction of processing pending validity checks).
* **Why it matters:** Asymmetric dispute mechanism: a single disputing party can unilaterally and immediately suspend a *valid* counterparty's data access, with the validly-consented party only finding out after the fact (notification to the ATP comes after termination per Figure 11). In a multi-occupant household with friction between occupants (separating couples, HMO conflicts), this is a vector for one occupant to disrupt a legitimate service the other is using, with no prior verification step. RECCo's GDPR justification addresses the *legal* basis but not the *operational* harm of zero-notice suspension.
* **Open question for RECCo:** Is any pre-suspension verification step (even lightweight) being considered, given the risk RECCo itself names in 8.75?
### ISSUE-17: REC data protection assessment required for all CCS Users regardless of existing SEC assessment — explicit duplication accepted, not just "being worked through"
* **Category:** Governance
* **Source:** S3, paras 8.50–8.53 (sharpens ISSUE-04)
* **Status:** Open — sharpened from "Watching" to a firmer finding
* **What happened:** More conclusive than the 1 July deck (S1) suggested. Para 8.53 states plainly: RECCo considered relying on SEC privacy assessments for SEC Other Users wishing to become CCS Users, and **explicitly decided against it** — "we do not believe the scope of the SEC privacy assessments would sufficiently address the risks we are seeking to mitigate." All CCS Users will undergo a full REC data protection assessment "regardless of whether they have already been subject to assessment under another industry code." Duplication is avoided only on the information-security side, via CE+ reliance (para 8.51) — confirmed again in S4 (slide 12: "by setting CE+ as a minimum-security requirement, RECCo will rely on this third-party assessment and focus the ISDP on areas not covered by CE+").
* **Why it matters:** ISSUE-04 originally read this as "duplication concerns being worked through with SECCo" (a plan in progress). The fuller text shows RECCo has already concluded duplication is *not* avoidable for the data protection assessment specifically — only for information security. Organisations already SEC-privacy-assessed will face a second full assessment under the REC. This is a settled position, not an open question, and should be communicated as such to affected SEC Other Users rather than left implied as "ongoing minimisation work."
* **Update (S4, 1 July deck):** RECCo's own messaging continues to frame this softly — slide 8 states "concerns... are addressed on the following slides" and slide 12 states RECCo "is working with SECCo to develop a complementary assurance framework that recognises existing SEC assurance, avoiding duplication while maintaining appropriate oversight." This framing still reads as more reassuring than the underlying settled position (data-protection-assessment duplication is *not* avoided, only info-security duplication is). The gap between messaging tone and substantive content persists across two successive sessions (S1 and S4 are the same deck, re-confirmed).
### ISSUE-18: Non-functional requirement table ships with almost every target value as "to be defined"
* **Category:** Technical / Process
* **Source:** S3, Annex D, NFR table
* **Status:** Open
* **What happened:** Annex D's NFR table (Responsivity, Demand & Capacity, Data Retention, Accuracy, Attrition, Retry Strategy, Query Resolution SLAs, RTO/RPO) lists metrics for each row but, except for Availability (99.9%, stated in the main body), every other row's value is described only as "to be defined" — with no proposed figures put to industry for comment.
* **Why it matters:** Same pattern as ISSUE-15 — consulting on a framework with the substantive numbers missing across the board. Respondents can comment on the *categories* of NFR but not on whether the actual thresholds are reasonable, because none are proposed.
### ISSUE-19: Behavioural archetype names and framing differ between the main consultation document and Annex F
* **Category:** Communications / Process
* **Source:** S3 main consultation doc and S8 (12 Mar, Slide 12) both confirm "Comfortable Data Enthusiast," "Careful Budgeteer," "Surviving Juggler," "Time-Poor Professionals" as the actual names; vs. S3 Annex F's "Digitally Confident Maximisers," "Cost-Conscious & Financially Constrained Consumers," "High-Need, High-Load Households," "Time-Poor, Digitally Capable Families"
* **Status:** Resolved — confirmed as a genuine naming discrepancy, not a memory error
* **What happened:** S8 (the 12 March UX-spotlight deck) independently and directly confirms the four names "Comfortable data enthusiast," "Careful budgeteer," "Surviving juggler," "Time-poor professionals" as RECCo's working terminology, used again unchanged in S11 (7 May Wave 1 research deck: "Comfortable Data Enthusiast," "Careful Budgeteer," "Surviving Juggler," "Time-Poor Professionals"). This was not a memory artifact or misremembering — it is the term set RECCo consistently uses in working group materials across at least three months (Mar–May), distinct from whatever naming variant appears in Annex F. The original question of *why* the two documents diverge remains open, but the existence of the discrepancy itself is now confirmed from primary sources rather than treated as "Watching."
* **Why it matters:** Two parallel naming conventions for the same four user groups, used in different document types (consultation annex vs. working-group/research decks) risks confusion for anyone cross-referencing the consultation response against the live design work — a respondent answering Q16 against Annex F's archetype table may not recognise the same groups when they reappear under different names in subsequent working group sessions.
### ISSUE-19b: Archetype research methodology and target population shifted between the consultation framing and Wave 1 research
* **Category:** Process / Technical
* **Source:** S11 (7 May), Slide 8
* **Status:** Watching
* **What happened:** S11 states the Wave 1 research "deliberately selected archetypes as edge cases rather than the mainstream majority" — i.e., the four archetypes used in the actual qualitative research (16 interviews) are explicitly the most complex/highest-friction users, on the logic that "if CCS works for those with the most complex needs... it will work for everyone." This is a reasonable research design choice, but it means the archetype *descriptions* now coming out of Wave 1 (e.g., "Careful Budgeteer" associated with "cautious by experience... vigilant but fatigued") may not be statistically representative of the named archetype's prevalence or typical behaviour — they're worst-case exemplars dressed in the same archetype names used elsewhere for general population planning.
* **Why it matters:** If CEGs or UX decisions are calibrated against the Wave 1 research findings under the assumption the four named archetypes represent typical members of each group, but the research was deliberately sampling edge cases within each group, there's a risk of over-designing for friction that the average member of that archetype wouldn't experience — or under-designing for the full distribution within it. Worth clarifying whether this distinction is preserved as design work progresses into Wave 2/3.
### ISSUE-20: IDV accessibility conflict with the GPG45 high-confidence photo-ID minimum — now backed by primary consumer research, not just an annex example
* **Category:** Governance / Technical
* **Source:** S3, Annex F (accessibility examples table); independently confirmed and substantially strengthened by S8 (12 Mar, Slide 14 — verbatim source of the original example) and S11 (7 May, Wave 1 research findings, Slides 20, 25, 37)
* **Status:** Open — escalated from "annex example" to "confirmed primary research finding," and now RECCo's most clearly evidenced unresolved design conflict
* **What happened:** Annex F's accessibility design-response table gives a worked example: "A consumer with a visual disability cannot complete the IDV process by taking a photograph of their passport," with the proposed design response being alternatives to "telephone-based verification / IVR." S8 confirms this is RECCo's own original worked example (not a summary or restatement), repeated verbatim. But the main consultation document (para 5.13) sets GPG45 high-confidence, photo-ID-based verification as the minimum standard for MMP, with only one IDV provider available at launch (para 5.14).
S11's Wave 1 research (16 in-depth interviews, conducted after the consultation closed) goes well beyond the annex's single hypothetical example: **"Photo ID is the biggest barrier and most likely drop-off point"** is now a headline finding (Slide 20), with a directly-quoted participant describing camera-based ID verification **failing entirely on a basic tablet** — "not due to user error but hardware limitations" (Slide 25). RECCo's own COM-B behavioural analysis (Slide 37) independently identifies "Photo ID as the main friction point" as one of only three most-critical, cross-archetype adoption barriers, alongside fear of data resale and lack of trust signals.
* **Why it matters:** This is no longer a single hypothetical accessibility example buried in an annex — it is now a confirmed, primary-research-backed finding that the mandatory minimum verification method for MMP fails for a meaningful subset of users for reasons of hardware capability, not user behaviour, and is independently flagged by RECCo's own UX/research team as the single biggest adoption barrier across all four behavioural archetypes (not just users with disclosed disabilities). The proposed mitigation (phone/IVR alternatives) does not address the device-failure mode the research surfaced, and there is still no stated alternative photo-ID-equivalent verification route at MMP launch with only one IDV provider committed for day one.
* **Cross-reference:** Tracker notes this exact IDV standard is the single most contested point across nine separate Design Consultation respondents (Centrica, ScottishPower, East Lothian Housing Association, Ohme, Octopus, RLBA, EDF, Luxon Group, CGI IT UK). RECCo's own 9 Apr consultation-response summary (S9, Slide 10) independently confirms IDV sentiment is contested ("Unsupportive ↔ Supportive" spread shown), with next steps listed as "in active conversations with potential IDV providers," "completing consumer research on the proposed IDV standards" (now delivered via S11, and the findings make the case for change stronger, not weaker), and "prioritising looking at federated IDV models for inclusion within the MMP." RECCo has scheduled a dedicated working group session specifically on this (16 July 2026 per S13's Forward Plan: "IDV Photo — define service driven IDV/Federated capabilities"), confirming this is being treated as the priority item to resolve — but as of the most recent material reviewed, no resolution has been published, and MMP go-live (end Q1 2027 per S12) is now under a year away.
### ISSUE-21: Coercive-control / domestic-abuse data-visibility risk raised by a stakeholder, acknowledged but with no design response
* **Category:** Governance / Process
* **Source:** S8 (12 Mar), Slide 30, Q1
* **Status:** Open
* **What happened:** A stakeholder directly asked how RECCo will "make sure that the bill payer will not use the household data to keep track of family members, and potentially lead to scenarios of control and abuse." RECCo's live answer (Matt White) acknowledges this is "a good thing for us to take away and consider," notes there's nothing equivalent in the energy sector currently, and effectively defers the question to industry-wide future consideration.
* **Why it matters:** This is a safeguarding-adjacent risk raised directly to RECCo, in writing, in a working group — not a hypothetical. The CCS's own multi-occupancy design (any occupant who proves occupancy can see that someone else behind the same MPxN has data access — confirmed separately in S8 Slide 30, Q2) is the exact mechanism that could enable this risk: visibility of "someone else has consented" could itself be used by a controlling household member to monitor a partner's activity, independent of the underlying energy data. No design mitigation has been proposed in any deck reviewed to date.
* **Open question for RECCo:** Has this been picked up by the safeguarding/vulnerability workstream, and is there a published design response yet (e.g., granularity limits on what one occupant can see about another's consent activity)?
### ISSUE-22: Non-digital and digitally-excluded consumer journeys explicitly out of scope for MMP, with no committed timeline
* **Category:** Governance / Process
* **Source:** S8 (12 Mar), Slide 30–31, Q6–Q7
* **Status:** Open
* **What happened:** In response to direct stakeholder pushback ("No consideration of digital excluded," "Journeys of digitally excluded people have been left out for the end... the solution would be too rigid to change anything to accommodate this group"), RECCo confirms non-digital journeys are "post-MMP," with research ongoing now to "prepare" for that later phase, but no committed date or scope for when non-digital/assisted journeys will actually be delivered.
* **Why it matters:** Ofgem's own direction (cited by RECCo itself in the same answer) is for CCS to be "as inclusive as possible for society as a whole" — but the MMP, the first live version of the system, is being built digital-first with non-digital accommodation deferred indefinitely. The stakeholder's structural concern — that a digital-only MMP could harden into a shape too rigid to retrofit non-digital journeys onto later — has not been directly rebutted, only reassured against in general terms ("we will certainly be looking... to be inclusive by design").
* **Cross-reference:** Connects to ISSUE-11 (build-before-governance pattern) — the same dynamic (technical commitments calcifying before policy/inclusion questions are resolved) applies to accessibility/inclusion scope, not just technical architecture.
### ISSUE-23: UK GDPR Article 7 end-to-end compliance for the consent lifecycle still unconfirmed as of March, with no public update since
* **Category:** Governance / Technical
* **Source:** S8 (12 Mar), Slide 28, Q5
* **Status:** Watching
* **What happened:** A stakeholder asked directly whether the Consent Lifecycle provides an end-to-end Art. 7 UK GDPR-compliant solution, or whether ATPs/EDPs are expected to fill a gap themselves. RECCo's answer: still in technology procurement and "assessing GDPR compliance... will update the working group in due time," with only a stated confidence ("we are confident our end-to-end solution will address Art. 7") rather than a substantiated answer.
* **Why it matters:** Article 7 (conditions for consent, including the ability to withdraw consent as easily as it was given) is one of the more legally consequential UK GDPR provisions for this entire programme. An unconfirmed compliance position on this, from March, with no public update found in any later deck reviewed (through 4 June), is a longer-than-ideal silence on a foundational legal question — especially set against the multiple instances elsewhere in this ledger (ISSUE-15, 16, 18) where legal/compliance specifics are deferred to "REC drafting" without an interim answer.
* **Open question for RECCo:** Has this Art. 7 compliance assessment now concluded, and if so, when will it be shared with the working group as promised?
### ISSUE-24: RECCo floats becoming a de facto cross-industry identity-verification register, with no governance framing for this secondary use
* **Category:** Governance / Technical
* **Source:** S13 (4 June), Slide 21 ("Sharing consumer information")
* **Status:** Watching — new, raised as an open question by RECCo itself, not yet a confirmed design decision
* **What happened:** RECCo raises, as an open question to the working group, whether "CCS providing verified consumer details back to ATPs to align records" would "benefit industry" — i.e., proposing that CCS's identity-verification function could be repurposed to feed verified consumer identity data back to ATPs for their own record-keeping, beyond the core consent-brokering purpose CCS was designed for.
* **Why it matters:** This is a meaningfully different data flow from anything else described in this programme to date — using CCS-verified identity data for ATP-side record alignment, not just consent management. No purpose-limitation, consumer-awareness, or additional-consent framing is discussed alongside the proposal; it's framed purely as an industry-benefit question. If pursued, this would need its own GDPR purpose-compatibility analysis (Art. 5(1)(b), purpose limitation) and a clear answer on whether consumers consented to *this* specific secondary use when they originally verified their identity for a single ATP's service.
* **Open question for RECCo:** Is this proposal being taken forward, and if so, what governance/consent framework would apply to it specifically, separate from the core CCS consent model?
### ISSUE-25: Mandatory introspection's tension with the FAPI 2.0 standard is now an explicit, named trade-off RECCo must resolve, not a hypothetical
* **Category:** Technical / Governance
* **Source:** S9 (9 Apr), Slide 11
* **Status:** Open — sharpens the existing zero-trust/introspection debate already reflected in the tracker (ScottishPower, Perse, ESG Global, Octopus vs. Citizens Advice, Novoville, East Lothian Housing Association)
* **What happened:** RECCo's own 9 April summary of consultation feedback explicitly states that working with the tech partner on "options for configuration of introspection depending on data sharing type... will need to assess the benefit of this in the context of breaking from the FAPI 2.0 standard." This is RECCo naming, in its own words, that accommodating bilateral/non-introspection arrangements (which EDF, ScottishPower, and others requested) may require deviating from the FAPI 2.0 standard it has otherwise committed to as foundational.
* **Why it matters:** This is a genuine, acknowledged architectural trade-off — not a settled-architecture-dressed-as-open-question pattern (cf. ISSUE-09/14), but an honestly-flagged tension between standardisation and flexibility. Worth tracking distinctly because the resolution either way has consequences: holding the line on FAPI 2.0 disappoints the bilateral-arrangement respondents (EDF among them, who separately call for halting development); relaxing it for certain data-sharing types creates exactly the kind of "settled architecture, foreclosed later" risk this ledger already tracks elsewhere.
* **Cross-reference:** Tracker notes ScottishPower, Perse, ESG Global, and Octopus raised cost/latency/proportionality objections to introspection; EDF separately disagrees with FAPI 2.0/mTLS as proposed.
### ISSUE-26: Tariff Interoperability Phase 1b (consumer-specific tariff data via CCS) has no implementation date and is dependent on CCS's own unresolved occupier/bill-payer position
* **Category:** Process / Governance
* **Source:** S10 (22 Apr), Slides 7, 8, 10
* **What happened:** A parallel workstream (Tariff Interoperability, also delivered by RECCo) originally planned its own bespoke OAuth-based consent mechanism, but this was scrapped after RECCo/DESNZ/Ofgem recognised the duplication/migration risk against the incoming CCS. The revised plan defers "Registered TI User" (consumer-specific tariff data) access to a "Phase 1b," explicitly folded into the CCS roadmap — but Phase 1b's implementation date is listed only as **"TBC"** (slide 9), even though Phase 1a (public tariff data) has a firm date of Feb 2027. RECCo's own slide 10 "Next Steps" further notes that Phase 1b's customer journey design "is dependent on current CCS activities considering legal and ICO positions regarding granting of consent" — i.e., dependent on the still-unresolved occupier-vs-bill-payer question (see tracker; ICO/legal advice on this was still "as recently as yesterday" per the 17 June transcript, S2).
* **Why it matters:** This is a second, independently-evidenced example of a downstream commitment (Phase 1b go-live) being structurally dependent on an upstream policy question (occupier vs. bill payer) that has been open since at least February and remained open as of 17 June. Unlike ISSUE-09/14 (PKI), this dependency is stated explicitly by RECCo itself rather than needing to be inferred — a rare case of RECCo naming a blocking dependency clearly. Worth tracking whether Phase 1b gets a firm date once (if) the occupier/bill-payer question resolves.
### ISSUE-27: Customer Experience Guidelines (CEGs) flagged by multiple consultation respondents as a likely barrier to ATP adoption — concern repeated by the working group itself, not addressed in any deck since April
* **Category:** Process / Governance
* **Source:** S8 (12 Mar, Slides 30-33, raised three times by attendees: "CEGs could be a significant barrier to adoption by ATPs and a significant cost to monitor"); S9 (9 Apr, Slide 12, listed as a "Change Control" concern: "CEGs being overly prescriptive, limiting innovation and not aligned to outcome-based governance")
* **Status:** Watching
* **What happened:** The same concern (CEGs as a prescriptive, costly barrier to ATP adoption) was raised independently at least four times across two sessions — three times by different attendees in the 12 March live Q\&A, then again as a named theme in RECCo's own 9 April consultation-response summary. RECCo's only stated next step (S9, Slide 12) is "provide clarification in relation to existing governance arrangements to address consultation queries" — a clarification commitment, not a substantive design response to the "overly prescriptive" critique itself.
* **Why it matters:** A concern repeated this many times, across both live working-group attendees and the formal consultation, without a substantive design response (only a promise to "clarify"), is worth flagging as potentially under-addressed relative to how often it's been raised. No later deck (through 4 June) returns to this theme with a resolution.
***
## Cross-Cutting Pattern Watch
Patterns appearing across multiple issues — worth tracking as a meta-theme rather than one-off complaints:
1. **"Settled architecture, open governance" sequencing** (ISSUE-01b, 07, 09, 10, 11, 14, 22): RECCo repeatedly presents high-level technical/architectural commitments as locked in, then treats the direct policy consequences of those commitments as still up for discussion — when in practice the earlier commitment has already narrowed or foreclosed the later answer. Corroborated by primary source: the official architecture diagram (Annex E, Figure 6; also S7, 26 Feb) already labels RECCo as the PKI provider, even while the 17 June working group treated this as open — a gap now confirmed to run at least four months, with industry itself flagging the same gap in writing by 9 April (ISSUE-14). The same dynamic now also applies to inclusion/accessibility scope (ISSUE-22): a digital-first MMP risks calcifying before non-digital journeys are designed in.
2. **Numbers appearing without visible derivation, or not appearing at all** (ISSUE-02, 07, 15, 18): cost bands, the 12-hour outage figure, the dispute-investigation SLA, and nearly the entire NFR table all either lack a derivation or are literal unfilled placeholders — even in a published consultation document inviting comment. A confirmed, recurring drafting pattern, not an isolated gap. The NFR table (ISSUE-18) is now confirmed to have shipped in this state as early as 26 Feb (S7, Slide 23) — i.e., it wasn't tightened between the technical-design spotlight session and the formal consultation a fortnight later.
3. **Consultation scope narrower than the eventual commitment** (ISSUE-01b, 07): industry consults on the abstract principle or framework, RECCo decides the concrete number/model afterward without circling back, and there is no committed re-opening trigger for funding once Model B's "initial period" ends.
4. **Asymmetric/one-sided consumer protection mechanisms** (ISSUE-16): the dispute-resolution design protects the *disputing* party automatically and immediately, while the *disputed-against* party bears the cost of an unannounced suspension before any investigation — a tension RECCo names itself but resolves by citing legal basis rather than mitigating the operational harm. ISSUE-21 (coercive control / data visibility) is an adjacent, distinct risk in the same multi-occupancy design surface, also acknowledged live but with no design response yet.
5. **Settled-sounding duplication avoidance that is actually a settled non-avoidance** (ISSUE-17): language suggesting "ongoing work to minimise duplication" conceals a section where RECCo has explicitly already concluded duplication will *not* be avoided for the data protection assessment specifically. This pattern repeats unchanged in the 1 July deck (S4) — the public-facing message hasn't tightened to match the more settled internal position five months on.
6. **Concerns raised live by working-group attendees, acknowledged, and then not visibly returned to** (ISSUE-21, 22, 23, 27): a recurring shape across the monthly decks is a stakeholder raising a substantive concern in open Q\&A (coercive control, digital exclusion, GDPR Art. 7 compliance, CEG prescriptiveness), RECCo giving a considered but non-committal live answer ("we'll take this away," "we are confident," "will update in due time"), and no later deck in the set reviewed returning to give the promised substantive update. This is distinct from pattern 1 — it's not that the architecture forecloses the answer, but that the question seems to genuinely drop out of the visible record after the live acknowledgment.
7. **Genuine, honestly-named trade-offs** (ISSUE-25): not every tension follows the patterns above. RECCo's own 9 April summary explicitly names that accommodating bilateral/non-introspection data-sharing arrangements would mean "breaking from the FAPI 2.0 standard" — a trade-off stated candidly rather than glossed over. Worth distinguishing from pattern 1: this is closer to "open architecture, open governance," and how RECCo resolves it (hold the line on FAPI 2.0, or carve out exceptions) is genuinely still undecided rather than already foreclosed.
8. **Downstream commitments dependent on still-unresolved upstream policy questions, named explicitly by RECCo** (ISSUE-26): Tariff Interoperability Phase 1b's design is stated by RECCo itself to depend on the still-open occupier/bill-payer question. A useful counter-example to pattern 6 — here RECCo is transparent about the dependency, it's just that the blocking question (occupier vs. bill payer) has now been open since at least February.
***
## Resolved Project-Memory Cross-References
* **Raidiam/PayPoint appointment** — previously flagged in project memory as "unverified against primary sources" (trade-press claim only). Now confirmed directly from RECCo's own primary source: S12 (21 May deck), Slide 4, states plainly "Raidiam and PayPoint have been appointed as Trust Framework partners for the CCS." Contract signed May 2026; discovery workshops May–June 2026; build & integration H2 2026; conformance/UAT/security review Q1 2027; go-live end Q1 2027. This item can be considered closed.
***
*Next update: append new issues here as further documents/transcripts are reviewed. Cross-reference new entries against the pattern list above where applicable.*