1 The commercial decision
Approve a utility information product only after identifying its inputs, permitted uses, customer deliverable and payment conditions. The proposed product could support infrastructure planning, maintenance decisions, efficiency analysis or a customer's own consumption management. Each purpose needs an explicit data perimeter. A business case should name the datasets that must remain available and the permissions required throughout the delivery period.
Start with a product specification that an investment committee can inspect. Describe the decision the customer intends to make, the information supplied, the update frequency and the limitations. Attach a sample deliverable and its acceptance test. A proposed maintenance ranking should state whether it identifies inspection priorities or authorises operational action. The distinction changes the engineering review, contract and cost of support.
The central commercial question is whether the provider can lawfully and reliably perform the promise for which the customer will pay. Resolve that question at the level of each material input and each intended use. Record the contract, permission or applicable rule supporting the proposed use, its scope and its expiry. Refer unresolved legal questions to qualified advisers in the relevant jurisdiction.
This paper proposes a structured assessment for network operators, technology providers and investors. It does not establish that a utility can sell any particular dataset or that a customer exists for the proposed product. The financial cases are illustrative. Their purpose is to help the decision maker identify conditions that would change an actual investment decision.
2 Source scope and current regulatory context
The European Commission explains that the Data Act has applied since 12 September 2025. Its connected-product provisions concern readily available raw and preprocessed data and relevant metadata. The explanation distinguishes inferred or derived information outside that chapter's scope. It also identifies user agreements, personal-data requirements and safeguards relevant to sharing.[1] The proposed diligence should determine which provision, role and dataset apply to an actual arrangement; this paper offers no transaction-specific legal conclusion.
Ofgem's linked Data Best Practice Guidance addresses covered energy licensees and energy system digitalisation. Its presumed-open approach includes triage of sensitivity and associated sharing decisions.[2] The May 2026 consultation on securing open data in energy is displayed as closed and awaiting a decision at the date of review. It discusses possible changes to triage arrangements.[3] The consultation proposals are treated as proposals throughout this paper.
The UK Information Commissioner's Office explains anonymisation through the risk of identification, including combination with other information. Its anonymisation resources carry a notice that guidance is under review following legislative change.[4] NIST's final operational technology guidance addresses the particular performance, reliability and safety considerations of those systems.[5] Neither source validates the security or privacy of the hypothetical commercial products considered here.
The Commission's Data Governance Act explanation describes requirements for regulated data intermediation, including separation and neutrality in relevant services.[6] The US Department of Energy Green Button material describes consumer access and authorised transfer of energy-use information.[7] These sources provide distinct institutional examples. No current adoption count, universal water-network obligation or transferable permission to sell data is asserted.
3 Define the information product
Prepare a short specification for each proposed product. State whether the customer receives raw readings, cleaned records, aggregates, forecasts, recommendations or access to a query service. Define the geographical boundary, temporal resolution, identifiers and permitted combinations. A product labelled network intelligence still needs this detail before its rights and delivery obligations can be evaluated.
Specify the intended customer purpose with equal care. A regional planning report, a household consumption application and a fault-location service expose different information and support different decisions. List permitted recipients and any onward-distribution limits. Identify whether the customer may retain the output, publish excerpts, use it to train a model or combine it with other records.
Set an acceptance test that the customer can reproduce. It might concern completeness, delivery frequency, supported asset identifiers and the handling of missing records. Performance promises should follow actual testing of the intended application. Where performance evidence is unavailable, restrict the initial proposal to a controlled evaluation with agreed limits, reporting and responsibilities.
The product specification should also describe what happens when an input becomes unavailable. State whether the output is suspended, narrowed or replaced with a separately accepted service. Identify which customers would receive notice and how invoices would change. The commercial proposal needs an affordable delivery commitment under the conditions that the rights register can substantiate.
4 Build the rights register
Create a register connecting every material dataset to its origin, custodian, permission evidence and proposed use. Assign a responsible reviewer and a review date. Record source contracts and their relevant provisions in a secure diligence file. A summary field should identify the practical limitation, with the underlying document available for examination by the authorised team.
Use a separate entry for each processing step that changes the proposed commercial use. Collection for network operation, sharing with a contractor, analytical processing and onward customer supply should each be addressed. Include retention, international processing and model training where intended. A broad description of a technology partnership cannot answer all of those questions without its actual terms.
Record conditional permissions as conditional. Identify the approval still required, who can provide it and the expenditure exposed before that approval. Set a funding hold point where the missing permission is essential to the proposed product. Permit an alternative product only after its revised inputs, customer promise and economics have been reviewed.
Table 1. Proposed register for utility information rights
| Information object | Proposed use | Evidence to inspect |
|---|---|---|
| Network sensor readings | Service analytics | Source agreement and use perimeter |
| Customer interval records | Customer application | Authority, purpose and privacy assessment |
| Asset location and topology | Planning output | Security triage and permitted granularity |
| Contractor inspection records | Maintenance ranking | Contractor terms and onward-use permission |
| Derived forecast | Customer decision support | Input rights and output licence |
| Model and training records | Continued model operation | Training permission and retention terms |
| Customer report | Defined customer purpose | Recipient, reuse and termination terms |
Table 1 is a proposed diligence tool. It supplies no conclusion about the rights in a specific record. Complete it using actual contracts, applicable rules and documented decisions. Keep sensitive documents within the approved review environment; the register should support controlled diligence without reproducing restricted operational information in sales material.
5 Use an evidence based readiness sequence
Advance the product through stages tied to observable evidence. Begin with the inventory and purpose definition. Then complete permission review, a controlled delivery test, customer acceptance and collection. The proposed sequence allows investment approval to be linked to completed conditions. It is a commercial readiness framework, with no validated technology score or probability attached to a stage.
Qualitative author framework. Stage positions indicate sequence only; they are not validated readiness scores, adoption measurements or success probabilities.
Define the evidence required to leave each stage. Permission review requires an approved scope and documented unresolved conditions. A controlled test requires authorised inputs, a repeatable output and a record of exceptions. Acceptance requires the customer's agreed test and decision. Collection requires a bank receipt reconciled to an accepted invoice, subject to the actual payment arrangements.
Keep technical and commercial readiness visible separately. A model can pass a test while the provider still lacks permission to supply its output to the intended customer. A fully authorised dataset can require further engineering before it supports the promised service. Review each deficiency against the product specification and limit commitments until the relevant condition has been satisfied.
Reassess the stage when an input, customer purpose, model version or permission changes. Retain the prior acceptance record and describe the changed condition. Expansion into a new country or customer application should have its own review. The proposed process is intended to make expenditure conditional on evidence; its effectiveness has not been empirically tested.
6 Review grid data at the intended resolution
Assess electricity-network information at the resolution proposed for release. The register should distinguish broad capacity summaries, asset locations, detailed topology and time-specific operating records. Identify the user decision supported by each field. Information that adds little to that decision should be reconsidered if it materially increases review, security or support requirements.
Propose a product-specific triage with the operator's authorised security and operational personnel. Document the reason for the chosen access level, aggregation and delay. Record how a customer can request a more detailed output and who can approve it. The proposal must remain subject to the operator's actual duties, licence conditions, contracts and applicable law.
Keep a reproducible record of transformations. If a planning product uses aggregation, describe the aggregation method and the limitations it introduces. A customer should know whether the output supports regional screening or equipment-level assessment. Validate any claim about the product's fitness for a specific planning task before including it in an enforceable service promise.
Plan for changes in network configuration and input availability. Establish a version date, update procedure and customer notification rule. A dataset can become unsuitable for a particular decision as operating conditions change. Price the actual maintenance of the information service, including review and correction, using verified delivery requirements and supplier quotations where available.
7 Review water data as a separate application
Water-network information needs its own contractual and regulatory assessment. This paper proposes applying the rights register to meter readings, pressure records, asset information, inspections and derived forecasts. It makes no claim that the energy rules discussed earlier establish an equivalent right to release water-network data. Identify the actual operator, concession or service arrangements before designing a commercial product.
Define the intended use of a water output. A pressure-analysis report, a consumption service and a planning dataset can have different inputs and recipients. Document whether the product is intended for internal operational review or external customer use. Include any restriction on publication, retention, linkage and onward disclosure that arises from the actual records and agreements.
Involve authorised engineering and security reviewers in evaluating location detail and time resolution. The proposed product should explain how missing measurements and changed network boundaries affect its output. A commercial forecast must account for the costs of maintaining those transformations and investigating customer queries. Their actual costs need evidence from the delivery design or a controlled pilot.
Avoid transferring conclusions from an electricity example to a water concession without review. Determine which approvals are needed and whether public procurement or other obligations affect the arrangement. Where those matters remain unresolved, keep the investment decision conditional. The initial commercial test should use an authorised dataset and a narrowly defined customer purpose.
8 Evaluate identification and linked information
Ask the privacy reviewer to assess the proposed output alongside the information available to its recipients. The diligence file should describe identifiers, time resolution, location detail and likely permitted combinations. Obtain a documented assessment appropriate to the applicable rules. Technical removal of a name or account number does not supply a transaction-specific privacy conclusion.
Define how the product will handle additions to its input fields. A later customer request for finer resolution or additional attributes should trigger a review of the changed purpose and disclosure. Record the approved version and the recipient conditions. The commercial team should sell the reviewed product specification and escalate proposed changes before making a commitment.
Include the privacy-related work in the delivery budget. Candidate tasks include assessment, transformation, controlled testing, incident response and periodic review. Their scope should follow the actual product and risk assessment. The illustrative costs later in this paper are fictional totals; they do not establish the cost or sufficiency of any particular anonymisation method.
Specify who can suspend delivery when a material concern is identified, how the concern is investigated and what the customer receives during suspension. Make those terms consistent with the revenue and continuity model. Legal review is necessary for any proposed contractual allocation of responsibility; a commercial model cannot establish compliance by assuming an inexpensive review process.
9 Preserve the operational boundary
Design the initial analytical service around a defined interface and authorised access. Document what the service can read, where processing occurs and whether it can issue commands. The engineering team should assess the actual architecture against operational needs. A proposed external planning product should have no implied authority to control a network merely because its provider receives information from it.
Describe installation, access management, credentials, monitoring and support responsibilities in the delivery contract. Define the change procedure and the handling of access withdrawal. Estimate the resources required to operate the approved interface. Obtain actual technical evidence before promising availability, update speed or recovery performance to customers or lenders.
Review the effects of commercial expansion on that architecture. An additional customer or model-training task may change data transfer, storage and support requirements. The proposed change needs operational and rights review before the sales forecast includes its receipts. Keep the accepted configuration and the commercial perimeter aligned through documented revisions.
Include a safe suspension and exit design. The parties should specify the conditions for disabling access, retaining required records and returning or deleting data under the applicable terms. Test the agreed procedures within an authorised environment. Report the observed result of a test separately from any broader security or resilience claim that has not been established.
10 Separate model training from customer supply
Address model training as an explicit intended use. Record which inputs will enter training, where they will be processed and which parties may operate the resulting model. Review retention and deletion obligations alongside the intended model lifecycle. A licence to provide a customer report should be inspected for its actual terms before being relied upon for a wider development programme.
Define the rights in proposed outputs through the relevant contracts and applicable law. A forecast, ranking or transformed dataset may involve several inputs, third-party software and customer information. Record restrictions inherited from those inputs and the proposed customer licence. Obtain legal review where ownership, reuse or attribution remains uncertain.
Maintain a version record linking each deployed model to the approved inputs and use scope. If a permission changes, identify the affected models and services. Assess the operational work required to replace inputs or retrain, and the periods during which customer delivery could be constrained. Budget that work using actual engineering estimates when preparing a live investment case.
Review whether a proposed broader licence is needed for the commercial plan. Identify its incremental scope, conditions and price through negotiation. Exclude assumed future uses from the base case until their supporting permissions and customer arrangements are evidenced. A proposed licence option can be described in diligence, with its conditions and uncertain economics retained.
11 Choose the commercial role
Select the role the business intends to perform. It may publish permitted information, deliver analytical services, operate a customer-authorised application or facilitate an exchange between other parties. Specify the inputs it receives, the outputs it supplies and the activities for which it charges. Ask legal advisers to assess the actual role against applicable requirements.
For a proposed intermediary, separate the facilitation activity from any independent analytics proposition in the business plan. Identify whether its permissions and organisational arrangements support both activities. The regulated model described by the Commission requires attention to separation and neutrality.[6] The proposal in this paper must be tested against the particular legal classification and contracts.
Identify the party responsible for ongoing customer service. A licensing arrangement still needs a mechanism for delivery problems, corrections, changed permissions and termination. Set the escalation route and the relevant cost allocation. A product sold through an intermediary should state which party owes the underlying performance obligation and which party administers access.
Model each role using its own revenues and costs. Facilitating fees, report subscriptions and project-specific advisory work should have separate assumptions and evidence. Avoid combining all prospective activities into one recurring revenue line before the associated rights and customer contracts exist. An investor needs to inspect the actual perimeter of the business being financed.
12 Examine customer authorised applications
A customer-authorised consumption application provides a useful distinct product design. Define the initiating customer, permission method, data provider and receiving application. Specify the information requested, the service purpose and the duration of the authorisation. The Green Button programme offers a reference for authorised energy-use information exchange.[7] This paper does not establish access at any particular utility or location.
Design the application around the permission it actually receives. Document renewal, expiry and withdrawal, together with the steps that stop future data transfer. The provider should understand what retained records and derived outputs it may continue to use under the actual terms. Legal and technical review are needed to reconcile those rules with the application architecture.
Test the customer experience with an authorised and limited pilot. Record completion, supported formats, missing fields and the delivery problems observed during the test. These results can inform actual support estimates. Keep them separate from claims about adoption, retention or market demand unless the evidence directly establishes those measures.
Build the revenue model from the application's actual commercial arrangement. Identify whether the customer, utility or another contracting party pays, and the conditions for payment. Consider service suspension and authorisation loss in the cash case. Do not assume that access to an exchange standard provides a paying customer or a transferable recurring revenue stream.
13 Compare product economics on a common basis
Use a consistent period and cost perimeter when comparing candidate products. Include source access, transformation, review, delivery infrastructure and customer support where applicable. Specify which costs recur and which are incurred initially. A comparison should identify the accepted customer deliverable so that apparently lower costs are not achieved by assuming a materially smaller obligation without disclosure.
The fictional comparison in Table 2 assumes three independent annual product cases. Open-information analytics has twenty paying customers at USD 3,000 each. Restricted planning has thirty customers at USD 4,000 each. An authorised application has thirty customers at USD 5,000 each. These assumed prices and customer counts have no market-validation evidence and should not be used as sales targets or pricing advice.
Table 2. Fictional annual product economics in USD
| Item | Open information analytics | Restricted planning | Authorised application |
|---|---|---|---|
| Assumed paying customers | 20 | 30 | 30 |
| Assumed annual fee per customer | 3,000 | 4,000 | 5,000 |
| Assumed annual receipts | 60,000 | 120,000 | 150,000 |
| Assumed annual delivery costs | 45,000 | 75,000 | 90,000 |
| Cash before initial cost and tax | 15,000 | 45,000 | 60,000 |
The comparison includes no verified output quality, customer benefit or measured accuracy. Treat it as a cost and cash template for evaluating an accepted specification. Obtain supplier quotations and customer evidence for an actual case, then replace every assumed entry. The recurring cash figures omit initial investment, taxes and other exclusions discussed in the valuation section.
Fictional author prices, customer counts and delivery costs. No observed market benchmark, performance measurement or commercial demand is represented. Initial expenditure and tax are excluded.
Evaluate cost performance through the obligations the customer has accepted. Record the delivery standard alongside costs rather than treating the margin as a technical quality score. If one product requires more frequent updates or tighter security controls, identify those requirements in the comparison. A controlled pilot should establish whether the proposed resources can meet them.
14 Price a specified service
Prepare the proposed price from the service specification and the negotiated commercial terms. State the update frequency, customer support, recipient scope and permitted use. Identify optional changes separately. Obtain customer acceptance of the actual deliverable before treating the price as evidence of willingness to pay. A draft tariff remains a proposal.
Choose a charging unit that can be administered using the agreed evidence. A subscription might cover a defined user group and period; a project fee might cover a specified report and acceptance event. The parties should define how additional recipients, changed data resolution and expanded use are priced. Test the administration cost as part of the delivery design.
Include changes in input availability in the pricing discussion. Define the customer remedy when a material dataset is unavailable and the provider cannot deliver the accepted specification. A narrowed replacement service should have an acceptance and pricing mechanism. Model the actual revenue effect of those terms using contract-specific assumptions.
Keep an evidence record for negotiated prices, discounts and delivery variations. Distinguish signed contracts from exploratory conversations and draft offers. Review whether receipts have been collected and whether credits or disputes change the economic result. A commercial forecast should identify the stage of each proposed sale and avoid presenting a hypothetical pipeline as contracted cash.
15 Write the customer contract around continuity
Attach the reviewed product specification, acceptance method and licence perimeter to the customer agreement. Define the permitted purpose, recipients, retention and onward use. Identify the data dependencies whose failure affects delivery. The contract should describe the service actually offered and the remedies that the provider can support with its resources and input arrangements.
Specify updates, corrections and customer notifications. Define how a customer can report a suspected error and how that report is investigated. Identify any decision for which the customer must obtain independent engineering or professional review. Obtain appropriate legal review of liability terms and their consistency with the service's demonstrated capabilities.
Address suspension and termination directly. State the circumstances, notice, payment treatment and record-handling obligations. Review the interaction with upstream permissions and supplier terms. Where an upstream right can end before the customer service term, explain the replacement plan and model the cash implications of failing to deliver it.
Keep customer commitments within the accepted rights and operating perimeter. A sales concession allowing wider reuse may require additional upstream permission and support work. Establish a review route for that change before signature. The business case should incorporate its negotiated costs, delivery requirements and potential effects on other customer agreements.
16 Allocate upstream permissions and costs
Review every upstream agreement required to deliver the product. Identify access duration, permitted processing, sublicensing, pricing, support and termination provisions. Record any approval needed for assignment, a change of control or a new recipient. A live investment decision requires the actual wording and legal assessment of provisions on which delivery depends.
Identify who bears costs when the input specification changes. Candidate costs include reformatting, retesting, migration and customer communication. Seek a workable change mechanism and assess whether its price can be funded from the proposed cash case. Include a constraint where a supplier has no obligation to support the requested change.
Budget permission-related work as a recurring obligation where the actual arrangement requires it. An initial review may need renewal or revision as products and recipients change. Assign a responsible owner, a timetable and an expenditure allowance supported by evidence. The fictional annual costs used here demonstrate the model structure without establishing a sufficient allowance.
Define the evidence retained for supplier performance and permission renewal. Keep approvals, version dates and accepted changes connected to the customer agreements they support. Assess the operational burden before expanding the product range. Financing diligence should examine whether the proposed organisation can administer those dependencies throughout the forecast period.
17 Value cash over the evidenced rights period
Estimate project value over the period that the rights and delivery assumptions support. The fictional illustration assumes USD 100,000 of initial expenditure at inception. It then assumes four annual, year-end cash flows of USD 60,000. An author-assumed twelve percent annual discount rate produces a project net present value of USD 82,240.96, rounded to USD 82,241 for presentation.
The base annual cash equals USD 150,000 of receipts less USD 90,000 of delivery costs, using the authorised-application case in Table 2. Assume all receipts are collected in the stated year and that the costs are paid in that year. The model has no working-capital balance, debt, tax, financing fee, inflation or residual value. These exclusions limit its usefulness for an actual transaction.
The illustrative rights and service period lasts four years. No renewal proceeds or terminal value are included. The discount rate is an assumption for sensitivity analysis, with no claim that it represents a market-required return. Obtain actual risk, contract, tax and capital information before preparing a transaction valuation or recommending a financing structure.
The break-even constant annual cash for this initial commitment is approximately USD 32,923.44 under the same four-year discount convention. It is calculated by dividing USD 100,000 by the sum of four annual discount factors. This threshold assumes the same cash timing and exclusions. It provides a mathematical comparison within the illustration, not a minimum market price for utility information.
18 Stress permission timing and withdrawal
The delayed case assumes the essential permission is unavailable throughout year one. The project receives no year-one revenue and incurs USD 30,000 of holding costs. It receives base cash of USD 60,000 in each of years two, three and four. Initial expenditure remains USD 100,000, and the rights period is assumed to expire at the end of year four without extension.
Under these fictional assumptions, the delayed case has net present value of USD 1,883.82. This result depends on the reduced holding cost and the assumed resumption of base cash. Additional capital, replacement inputs, customer compensation and tax are excluded. An actual permission delay requires a revised delivery plan, expense evidence and a review of the remaining customer obligations.
The withdrawal case assumes base cash in years one and two, no further service receipts, a USD 15,000 exit payment in year three and zero year-four cash. No termination compensation or residual value is assumed. Its net present value is negative USD 9,273.64. The scenario supplies no estimate of withdrawal probability or legal termination entitlement.
Table 3. Fictional four year rights and valuation cases in USD
| Item | Base | One year delay | Withdrawal after year two |
|---|---|---|---|
| Initial expenditure | 100,000 | 100,000 | 100,000 |
| Year one cash | 60,000 | -30,000 | 60,000 |
| Year two cash | 60,000 | 60,000 | 60,000 |
| Year three cash | 60,000 | 60,000 | -15,000 |
| Year four cash | 60,000 | 60,000 | 0 |
| Annual discount assumption | 12% | 12% | 12% |
| Net present value rounded | 82,241 | 1,884 | -9,274 |
Use the cases to ask which contract provision or operational dependency changes the outcome. Obtain evidence for the actual restoration period, remaining rights duration, customer remedies and exit cost. Model those conditions directly. A general risk premium can obscure the cash consequences of a specific permission event and should not replace inspection of the underlying obligations.
19 Finance the permitted service perimeter
Identify the project expenditure that the sponsor proposes to finance and the receipts available to repay it. Separate development, permission work and continuing delivery expenditure. Determine which commitments are recoverable if the product cannot launch. The funding plan should state who bears the loss under each failed condition and what approval is needed before further expenditure.
Consider the evidence available to a lender or equity investor. Provide executed material agreements, permission records, acceptance tests and collected receipts where they exist. State any unresolved renewal, assignment or customer condition. The illustration contains no debt-service model, financing offer or lender acceptance; its project value calculation alone establishes none of these.
Review proposed security and control arrangements with qualified advisers. Identify the enforceability and practical transferability of customer agreements, software, permissions and other assets in the actual jurisdiction. A data licence may have conditions affecting a replacement operator. The investor needs the transaction-specific assessment and an operational plan for continuing the accepted service.
Stage funding where essential evidence remains unavailable. A controlled development tranche can have a defined cost limit and exit decision, subject to the sponsor's approved resources. Later funding should depend on the agreed evidence and updated cash model. This is a proposed decision structure; no claim is made about market availability, lender practice or successful financing outcomes.
20 Review acquisition and change of control
In an acquisition, examine the permissions and delivery obligations alongside customer revenue. Identify consent, assignment and change-of-control conditions in the actual agreements. Review which products depend on the acquired entity's particular role or approvals. A diligence summary should explain what the buyer can continue after completion and which conditions still need satisfaction.
Reconcile the revenue schedule to the reviewed product and rights register. Record contract term, renewal, acceptance, refunds and restrictions on recipient expansion. Ask whether the forecast includes uses that require permission the seller has not obtained. Separate evidenced receipts from proposed future products, then prepare sensitivities for the identified conditions.
Prepare a practical transition plan for data processing and service delivery. Specify the people, systems and supplier arrangements needed during integration. Identify changes requiring renewed assessment or customer notice. Estimate transition costs from the actual plan and document unresolved resource requirements. Include those costs and delivery interruptions in the transaction model where appropriate.
Use contract-specific conditions in the purchase agreement, subject to legal advice. Candidate matters include consent before completion, verification of a material licence and a defined transition obligation. This paper offers no claim about the adequacy or enforceability of a particular remedy. Actual deal terms must follow the diligence evidence, risk appetite and applicable legal framework.
Four year cash cases, USD 100,000 initial expenditure, twelve percent discount, zero terminal value and the stated exclusions. Roadmap stages are author proposals; no transaction valuation or measured commercial result is represented.
21 Organise governance and decision records
Assign a named organisational role to maintain the rights register and coordinate product changes. Define which reviewers approve legal scope, privacy, operational access and customer commitments. Keep the approval record linked to the accepted specification. The governance proposal needs to reflect the actual company's authority structure and available resources.
Maintain a change log for datasets, transformations, models, customers and recipient conditions. Record the reason, review, effective date and affected agreements. A new model version or licence term should be assessed for its impact on existing services. The record should support a reproducible explanation of the product delivered during a particular billing period.
Design reporting around evidence useful for decisions. Candidate measures include accepted deliveries, exceptions, permission expiry dates, invoiced amounts, collected amounts and support expenditure. Define each measure and its source. Keep customer-benefit or performance measures separate until an appropriate method and observed evidence support them.
Set an escalation rule for material uncertainty. The responsible person should identify the affected promise, expenditure and decision date. Document whether delivery or funding is paused, narrowed or continued with an approved condition. Record the basis and required follow-up. These procedures are author proposals whose effectiveness would require observation in a real operating setting.
22 Test commercial demand without overstating it
Conduct a bounded commercial test around the specified customer decision. Show the permitted sample product, limitations and proposed support. Record the prospective customer's requested changes and the status of the discussion. A meeting, an expression of interest and a signed agreement represent different evidence and should remain distinct in the commercial record.
Seek an agreed evaluation or purchase only within the reviewed rights perimeter. Define the deliverable, permitted use, fee and acceptance condition. Record actual delivery work and any customer dispute. Assess the costs of serving that agreement before using it as a basis for wider commercial expansion.
Measure collected cash separately from proposed contract value. Reconcile accepted invoices, credits and bank receipts. Explain any collection delay and the associated delivery cost. A product can have technical acceptance and an unpaid invoice; the financing case needs the actual payment position and a sensitivity for the outstanding amount.
Revise the product when the commercial test identifies a different customer need. Reassess rights, delivery, acceptance and costs before pursuing it. Keep the original test evidence with its scope and dates. No commercial demand, customer conversion, advisory mandate or fee revenue is claimed for the hypothetical products presented in this paper.
23 Apply an investment approval checklist
Require a complete product specification, rights register and delivery plan before approving the principal investment commitment. Identify each material dependency and its evidence. State remaining conditions and the expenditure proposed before their resolution. The committee should be able to reproduce the cash calculation and understand the consequences of failing a condition.
Review the base case against actual customer terms and supplier obligations. Confirm the cash period, receipt timing, delivery costs, initial expenditure and exclusions. Include sensitivities for permission delay, withdrawal, data replacement and customer remedies. Use a transaction-specific assessment of tax and capital structure where an actual investment is being considered.
Set explicit limits for a controlled pilot where the evidence supports only that stage. Define authorised inputs, participants, outputs, duration, spending and the decision at completion. Identify who can accept the result and whether further permission is necessary for launch. A pilot should create evidence relevant to the next decision within its approved scope.
Document the approval and subsequent changes. Record the accepted conditions, responsible people and reporting obligations. Revisit the decision if the customer purpose, information perimeter or essential permission changes. The framework makes these dependencies visible; its use does not establish legal compliance, commercial success or a particular investment return.
24 Conclusions and further research
A utility information investment should be assessed through the service it can permissibly deliver, the evidence supporting that promise and its actual costs and receipts. The proposed rights register connects raw records, processing, model use and customer supply. The contract design then makes continuity, changed inputs and exit conditions available for financial review.
The hypothetical cases demonstrate the effect of stated cash assumptions. The base project has positive net present value, while permission delay leaves little value under the specified costs and fixed rights period. Early withdrawal produces a loss in the stated case. None of these results estimates actual prices, legal risk probabilities, customer demand or the value of a particular utility business.
Empirical work could test the cost of maintaining reviewed permissions and the resources required for accepted delivery across product types. Such a study would need authorised records, a clear methodology and observed customer and expenditure evidence. It should distinguish electricity and water settings and retain jurisdiction, contract and resolution differences in its findings.
Further transaction research could examine how assignment conditions, renewal rights and customer remedies affect actual acquisitions or financing terms. Those questions require reviewed documents and permission to use the evidence. Until that work exists, the proposed framework serves as a structured diligence and decision tool with explicitly stated limits.
References
- European Commission. Data Act explained. https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained Accessed 4 October 2026. Commission explanation of scope, roles and conditions; no transaction-specific legal assessment.
- Ofgem. Data Best Practice Guidance. PDF cover dated 8 October 2024, linked from the guidance page dated 17 November 2025. https://www.ofgem.gov.uk/sites/default/files/2025-11/Data_Best_Practice_Guidance_CLEAN%26ACC.pdf Accessed 4 October 2026. Covered energy licensees, presumed-open sharing and triage context.
- Ofgem. Securing open data in energy: triage in data best practice guidance. Consultation published 29 May 2026; page displays Closed awaiting decision at review. https://www.ofgem.gov.uk/consultation/securing-open-data-energy-triage-data-best-practice-guidance Accessed 4 October 2026. Consultation proposals distinguished from adopted requirements.
- Information Commissioner's Office. Introduction to anonymisation and current anonymisation guidance notice. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/introduction-to-anonymisation/ Accessed 4 October 2026. Main guidance page https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/ notes review following the Data Use and Access Act.
- National Institute of Standards and Technology. SP 800-82 Revision 3 Guide to Operational Technology Security. September 2023; publication page planning note 21 September 2026. https://csrc.nist.gov/pubs/sp/800/82/r3/final Accessed 4 October 2026. Final Revision 3 distinguished from draft Revision 4.
- European Commission. Data Governance Act explained. https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained Accessed 4 October 2026. Regulated intermediary model and organisational conditions; applicability requires assessment.
- US Department of Energy. Green Button. https://www.energy.gov/data/green-button Accessed 4 October 2026. Historical programme explanation of energy-use information access and authorised exchange; no current adoption figures used.
About the Author
Chennakeshav (CK) is a corporate finance and investment banking executive with 25+ years of global experience in deal origination, structuring and execution across M&A, growth capital and corporate strategy. He has led value-creation mandates for founders, corporates and funds — bridging the boardroom view to hands-on execution and close.
His career spans Morgan Stanley, HSBC, Lloyds Banking Group, EWEC, ADQ portfolio companies and Emirates Growth Fund, across TMT, real estate, fintech, deeptech, cleantech, infrastructure and energy. He has partnered with C-suite leaders, private equity and venture funds, sovereign wealth funds and family offices to finance complex fund raises and scale-up ventures, and has led M&A due diligence, post-merger integration and business-transformation initiatives to create value.
At Matchpoint Partners he is Managing Partner, leading the firm's corporate finance, M&A and capital-raising practice. He holds an MBA from London Business School, an engineering degree from VTU and a Master of Laws (LLM, in progress) from UCL London.
An active start-up mentor, CK mentors at Techstars, DIFC FinTech Hive, Startup Grind, Founder Institute and IN5, serves as Entrepreneur Mentor in Residence (EMiR) at London Business School, and judges the Entrepreneurship World Cup.
