- Article ID: NU54-049
- Section: Hot
- Slug: smart-meter-data-privacy-resolution
- Prepared: 31 October 2026
- Evidence checked: 31 October 2026
- Dek: Interval electricity records can support a more flexible grid and a more revealing picture of household life. The privacy question is not whether a meter is smart, but which measurements leave it, who receives them and what those recipients are allowed to infer.
<!-- ARTICLE_BODY -->
A useful record becomes a revealing one
A monthly electricity total says how much energy a household bought. A sequence of interval readings begins to say when it bought it. That additional dimension is valuable: it can support time-varying prices, identify unusual consumption and help operators understand demand. It also creates a record of patterns that may be associated with work schedules, occupancy, heating, charging and other activity inside a home.
The difference is not hypothetical policy trivia. Ofgem opened a consultation on a Smart Data Repository on September 14, 2026, proposing governance arrangements for electricity data used in settlement and consent-based access by third parties. When checked on October 31, the official page marked the consultation closed and awaiting a decision. The proposal should not be described as a completed final governance regime. It does show how energy data infrastructure is moving beyond a meter-to-bill relationship. Ofgem's Smart Data Repository consultation.
The question is not whether all smart meters expose everything about everyone. They do not. Inference depends on sampling, available variables, household characteristics, auxiliary information and the method used. A half-hourly energy total is not equivalent to a high-frequency electrical waveform. Treating them as interchangeable exaggerates some risks while obscuring the more ordinary risks of identifiable long-term patterns.
A better question is what information each service actually needs. Billing, settlement, network planning, appliance advice and advertising are different purposes. They do not automatically require the same resolution, retention period or recipient list. A credible privacy design separates them and makes the tradeoffs visible. It allows useful energy services without assuming that every useful measurement should become a permanent, widely reusable household dossier.
Resolution has several dimensions
Granularity is often reduced to the interval length: monthly, daily, hourly or half-hourly. That matters, but it is only one dimension. A dataset also has a collection frequency, a transmission frequency, a retention period, a geographic scale and a set of measured variables. Confusing these dimensions makes both privacy promises and technical claims unreliable.
A meter might store half-hourly values and transmit them once a day. The daily transmission does not turn those values into daily data. Conversely, a device might sample internally at high frequency but release only a monthly total. The internal capability does not establish that an external party receives the detailed signal. The relevant analysis follows the actual data path.
Energy and power also differ. Energy accumulated over an interval summarizes consumption across that interval. Instantaneous or rapidly sampled power can reveal changes that are averaged away in a longer total. Reactive power, voltage and event information may add further context where collected and available. A privacy assessment should list the fields rather than rely on the broad label usage data.
Duration matters as much as resolution. One day of half-hourly values may be less revealing about a routine than several years of hourly values. Repetition allows an analyst to distinguish recurring patterns from unusual events. Location and account linkage can make an otherwise anonymous-looking sequence attributable to a household.
The first practical deliverable is therefore a data inventory with separate columns for what the device measures, what it stores, what each recipient receives and how long each copy remains. Include derived features and exports, not just the original readings. Without that inventory, an organization can truthfully say it transmits once a day while leaving users with a false impression about the detail contained in each transmission.
The arithmetic explains why more detail changes the risk
Consider a hypothetical month in which a household imports 300 kilowatt-hours. One monthly total is compatible with many different daily patterns. At half-hourly resolution, a 30-day month contains 1,440 intervals. Those values constrain the possible timing of consumption much more closely, even though they still do not identify every appliance or person.
Two households can have the same monthly total while using energy at very different times. One may have a steady heating load; another may concentrate consumption into evening cooking and overnight charging. The monthly total conceals that difference. The interval record exposes it to analysis. Whether the analyst can interpret it correctly is a separate question.
Averaging is information reduction, but it is not necessarily anonymization. A daily series can still reveal seasonal routines, extended absences or changes in occupancy. A monthly series linked to an address can reveal changes in consumption over years. The privacy benefit of coarser data should be evaluated against the particular inference or linkage risk, not declared absolute.
There is also a difference between a fact and a hypothesis. A sustained overnight load may be consistent with vehicle charging, but it could have another cause. A low daytime load may suggest absence, but a person can be home while using little electricity. A dataset can support a probabilistic inference without proving a personal circumstance.
That distinction matters because errors can cause harm too. A company might target, exclude or investigate someone based on a mistaken inference. Privacy analysis should therefore consider both accurate discovery and incorrect classification. The risk is not limited to a perfectly reconstructed household diary. It includes institutions acting as though a suggestive consumption pattern were an established fact about the people living there.
Appliance inference is a model, not a direct sensor reading
Non-intrusive load monitoring attempts to infer component loads from an aggregate electrical signal. In broad terms, the analyst looks for patterns associated with devices or operating states. The task becomes harder when appliances overlap, devices vary, measurements are coarse or the home differs from the training data. The output is an estimate, not an inventory directly measured by the utility meter.
Research on occupancy inference demonstrates why energy data should not be treated as behavior-free. For example, the original ABODE-Net study evaluated a learning-based occupancy method on two smart-meter datasets. That is evidence that occupancy inference is a serious technical task with demonstrated experimental results, not evidence that any ordinary utility record can identify occupancy perfectly in every home. ABODE-Net original research.
A responsible evaluation asks what was measured, at what resolution, in how many homes and with what ground truth. Did training and testing include the same households? Was the model tested across seasons? Were missing intervals and solar generation included? A high reported score on a narrow dataset may not transfer to a new population or commercial deployment.
Even imperfect inference can be useful to an organization with many records. A marketing system does not need to identify an appliance with certainty to rank households by likelihood. A network planner may find approximate charging patterns valuable at aggregate scale. The same technical capability can therefore support beneficial planning and intrusive profiling, depending on the recipient, purpose and safeguards.
The right response is neither to dismiss the research nor to turn it into a universal surveillance claim. Ask which inferences are reasonably possible from the data actually disclosed, how reliable they are and what actions recipients may take on them. A privacy policy that protects only raw readings while ignoring derived labels leaves the most consequential part of the analysis outside its stated boundary.
The meter does not necessarily measure the household's total demand
A grid-connected household with rooftop generation or a battery complicates interpretation. The meter may record net imports and exports rather than every internal flow. A low import reading can reflect low demand, local generation, battery discharge or a combination. Inferring behavior from the external exchange without accounting for those possibilities can be misleading.
A hypothetical home consumes 4 kilowatt-hours during an interval while generating 3 locally. Its net import is 1 kilowatt-hour if the simple balance applies and other flows are absent. Another home consuming only 1 kilowatt-hour with no generation can produce the same import value. The utility-facing measurement does not distinguish those internal states by itself.
Storage adds time shifting. Energy bought overnight may be used later, and a battery can make grid imports smoother than household activity. This can reduce some visible patterns while introducing others, such as a regular charging schedule. It should not be assumed to provide a comprehensive privacy guarantee. The outcome depends on control settings, capacity, other data and the inference being considered.
These distinctions matter for consumer advice as well as privacy. An application that mistakes net import for total consumption may offer inaccurate appliance estimates or savings claims. A household could then disclose detailed data without receiving the benefit used to justify the disclosure. Data quality and semantic accuracy belong in the service evaluation.
The European Commission describes smart grids and meters as supporting flexibility, network management and integration of technologies such as heat pumps and electric vehicles, while also acknowledging privacy and cybersecurity concerns. That broad policy rationale does not eliminate the need to identify what a particular meter stream actually represents. European Commission's smart-grid and metering overview.
Start with a purpose, then choose the smallest useful dataset
A monthly fixed-rate bill may require a different dataset from a tariff that varies every half-hour. A network study may need aggregated feeder demand rather than named household histories. An appliance-advice application may want detailed individual data, but wanting it does not establish that unlimited retention or unrelated reuse is necessary.
Purpose-based design asks a concrete question: what output must the service produce, and which inputs materially improve it? Test alternatives. Can daily totals support the promised comparison? Can the calculation happen locally? Can the provider receive a derived statistic rather than the entire history? Can old high-resolution data be replaced by a coarser summary once the operational need has passed?
The answer will not always be less data. Some services genuinely depend on timing. A dynamic tariff cannot be calculated accurately from a monthly total alone if prices and consumption vary within the month. A demand-response payment may require evidence of behavior during an event. The point is to connect access to a defined function rather than treat every available field as automatically useful.
The 2012 SEE Action regulator guide addresses third-party access to energy data as a balance between useful services and privacy protection. It is a historical guide, not a statement of current law in every jurisdiction. Its continuing relevance lies in treating access arrangements as design choices that need explicit responsibilities rather than assuming either total secrecy or unrestricted sharing. SEE Action's third-party energy-data privacy guide.
A purpose statement should be testable. Improving services is too broad to constrain anything. Calculating a customer's bill under a specified tariff, estimating a feeder's peak load or evaluating a defined demand event gives reviewers something to assess. If the purpose changes, the data arrangement should be reconsidered instead of silently expanding through an application update.
Consent should describe the data, not just the brand
A button labeled connect my energy account does not tell a person which data will move. It may authorize a one-time historical download, an ongoing stream or both. It may include one property or every account associated with a login. The difference is material, and the interface should make it visible before access begins.
A meaningful authorization identifies the recipient, purpose, fields, resolution, historical period, future duration and revocation route. It distinguishes required service processing from optional uses. It also explains whether the recipient can share the data onward and what happens to existing copies when access ends. These details should not be buried behind a general statement that partners help improve the experience.
The U.S. Department of Energy's Green Button description distinguishes customer downloads from an automated transfer capability based on affirmative customer authorization. The historical page explains the model of access; its old adoption figures should not be treated as a current market census. The important design distinction is between a user obtaining their own records and granting a third party continuing access. DOE's Green Button explanation.
The choice also needs to be understandable in context. A person shopping for a tariff may not realize that the same data can support occupancy or appliance inference. A service should explain plausible uses without sensationalizing technical capabilities. Consent obtained through a misleadingly narrow description does not become well informed because a long legal document technically mentions analytics.
An original 2025 preprint studying 965 Great Britain bill payers examined preferences for anonymization and the effect of information about privacy implications. Its findings support taking information and presentation seriously, while remaining survey and experimental research rather than proof of how every customer will behave in a real enrollment. Research on informed consent and smart-meter anonymization.
Revocation is a system behavior, not a sentence
A privacy notice may promise that access can be withdrawn. The promise has several technical meanings. Future meter retrieval can stop. An authorization token can be invalidated. A recipient can delete retained records. Derived profiles can be removed or restricted. Backups can age out under a defined policy. These are separate operations, and a single disconnect button may perform only the first.
Test the complete sequence. After a hypothetical user revokes access, attempt a new authorized-data request through the ordinary service path. Confirm that it fails appropriately. Check whether scheduled exports continue, whether cached copies remain in active analytics and whether downstream processors receive the change. The test should be performed with authorized test accounts, not by probing unrelated customers' records.
Revocation does not necessarily erase every record immediately. Billing, dispute or other lawful retention obligations may apply, depending on the jurisdiction and purpose. The service should explain those limits specifically. A vague statement that data may be retained for business reasons offers little information about the actual boundary.
Derived information needs attention. If a provider deletes raw intervals but retains a label such as likely electric-vehicle owner, it may preserve the inference the user cared about. A retention schedule should identify those features and their uses. Otherwise deletion can become a cosmetic change to the storage format rather than a reduction in personal profiling.
The same design should handle expired consent, account closure, a supplier switch and a move to another property. These events can break assumptions about who is authorized to see which history. An old account holder should not retain automatic access to the new occupant's readings merely because a service identifier remained unchanged. Privacy depends on maintaining the relationship among person, account, property and time, not just authenticating a familiar username.
Aggregation helps, but the group has to stay a group
Combining multiple households can reduce exposure of individual patterns and provide useful network information. But aggregation is not a magic label. The protection depends on group size, diversity, timing, auxiliary information and the way repeated releases interact. A group dominated by one large consumer may reveal more about that consumer than its membership count suggests.
Northern Powergrid's published dataset description provides a concrete operational example. It describes half-hourly data aggregated at feeder or substation level and says values are withheld when fewer than five meters respond in an interval. It also notes data-quality limitations. That is a specific publication rule, not a proof that five is a universally safe threshold or that the dataset is suitable for every inference. Northern Powergrid's aggregate smart-meter dataset description.
Missing responses matter. A group with many installed meters may have only a few reporting during a particular interval. Publishing the nominal group size rather than the actual contributor count can overstate the protection. Changes in membership can also create opportunities to compare totals across time or overlapping groups.
A hypothetical release contains the sum for ten homes and another sum for nine of the same homes. Subtracting the two reveals the remaining home's contribution if the intervals and values align. This simple differencing example shows why reviewing each table separately is insufficient. The privacy assessment must consider the family of releases and what users can combine.
Aggregation should therefore include rules for small groups, dominant contributors, overlapping queries and time consistency. It should also be evaluated against the intended utility. A planning dataset may tolerate coarser groups or delayed publication; a real-time operational task may not. The choice should be made deliberately, with the residual risk explained rather than hidden behind the assumption that removing names makes a time series anonymous.
Pseudonyms are useful controls, not invisibility cloaks
Replacing an account number with a random identifier can reduce casual exposure and separate analytical work from direct identity information. It does not necessarily prevent linkage. A distinctive consumption pattern can recur across datasets. Location, tariff, device ownership or a known event can supply additional clues. The risk depends on what other information is available to the recipient.
Stable pseudonyms also enable longitudinal tracking. That may be necessary for evaluating a program, but it preserves a household-level trajectory. Rotating identifiers can reduce some linkage while complicating legitimate analysis. Neither choice should be presented as automatically anonymous. The design needs to state which associations remain possible and who can reverse the mapping.
Separation of duties can help. One team may hold the identity mapping while another receives only the data needed for a defined analysis. Access to the mapping should be controlled and logged. Yet organizational separation is not a substitute for examining the data itself. If the analytical dataset contains an exact address or a uniquely identifying combination of attributes, the pseudonym contributes little.
A useful privacy test asks what a motivated recipient could infer using information reasonably available to them. It should not assume unlimited omniscience, but it should not assume recipients know nothing beyond the released file. The threat model should include accidental linkage as well as deliberate reidentification.
This does not mean all de-identification efforts are worthless. It means their claims should be proportional. Pseudonymization can be an important layer alongside restricted access, limited purpose, short retention and controlled outputs. The failure is calling that layer complete anonymity and then permitting unrestricted reuse. A well-described partial protection is more useful than an absolute promise the data cannot support.
Differential privacy requires a defined promise
Differential privacy offers a mathematical way to bound how much a person's participation can affect a released result, under a specified model. It can support statistical analysis without exposing exact individual contributions. But the label alone does not tell a reader what is protected, how strong the protection is or how repeated releases are accounted for.
NIST's March 2025 guidelines focus on evaluating differential-privacy guarantees and the implementation hazards that can weaken them. The document is a framework for understanding claims, not an endorsement of every system that adds random noise to a dataset. NIST SP 800-226.
For energy data, the protected unit matters. A guarantee about one interval is different from a guarantee about one household's entire year. A household contributes many correlated readings. If the guarantee protects only one interval at a time, the apparent protection may not match the consumer's concern about their overall routine. The design should say whether it protects an event, a day, a person or a household history.
Repeated queries matter too. Releasing many overlapping statistics can consume a privacy budget. The system needs an accounting method and a policy for refusing or modifying further queries. A single impressive parameter in a product brochure does not explain the cumulative effect of years of publication.
Utility should be tested on the actual task. Noise that is tolerable for a large-area average may make a small feeder's peak estimate unreliable. A privacy mechanism can also affect small groups differently from large ones. The evaluation should report those tradeoffs rather than promise that privacy arrives at no analytical cost.
Differential privacy is best treated as an engineering commitment with explicit assumptions, not a decorative synonym for safe data. It can be a strong component of a release strategy when its protected unit, parameters, composition and implementation are understood. It does not replace access control for raw records or permission to use the resulting statistics for any imaginable purpose.
Demand response creates a second measurement problem
A demand-response program may pay customers to change consumption during specified periods. Interval data can help establish what happened, but the payment often depends on a counterfactual: how much the household would have used without the event. That baseline is modeled, not directly observed. The program therefore combines privacy questions with measurement uncertainty.
A hypothetical customer uses 2 kilowatt-hours during an event. If the baseline predicts 3, the measured reduction is 1. If the baseline would more reasonably have been 2.2, the reduction is only 0.2. The same observed data can produce different credited performance because the counterfactual differs. A provider should explain the baseline method rather than imply the meter directly measured avoided consumption.
Privacy design can begin by asking which data are needed to estimate that baseline fairly. A long history may improve some models, but unlimited history should not be assumed necessary without testing. Weather, household changes and equipment additions can make old data less relevant. A model that collects more while predicting worse offers a poor tradeoff.
Program evaluation should also distinguish energy shifting from energy reduction. A customer may move charging to another hour without reducing total consumption. That can still benefit the grid, but it is a different outcome. Reports should identify the service delivered and avoid using one metric to imply another.
Participants need a way to dispute missing data, incorrect baselines and mistaken account assignments. A privacy-respecting service should not become unaccountable by hiding all calculation details. The goal is to provide the relevant evidence without unnecessarily exposing unrelated household activity. Data minimization and a usable dispute process can reinforce each other when the system stores a clear, purpose-specific record of how the payment was calculated.
Local processing can reduce exposure without eliminating every tradeoff
Not every useful calculation needs to send raw household history to a central server. A local device or trusted customer application can compute a summary and share only the result needed by a service. For some tasks, this can materially reduce the amount of detailed data leaving the home or the customer's control.
The architecture must be examined carefully. A supposedly local application may still transmit diagnostic logs, crash reports or derived features that reveal much of the original pattern. A cloud backup may copy the local database. A remote support feature may expose records to staff. The privacy claim should describe all outbound data, not only the main analytics interface.
Local processing also creates reliability and security responsibilities. Software updates, device replacement and key management still matter. If a payment depends on a locally computed result, the provider needs a way to trust its integrity without demanding all the underlying data by default. Different tasks will justify different verification mechanisms.
The right comparison is between complete system designs. Central processing may simplify maintenance but concentrate data. Local processing may reduce central exposure but place more responsibility on devices and users. A hybrid arrangement may retain raw detail briefly, transmit a limited summary and allow customer-controlled export when needed. No architecture should be declared superior without considering the service and threat model.
The practical benefit of this comparison is that it challenges an unspoken assumption: useful analysis requires collecting everything first. Sometimes it does; often a narrower computation can answer the actual question. Testing that possibility before deployment can avoid years of unnecessary data accumulation. Once a detailed archive exists, organizational incentives tend to discover new uses for it. The strongest protection may be deciding that the archive is not needed in the first place.
Security protects the data path; privacy constrains the authorized use
Encryption and authentication are essential, but they answer only part of the question. A system can securely deliver detailed data to an authorized recipient who then uses it for an unexpected purpose. No breach is required. Privacy therefore includes decisions about permissible analysis, retention and onward sharing, not only protection against outsiders.
NIST's smart-grid cybersecurity guidance frames the grid as an interconnected environment whose risks require tailored assessment. That is useful context for following data across utilities, service providers and devices rather than treating the meter as the only security boundary. The 2014 guidance is not proof that a current deployment satisfies every contemporary requirement. NIST's smart-grid cybersecurity framework.
Access should be tied to roles and purposes. Billing staff may need a different view from network planners or marketing teams. An analyst who can work with aggregates should not receive named household histories merely because they share an employer with the billing operation. Service accounts and automated jobs need the same discipline as human users.
Audit logs should record consequential access and exports without becoming an uncontrolled second copy of the data. A useful log identifies who accessed which resource, under what authorization and for what operational purpose. Monitoring should look for unusual volume or patterns, but it should also review ordinary access that no longer has a valid business need.
Supplier arrangements require particular attention. A utility may retain responsibility while a processor stores or analyzes the data. Contracts need to specify access, retention, incident handling, subcontractors and exit arrangements. The customer should not have to map a hidden chain of vendors to understand who can see their energy history. A secure architecture and a constrained-use policy are complementary protections; neither can substitute for the other.
A household is not always one consenting person
Electricity accounts are commonly organized around a named customer, but the readings can reflect several people. Partners, children, lodgers, tenants and visitors may contribute to the same pattern. An account holder's authority to manage the service does not make every ethical question about household inference disappear.
Shared housing illustrates the difficulty. A single meter may cover people with different schedules and privacy preferences. A landlord may pay the bill while tenants generate the consumption pattern. A former partner may still know login credentials. The design needs to distinguish account administration from unrestricted permission to monitor the behavior of everyone associated with the property.
Move-in and move-out boundaries are especially important. Historical records may be useful for estimating costs, but detailed readings from a previous household should not automatically appear in a new customer's application. Conversely, an old authorization should not follow a meter identifier into a new tenancy. The system must model occupancy and account periods accurately enough to enforce those distinctions.
A hypothetical energy app that shares an unusually quiet day with all linked account users could create a privacy problem even if no external company receives the data. Notifications, dashboards and family-sharing features deserve review alongside APIs. A feature designed for convenience can reveal information to someone whose relationship with the household has changed.
These cases do not yield one universal consent rule, and legal obligations differ. They do show why the privacy assessment should involve real household arrangements rather than an idealized single user. The technical unit is the meter; the administrative unit may be the account; the people affected may be several individuals. A good service does not pretend those units are always identical.
Retention should follow the lifecycle of the purpose
Data becomes easier to reuse when it remains available indefinitely. That convenience can turn a short-term operational need into a long-term behavioral archive. A retention policy should therefore specify what happens as data moves from immediate operations to billing, dispute handling, analysis and eventual deletion or aggregation.
Different resolutions can have different lifetimes. A service might need detailed intervals for a defined calculation and retain only the resulting total after the relevant review period, subject to applicable obligations. Another purpose may justify a longer history. The point is to make the transition explicit rather than preserve maximum detail because storage is cheap.
Deletion must cover active copies, exports and derived datasets. Backups may follow a separate expiry schedule, but restored data should not silently re-enter active use after the original record was deleted. Test environments deserve attention too. Production histories copied into development systems can expand access far beyond the original operational team.
Models trained on the data complicate the picture. Removing a record from a table does not necessarily remove every influence it had on a trained model. The significance depends on the model, task and applicable obligations. Providers should describe what they can actually do rather than promise universal erasure that their architecture cannot deliver.
A useful retention review starts with a concrete question: if the organization lost access to this category of old detailed data tomorrow, which legitimate function would fail? If the answer is merely that the data might be useful someday, the justification deserves scrutiny. The purpose of the review is not to destroy evidence needed for customers' rights or reliable billing. It is to stop speculative future analytics from becoming the default reason to keep a household's detailed history forever.
A missing interval is not evidence of an empty house
The data pipeline needs to preserve quality flags. A zero reading, an unavailable reading and an estimated reading are different states. Replacing all missing values with zero can manufacture a pattern of absence. Interpolating across a gap can manufacture a smooth routine that never occurred. Those transformations may be convenient for a model, but they should remain visible to anyone interpreting its output.
Time conventions also matter. Local clock changes can produce repeated or missing clock labels even when elapsed time is continuous. A system should distinguish timestamps, time zones and interval boundaries clearly. Comparing a household's apparent evening pattern across a clock change without proper alignment can create an artificial behavioral shift. The privacy concern is not only the disclosure of real routines; it is the creation of false ones through careless preprocessing.
A hypothetical application receives two hours of delayed data after a communications outage. If it orders records by arrival time rather than measurement time, it may place the consumption in the wrong part of the day. The customer sees a confident chart and assumes the meter observed that pattern. The error actually occurred in the application. Provenance and quality information help locate the problem without blaming the household or the device automatically.
Privacy-preserving summaries should carry enough quality metadata to avoid misleading analysis, while avoiding unnecessary personal detail. An aggregate can report how many meters contributed, which intervals were estimated and whether coverage changed. A household-facing tool can mark uncertain periods rather than presenting every point with equal confidence.
This is a practical reason to evaluate the entire service rather than only its statistical model. A model can be well designed and still receive a distorted history. Responsible data use means limiting exposure and preserving meaning. Neither goal is met when a tidy dataset conceals the transformations that made it tidy.
Better energy services need a better data bargain
Smart-meter data can help households understand costs and help electricity systems accommodate changing demand. Those benefits are real possibilities, not a reason to ignore privacy. The durable approach is to specify the bargain: which data are needed, what benefit they enable, who receives them, what inferences are permitted and how the relationship ends.
A consumer-facing explanation should distinguish the meter's capabilities from the data actually disclosed. It should identify ongoing access separately from one-time downloads and distinguish required regulated processing from optional services. Because rules differ by jurisdiction and change over time, a historical privacy framework should not be presented as a universal statement of current consent rights.
An operator-facing specification should be equally concrete. Define the fields, resolution, retention, access controls, aggregation rules and permitted outputs. Test revocation and household transitions. Evaluate inference risk using the actual dataset, not a generic claim that energy data is harmless or that every interval reveals an exact activity.
The most credible service will also explain uncertainty. Appliance and occupancy labels are estimates. Demand-response baselines are counterfactuals. Aggregated releases have limits. Acknowledging those facts protects people from mistaken conclusions as well as unwanted disclosure.
The monthly bill was never the only possible use of electricity information. Interval metering makes that fact harder to overlook. The challenge is to capture the value of timing without granting every recipient an open-ended right to interpret household life. A smart system should be able to measure carefully, share selectively and forget deliberately. Otherwise the meter becomes more informative while the people it serves become less able to understand or control the information relationship. <!-- /ARTICLE_BODY -->