The cable was damaged. The consequences spread across the city.

What happened

Stromnetz Berlin reports that the 3 January 2026 cable-bridge attack affected roughly 45,400 households and 2,200 commercial customers. Supply was restored to all customers on 7 January. District-heating pumps were also affected by the loss of electricity. The operator’s 8 January statement warned of possible brief interruptions during temporary network reconfiguration.

THW’s Berlin-Spandau account describes emergency-call reception points, transport tasks and support to the fire-service control room. The operator’s restoration statement also records cooperation with public authorities, emergency organisations and other infrastructure operators.

The repair and the response run on different clocks

For the electricity operator, an update might describe a damaged connection, an available repair route or a planned switching operation. For a local authority, the immediate question could be whether an assistance location remains usable. For a responding team, it could be whether a reported need has already been addressed. These are illustrative examples of different responsibilities within an outage, not assertions about failures in Berlin’s response. Their usefulness depends on knowing which organisation can confirm each answer.

A planned restoration time cannot safely stand in for a verified service status. Neither does power returning to an area establish that every dependent facility has resumed normal operations. A record needs an owner, an observation time and a clear meaning. Otherwise a forecast can remain on someone’s screen after circumstances change. The shared picture should help teams see that distinction rather than produce an apparently precise answer from information that is still provisional.

One damaged asset, several operational pictures

A repair team works with network topology. A municipality needs affected streets and assistance locations. Emergency services need verified requests and available resources. Those views should remain distinct, but they need common identifiers, time references and a way to exchange changes.

• Connect dependencies. Relate an asset to the facilities and services that depend on it, validating those relationships with the operator.
• Date every update. Separate a repair estimate from confirmed restoration and show when each observation was last checked.
• Track responsibility. Link a request to an assigned team, acknowledgement and outcome.

Follow one request through the dependency chain

Imagine an authorised report that a facility needs temporary power. Before allocating equipment, the responsible team needs to establish the location, the request’s current status and the person who can confirm the requirement. The power-system details must be assessed by the competent specialists. Coordination software can attach their approved information to the request, show its assigned owner and retain the source of each update. It should not infer that an available generator is suitable or issue electrical instructions.

Once a team accepts the assignment, other authorised participants should be able to distinguish acceptance, arrival and completion. If the request changes, the previous state remains part of the incident history. If a second organisation reports the same need, a reviewer can check whether it is a duplicate or a separate requirement at the same site. This example shows why common objects matter: a street, a building, an electrical asset and an assistance request are related, but cannot be treated as interchangeable labels on one map.

An operational layer alongside existing control systems

A Meridian project could connect authorised outage updates, facility records and field reports without replacing SCADA or directing grid switching. Shared objects in the ontology make dependencies inspectable. European sovereignty means agreed control over data, processing and access, alongside exercised continuity arrangements. Local hosting alone does not keep a service running during a power or network failure; backup power and communications remain necessary.

Test the operating picture under the conditions of an outage

A focused Meridian project could begin with a small set of approved facility records, outage-status updates and field reports. Operators and responders would agree what each status means and who can change it. The first exercise could follow one request through reporting, verification, assignment and closure. Another could introduce a conflicting update or remove a connection. The purpose would be to expose unclear handovers before extending the scope. No claim is made that this workflow describes the systems used in Berlin.

The evaluation should ask whether a team can identify an outdated observation, retrieve the latest verified source and determine who owns an unresolved action. It should also test what happens when the coordination environment is unavailable. Backup power, network dependencies and independent communications need their own arrangements; the field application’s full offline mode remains in development. For a European operator, control of deployment and data is valuable when it supports these practical responsibilities. Sovereignty includes the ability to maintain, inspect and recover the service, with defined partners and tested procedures.

The shared picture must explain what an outage means for the response.