Role-aware regulatory intelligence is the difference between telling a company what changed and telling the right person inside that company why it matters to their work.
Policy Compass, our regulatory intelligence platform for UK energy, already knew the business: licence position, market participation, customer segments, operating model and strategic context. Now it knows the role as well. Radar and Research no longer stop at “this matters to the company”. They ask the sharper question: who does this matter to, and why?
That is not a prompt trick. It is part of the Regulatory Harness around the model: the Authority Set first, Business Context second, then Role Context - the layer this update adds - before the answer. That changes the product.
TL;DR
- What changed: Policy Compass now ships role-aware regulatory intelligence: a role profile on top of the business profile, so each user gets intelligence tuned to their actual responsibilities.
- Why it matters: the same Ofgem consultation, BSC change or Grid Code modification can land differently for a codes lead, a retail regulation lead, a flexibility analyst and a commercial stakeholder.
- Why a prompt is not enough: a general-purpose assistant can help with bounded research, but role-aware intelligence depends on a specialist UK energy Regulatory Harness that keeps source, business and role context attached.
- How Radar and Research use it: Radar rates and explains relevance per user, not just per company; Research treats the role as the primary voice of the answer, with the business profile as supporting context.
- What it is not: it is not a verdict engine. It is prioritisation, source-grounded research and context - the judgement stays with the team.
What does role-aware regulatory intelligence add?
The role layer adds person-level context to Policy Compass. A business profile tells the product what the organisation is. A role profile tells it what the user actually does.
Role Context is the personal context Policy Compass applies on top of a business profile - who the user is and what they are actually accountable for. It is the layer that tunes regulatory intelligence to the individual user, not just the organisation.
Role Context is one layer of the same Regulatory Harness we wrote about in Policy Compass vs ChatGPT for UK energy research. The model matters, but the Harness decides where to look, what source material to trust, which business context to apply, and which person inside the team needs the answer.
That sounds like a small addition.
It is not.
A company-level relevance view solves only the first half of the problem. It can tell you whether a development touches the organisation, but it still treats everyone inside as if they need the same priority order, the same explanation and the same timing. They do not. The same source signal can be a nine-out-of-ten for the person covering codes and a three-out-of-ten for a colleague focused on retail operations. The company matters; the role decides whether it should interrupt your day.
Why company-level context is not enough
Company-level context answers the first-order question: does this development touch the organisation?
Role-level context answers the operational question: who needs to care first?
That distinction matters because official source surfaces are organised around documents, processes and bodies. They are not organised around your internal operating model.
Ofgem’s consultations page (opens in new tab) shows publication type, publication date, status and topic. DESNZ’s consultation hub (opens in new tab) shows open consultations and closing dates. Elexon’s BSC Change Process Guidance Note (opens in new tab) explains different change routes, including Modifications and Change Proposals, and notes that a Modification will typically take six to eight months to progress to a final decision before implementation time is added. REC’s June 2024 change-process update (opens in new tab) said over 55 new requests were raised in 2023/24 and that the volume of change had been higher than estimated. NESO’s Grid Code modifications page (opens in new tab) points users to a tracker with current code modifications, including purpose and affected stakeholders.
Those are good source surfaces. They are not the same as role-aware intelligence.
They tell you what is open, current, decided, delayed or moving through a process. They do not know whether the person reading is accountable for settlement, retail policy, flexibility markets, networks or client delivery.
Policy Compass now has that extra layer.
How Radar changes when it knows your role
Radar still does the same underlying job: it watches across UK energy’s regulators and industry codes and runs commentary on every signal we monitor.
The role layer changes what happens next.
Instead of one relevance view for the whole company, Radar can rate the same item differently for each user. A development that sits squarely inside one person’s market coverage rises. A development that is only loosely adjacent to another person’s responsibilities drops. The explanation changes as well, because the “why it matters” line is no longer written for a generic company profile. It is written for the person.
| Signal type | Company-only interpretation | Role-aware interpretation |
|---|---|---|
| Ofgem consultation | Relevant to the supplier profile | High priority for the retail regulation lead; lower for the codes specialist |
| BSC modification | Relevant to market participation | High priority for settlement or MHHS ownership; lower for commercial comms |
| Grid Code modification | Relevant to energy-sector monitoring | High priority for networks or flexibility roles; lower for retail-only roles |
| REC change update | Relevant to retail market operations | High priority for customer operations or switching ownership; lower for generation-facing roles |
| DESNZ call for evidence | Relevant to policy horizon scanning | Priority depends on the user’s market coverage and response responsibility |
Illustrative product-routing examples, not regulatory advice.
This is the part generic alerts cannot do. A keyword can match the document. It cannot decide whether the document is yours.
How Research changes when it knows your role
Research changes too. Before the role layer, the business profile did most of the work. It still does. The product needs to know the organisation before it can give a useful answer.
But the role profile now becomes the primary voice of the answer. If you are responsible for regulatory affairs, the answer should read differently from the same question asked by someone on commercial strategy, client delivery or market operations. Not because the source material changes. Because the job to be done changes.
That matters most in grey areas. The same paragraph can raise different next questions depending on the user’s remit:
- Regulatory affairs: what does this change mean for our formal response position?
- Commercial strategy: what could this change do to product design, pricing or market entry?
- Client delivery: which clients need a briefing, and how should it be framed?
- Operations: what process, data or system impact should be checked first?
Policy Compass does not pretend those are the same question.
That is why what design partners told us about per-role relevance changed the product. The company profile was necessary. It was not sufficient.
Why role-aware intelligence is a force multiplier
Role-aware intelligence is a force multiplier for regulatory people, not a substitute for them. Regulatory professionals are not short of judgement; their interpretation, experience and market sense are the valuable part. The expensive part is the volume: watching the authoritative sources, separating signal from noise, and then doing the deeper source work once something relevant appears.
A general-purpose assistant can help once you know what to ask. Policy Compass is built for the step before that: finding the relevant signal, routing it to the right role, and giving that person the source trail they need to apply their own judgement faster.
That is why Role Context belongs in the Regulatory Harness. Without it, even a strong answer can land in the wrong place. With it, Radar becomes a routing layer and Research becomes a deep assistant for the person who actually owns the question.
What does a role profile contain?
A role profile captures enough context to make the product useful without turning onboarding into a procurement form.
The core fields are deliberately practical:
- role title;
- markets covered;
- topics tracked;
- work types;
- responsibilities in the user’s own words;
- notification sensitivity.
The split matters. We build the business profile when we provision the account. Each user then adds their own role, because only they know the work they are actually accountable for.
From there, Policy Compass has two lenses:
- Business context: what kind of organisation is this, and where does the development touch it?
- Role context: what does this person do, and should this signal interrupt them?
That is the full phrase we keep coming back to: it knows your business and your role.
What this means for different teams
For energy suppliers, role-aware intelligence reduces the internal firehose. A regulatory team can still share one business profile, but the person on retail does not need the same priority order as the person tracking code change.
For energy consultancies, the role layer sits on top of the work pattern consultants already have: different people own different client questions, markets and response types. The more client portfolios a team carries, the more expensive a one-size feed becomes.
For flexibility providers, role context matters because the same organisation can sit across supply, aggregation, markets and operations. A source signal can touch the business but still belong first to one person.
For network operators and adjacent teams, the difference is planning horizon. Some roles need source changes for immediate response. Others need them because they alter a programme, a price-control conversation or a future workstream.
Same company.
Different job.
Sources
- Ofgem consultations (opens in new tab) - consulted 6 July 2026.
- DESNZ consultation hub (opens in new tab) - consulted 6 July 2026.
- Elexon BSC Change Process Guidance Note (opens in new tab) - consulted 6 July 2026.
- REC change-process update (opens in new tab) - published 24 June 2024, consulted 6 July 2026.
- NESO Grid Code modifications (opens in new tab) - consulted 6 July 2026.
The bottom line
Knowing the company is the first step. Knowing the role is what makes the intelligence usable at the desk where the work happens.
Policy Compass now has both: Radar watches the market in the background, Research answers against the right source base, and each person gets the version of the signal that fits their work.
That is what changes when regulatory intelligence stops being company-aware and starts being role-aware. Request a trial and put Radar to work on your own role - a free, team-wide trial with full access.