Dimitri Wolf
Architect of the Thermal Plug Standard  ·  Thermal infrastructure for the AI era
Feature Interview VI  ·  The Intelligence Layer  ·  2026

The Intelligence Layer

The electricity grid tells you, in real time, how much power is available, where it is, and what it costs. The thermal grid cannot — not because the heat is absent, but because no node publishes its state. More than 24,000 waste heat sources are declared in Germany's register; the pipes to carry that heat are already in the ground. What is missing is the layer that turns this collection of potential connections into a network that dispatches, optimises, and schedules heat in real time: a standardized digital identity on every node, a model-predictive algorithm routing thermal energy, and storage that makes prediction actionable. This interview defines that layer.

Dimitri Wolf Mechanical engineer (MEng) Architect of the Thermal Plug Standard July 2026

A standard without an intelligence layer is just a better cable. The Thermal Plug defines the socket — the 19-parameter handoff boundary where a waste heat source connects to a thermal network. The intelligence layer defines what happens when every socket in the network is alive: publishing its state, receiving a schedule, absorbing a timing mismatch, shifting a batch workload to the hour when the campus runs coolest. That is the step from a collection of standardized interfaces to a network that thinks.

The digital profile for a Thermal Plug node — the AAS submodel conformant with IEC 63278 / IDTA — maps 30 fields across four functional blocks. Approximately 60 percent of those fields map directly to published IDTA templates today; three TP-specific submodels covering temperature grade, availability profile, and contractual parameters require authoring from scratch — weeks of standards work, not years. The city-scale thermal buffer that makes model-predictive dispatch possible is not speculative: Høje Taastrup outside Copenhagen has operated a 3,300 MWh pit thermal energy storage (PTES) at a measured annual efficiency of 89 percent on a one-to-two-week storage cycle since February 2023. The physical components of the intelligence layer exist. The standard that connects them to the Thermal Plug specification does not yet.

This is the sixth interview in a series on thermal infrastructure and the future of energy networks — following The Thermal Plug, The Reverse Thermal Plug, Built for Heat, Heat as a Seed, and Use What You Own. The first five defined the interface, its bidirectional logic, the enclosure that produces the heat, what grows from a stable thermal source, and the national map of 24,000 declared sources waiting to be connected. This interview asks what happens after the socket exists: how a collection of standardized connections becomes a network that dispatches, optimises, and schedules heat by itself. Dimitri Wolf is Architect of the Thermal Plug Standard, a mechanical engineer, and a DIN standardization committee member and participant in European CEN working groups on district heating and cooling systems.

Interview V left a precise inventory: 24,215 records in Germany's public waste heat register, classified by Thermal Plug compatibility. More than a quarter carry their heat in a liquid and connect with an interface bolted to the outside of an existing pipe. The map is drawn. The physical interface is defined. The 19 parameters that cross the handoff boundary are specified.

That is the socket. The intelligence layer is the argument of this interview. A thermal network is not just a collection of pipes and defined interfaces — it is a system with state. Each node has a current temperature, a current available power, a timing profile, a role in the network. Left unmanaged, a collection of Thermal Plug connections remains a bilateral system: each dispatch decided by manual agreement between two parties. Managed by an intelligence layer — a standardized digital profile on every node, a model-predictive dispatch algorithm, and thermal storage absorbing the timing mismatches — the same physical connections become infrastructure that can be scheduled, optimised, and eventually traded. The physical layer and the intelligence layer are not two separate projects. They are two halves of one standard.

Q 01  ·  The Gap

You have the physical interface and the national map. What is still missing before this becomes a functioning network?

Interview V ended on a specific observation: the heat is documented, the grid is built, the demand is mandated — and every connection is still hand-made. You have defined the Thermal Plug, the repeatable physical interface. What has not been solved?

Three things, in order. First: every node must have a machine-readable digital identity. Not a PDF commissioning sheet — a live profile that a dispatch algorithm can query at any moment: current supply temperature, available thermal power in kilowatts, system status, a 24-hour forecast of availability. Today, no waste heat source in Germany publishes that. The Plattform für Abwärme — Germany's public waste heat register — is a static annual snapshot in a spreadsheet. You can download it this afternoon. You cannot query it. You cannot ask what is available right now, at what temperature, in which grid sector. The physical map exists; the live data layer does not.

Second: the network state must be visible in aggregate. One queryable node is useful. A hundred queryable nodes, all publishing in the same standard format, all visible to a common dispatch layer, is infrastructure. The difference between a collection of standardized sockets and a network is coordination: something that knows what every node holds and routes supply to demand continuously — not by negotiation, but by algorithm.

Third: there must be an optimisation algorithm that schedules across the whole system. Charge the thermal buffer when supply exceeds demand. Discharge it into the evening peak. Shift batch compute workloads to the morning hours when the campus runs coolest and exports its hottest waste heat. Hold a grade-A source in reserve for the coldest morning of the season. None of those decisions can be made by the physical interface alone. They require data, a model, and an algorithm. The Thermal Plug is the socket. The intelligence layer is what makes the socket part of a network rather than just a better cable.

The physical interface defines the socket. Three things remain: a live digital identity for each node, a layer that makes the whole network visible, and a dispatch algorithm that routes the heat.
Q 02  ·  The Digital Twin

What does a standardized digital identity for a thermal node actually look like — and is it a real standard or a design intent?

You reference the AAS — Asset Administration Shell — as the digital profile format. What is it, how does it map onto a Thermal Plug node, and what can be claimed about its current state of readiness?

The Asset Administration Shell is a metamodel defined in IEC 63278, maintained by IDTA — the Industrial Digital Twin Association. It is the Industrie 4.0 standard for machine-readable digital profiles of physical industrial assets: a pump, a valve, a sensor — or a thermal connection node. Each asset gets a standardized shell containing submodels: typed, schema-defined containers for distinct categories of information. The shell exposes a standardized HTTP/REST API, specified in IDTA-01002, so any system that speaks the standard can query any compliant node without custom integration work. The metamodel is published, stable, and tooled — open-source AAS server software runs today on edge hardware costing under a hundred euros. The AAS-to-OPC UA mapping is formally specified in the OPC Foundation's I4AAS companion specification (OPC 30270), with no translation layer required.

I am authoring a TP submodel profile conformant with IEC 63278 and the published IDTA template library. Approximately 60 percent of the profile maps to existing published templates: IDTA 02003 (Technical Data) for static installation parameters, IDTA 02004 (Handover Documentation) for commissioning certificates and meter calibration records, IDTA 02006 (Digital Nameplate) for hardware identity, and — most important for the live data path — IDTA 02008 (Time Series Data, v1.1, Published). The live parameters the node needs to publish — supply temperature, return temperature, flow rate, available thermal power, cumulative energy, differential pressure, fluid pH, conductivity — all map into IDTA 02008 time series segments, polled via OPC UA (IEC 62541) at five-second intervals. wM-Bus is explicitly excluded from the control path: it is metering-grade, not control-grade.

Three submodels do not yet exist in the IDTA library and must be authored from scratch: TP_TemperatureGrade (the A/B/C classification by supply temperature at the handoff point), TP_AvailabilityProfile (the 24-hour forecast and seasonal pattern), and TP_ContractualParameters (the bankable contractual floor — minimum supply temperature and minimum guaranteed output). No existing IDTA template covers waste heat source characterisation. No OPC UA companion specification covers district heating network nodes. No machine-readable semantic definition for BEW (federal heat network subsidy) eligibility exists anywhere in the industrial standards ecosystem. Those three gaps are authoring work in progress — weeks of standards work, not years. The correct claim is that I am authoring the TP submodel profile conformant with IEC 63278; not that it is filed, submitted, or ratified.

The first-mover position is real and verifiable. No AAS-native deployment could be found anywhere in European district heating today — and I have looked. Fraunhofer ITWM's DingFESt project at Technische Werke Ludwigshafen (completed 2023) uses a conventional proprietary simulation model — not an IDTA-conformant AAS. BEW Berlin's AI-augmented digital twin with Neurospace, a proof of concept published in October 2025, uses a standard machine-learning pipeline, not an IDTA AAS stack. The standard infrastructure to build the first AAS-native thermal node exists. No one has built it yet.

No AAS-native deployment exists in European district heating today. The template library covers 60 percent of the TP profile. The three novel submodels represent weeks of authoring work — and none has been filed or submitted yet.
Industrial monitoring and control systems with real-time data displays
The intelligence layer turns a collection of standardized physical connections into a network with state. Each AAS-enabled Thermal Plug node publishes its temperature, capacity, and availability in real time — the live data layer that district heating has never had.
Q 03  ·  The Buffer

Why can't the network just match supply to demand in real time? Why does thermal storage matter?

The AAS profile makes each node queryable. The dispatch algorithm can see the whole network. Why is thermal energy storage part of the intelligence layer at all — can't the system simply match available supply to current demand, moment by moment?

Real-time matching is brittle. A data center scheduled for maintenance cuts its waste heat output to zero for six hours. A district heating demand peak arrives two hours earlier than forecast because a cold front moved faster than the weather model predicted. A batch job that was going to run during the morning cooling window gets deprioritised. In a real-time-only system, every mismatch causes the district heating operator to fire up a gas boiler backup. Storage absorbs those mismatches. Without it, the dispatch algorithm is reactive. With it, the algorithm thinks ahead.

Thermal energy storage is not storage for its own sake. It is the memory that makes prediction actionable. The model-predictive dispatch layer optimises over a 24-hour horizon: charge the buffer during the morning surplus, discharge it into the evening demand peak, hold reserve capacity for cold-snap events. That optimisation is only possible if there is somewhere to put the surplus heat while the forecast plays out. TES is not storage. It is memory. And memory is what makes prediction possible.

The technology splits by scale. At the city and district heating network level, the right anchor is pit thermal energy storage. The clearest operational precedent is Høje Taastrup, outside Copenhagen: 70,000 m³ of water, 3,300 MWh of thermal capacity, 30 MW charge-and-discharge power, operated since February 2023 by VEKS and HTF on the Greater Copenhagen grid. In 2024 it completed 25 to 30 short-cycle charge-discharge operations — daily and weekly dispatch cycles, not seasonal — at 89 percent annual round-trip efficiency. Cost is on the order of 1 to 5 €/kWh of storage capacity. At that cost and that efficiency, PTES is the district heating operator's equivalent of a large grid battery: a managed buffer asset that allows the network to absorb surplus heat, hold it, and discharge it when demand requires. The district heating operator goes from a passive recipient of whatever waste heat arrives to an active participant in a scheduled thermal system.

At the building and individual node level, the starting point is a stratified hot-water buffer tank — 94 to 97 percent short-cycle round-trip efficiency, commercially standard, no experimental risk. Phase-change material (PCM) adds footprint compactness: four to six times the energy density of water at the same temperature swing, with 85 to 92 percent round-trip efficiency. The critical sizing constraint for PCM is its peak-power delivery limit — 5 to 15 kW per cubic metre — which means a 1 MW peak discharge requirement implies roughly 100 m³ of PCM, and that physical volume must be accommodated in the building. Thermochemical storage is pre-commercial and should not be presented as a near-term option. The correct answer at building scale is hot-water tank first, PCM where floor area is the constraint, and PTES where the district heating operator can invest at city scale.

One asymmetry to state honestly: the morning load-shift argument — shifting heavy batch compute to the 09:00–12:00 cooling window and increasing waste heat export in the same period — creates a heat surplus precisely in the hours when district heating demand is at its seasonal minimum. The surplus case is summer-dominant. In the heating season, the same waste heat the network was about to have too much of becomes a welcome supply against high demand. The dispatch algorithm must handle both conditions: size the buffer for the summer surplus case, not the winter deficit. And the algorithm must know the thermal storage state at the receiving district heating network end, not only at the data center end.

TP Node AAS Profile v0.1 — 30 fields / 4 blocks (IEC 63278 / IDTA)
BlockKey fieldsStandard anchorStatus
Static IdentityTP_Class, TP_Role, TemperatureGrade (A ≥70 °C / B 40–70 °C / C <40 °C), PfA_SourceID, BEW_Eligible, Min_Supply_Temp_°C, Min_Guaranteed_Output_kW, HX_MaxPower_kW, DN_HandoffPoint_mm, CommissioningDateIDTA 02003 (Technical Data, Published) · IDTA 02006 (Digital Nameplate v3.0.1, Published) · TP-authored fieldsIDTA templates published; TP-specific fields in authoring
Live TelemetrySupplyTemperature, ReturnTemperature, FlowRate_m³h, ThermalPower_Live_kW, CumulativeEnergy_kWh, DifferentialPressure_Pa, FluidQuality_pH, Conductivity_µScm, ActiveSetpoint_°C, ControlMode, MaxExtractablePower_kWIDTA 02008 Time Series Data (v1.1, Published) · M-Bus EN 13757-3 · OPC UA IEC 62541 · AAS-OPC UA mapping OPC 30270 (I4AAS)Template published; field mapping complete; 5 s poll; wM-Bus excluded
Status & FaultSystemStatus (5-value enum: AVAILABLE / CHARGING / TRANSITIONING / FAULT / OFFLINE), FaultCategory (21-value enum), FaultSeverity, FaultTimestamp_UTC, TemperatureGrade_CurrentLiveTP specification — no IDTA, ECLASS, or OPC UA equivalent exists for any of these fieldsTP-original taxonomy; first-mover position confirmed vacant in IDTA library
ForecastAvailability_24h (Boolean[24], one value per UTC hour), Forecast4h_kW (rolling, updated hourly), Forecast_LastUpdated_UTCIDTA 02008 time series structure (InternalSegment, TimeSeries submodel) · TP-authored forecast semantics and update cadenceData structure reused from published template; forecast semantics require TP authoring

AAS metamodel: IEC 63278-1:2023 (IDTA-01001-3-0 V3.0, April 2023). All 19 Thermal Plug parameters mapped across the four blocks. SLA-grade temperature averaging: 15-minute rolling mean (established smart-metering practice; billing meters MID-certified per Annex MI-004 / EN 1434). Edge hardware minimum: Raspberry Pi CM4 4 GB (~€35) or SIMATIC IOT2050 (~€300); local AAS persistence with cloud sync; cloud round-trip latency target <200 ms. No IDTA submodel template, no ECLASS IRDI class, and no OPC UA companion specification currently exists for district heating network nodes or waste heat source characterisation — the TP profile would be first in each category.

"TES is not storage. It is memory. And memory is what makes prediction possible. Without the buffer, the intelligence layer reacts. With it, it schedules."

Dimitri Wolf
Q 04  ·  The Dispatch Algorithm

What does model-predictive dispatch actually do — what is it optimising, and is it genuinely novel?

The AAS profile gives every node a machine-readable state. Thermal storage gives the system time. What does the dispatch algorithm do with those two things — and is the method new, or is this established technology being applied somewhere it has never been applied before?

Model-predictive control (MPC) is not novel technology. It has a 20-year operational track record in district heating and building energy management: constrained optimisation over a receding horizon, re-solved every few minutes as new data arrives. The solvers exist. The control theory is textbook. What has never existed in thermal networks before is the real-time data layer to run it at network scale — telemetry from multiple independent nodes, each publishing a standardized AAS profile, all visible to a common optimiser. AAS on OPC UA provides that data layer for the first time. The algorithm is borrowed from grid-scale battery dispatch. The data infrastructure is the original contribution.

What the algorithm optimises: given the current AAS telemetry from every TP node, the 24-hour ambient temperature and evapotranspiration forecast from Open-Meteo MOSMIX (free, programmatic, hourly resolution at any European coordinate), the thermal buffer state at each storage node, the district heating operator's demand forecast, and the EPEX SPOT electricity price signal — relevant for heat pump dispatch when a grade-B or grade-C source needs temperature lift — find the 24-hour schedule for every node that minimises total fossil heat consumption in the network, maximises waste heat utilisation, maintains district heating programme compliance, and avoids overflowing or emptying any buffer. The output is a schedule that executes until the next optimisation cycle, adjusted continuously as telemetry updates the model.

One hard dependency to name explicitly: the algorithm needs a calibrated pipe-segment thermal model — a map of heat loss as a function of pipe length, insulation condition, soil temperature, and flow rate between every source and sink in the network. That is the hardest single input to obtain, because it requires the district heating operator to share network topology data that is currently proprietary. Without it, the optimiser dispatches efficiently at the node level but cannot accurately account for thermal losses between nodes. The natural entity to run the dispatch function is the municipal district heating operator — the Stadtwerk — precisely because it already owns the pipe model, the demand forecast, and the network state. The intelligence layer is a tool the operator uses. It does not override the operator.

The best available field calibration for what MPC delivers in district heating: a peer-reviewed study at two Canadian sites, published in Energy in 2023, operated over 2 to 3 months each — GHG reductions of 1.3 and 2.8 percent against the baseline. Modest, statistically validated, and honest. The argument for MPC in a TP network is not that a single deployment transforms the energy balance. It is that as more nodes join the network and the model becomes better calibrated, the dispatch decisions compound. The value of the intelligence layer grows with every node added, because every node makes the model more accurate and every more accurate model makes every other node more valuable.

Q 05  ·  The Building That Knows What Time It Is

In Interview IV you designed a campus around its morning cooling advantage. How does the intelligence layer connect to that?

The campus in Interview IV was designed with earth-to-air heat exchange, surrounding vegetation for evapotranspiration, and a morning passive cooling window. You said the building should know what time it is. What does that mean in the context of the intelligence layer?

The campus designed in Interview IV has a passive cooling advantage that peaks in the 09:00–12:00 window. That is when the evapotranspiration from the vegetation buffer reaches its morning maximum, the ambient temperature is still below the diurnal peak, and the earth-to-air heat exchange system pre-conditions incoming air at its most effective. During those three hours, the servers operate in cooler inlet conditions: lower supply temperatures, lower fan power, higher efficiency across the rack. The waste heat leaving the campus in that window is hotter, more plentiful, and more valuable to the district heating network than at any other point in the operating day.

Batch artificial intelligence workloads — training runs, dataset preprocessing, model evaluation at scale — have no strict latency requirement. A training job that runs for eight hours does not care whether it starts at 07:00 or 09:30. The intelligence layer knows the evapotranspiration forecast for the day ahead, the ambient temperature curve, the district heating demand profile, and the thermal buffer state at the receiving network. It can therefore recommend — or, within pre-agreed operational bounds, automate — the compute schedule that maximises the thermal value of the waste heat the campus produces. Run the heavy batch workloads when the campus runs coolest and the network has the most capacity to absorb what it exports. The building stops being a fixed load profile attached to the grid and becomes a participant in the thermal system it feeds.

The academic state of the art in thermal-aware load scheduling covers reactive inference dispatch. TAPAS, published by Microsoft Research in 2025 (arXiv 2501.02600), adjusts inference routing based on current server inlet temperature. TAWS from ACM SIGEnergy, also 2025, does the same for high-performance inference in cooling-regulated facilities. What does not yet exist in the published literature — and is confirmed absent after systematic search — is proactive, forecast-based shifting of pre-scheduled heavy batch workloads at campus-ambient scale, using outdoor evapotranspiration as the scheduling signal. That is the novel step. The intelligence layer is the architecture that makes it possible, because it combines the ambient forecast with the network demand model and the compute schedule in a single optimisation loop.

Two constraints to name honestly. The 06:00 to 09:00 period is a German electricity grid ramp-up window — above-average EPEX SPOT prices and elevated grid stress at the same time. Shifting large compute loads into that window worsens operating cost and grid impact simultaneously. The correct scheduling window is 09:00 onwards. Additionally, a data center shifting its load profile within its contracted grid capacity may carry notification obligations to its distribution system operator (DSO) whose precise scope for this case has not been confirmed by legal review. I name that as a flag, not a resolved constraint.

The building that knows what time it is runs cooler and exports more. The intelligence layer connects the campus's passive physics to the thermal network it feeds — and closes a gap in load scheduling that the literature confirms is open.
Q 06  ·  The Thermal Market

Is there a point where the intelligence layer makes a thermal market possible — where connections happen without two-year negotiations?

You have described a physical standard, a digital profile format, a dispatch algorithm, thermal storage, and load scheduling. Taken together, what do those layers enable that none of them enables alone?

Every functioning commodity market in history required three layers before it stopped being a collection of bilateral deals. A physical interface: supply and demand connect without bespoke engineering on every connection. An information layer: buyers and sellers can see what is available, where, at what price, in real time. And a contract template: the deal closes without a fresh legal project each time. The Thermal Plug and the intelligence layer together provide the first two. The third does not yet exist anywhere in Europe.

The closest structural analogy is the German gas market before standardisation. GasNZV — the Gas Network Access Regulation — defined third-party access rights to gas pipelines. DVGW published the technical connection standards. BGW and DVGW together published model contract templates. The combination — access right, technical standard, model contract — created the gas spot market: entry-point and exit-point capacity booking replaced bilateral pipeline-access negotiations, and the cost and time of a gas supply agreement collapsed. GasNZV expired at the end of December 2025 and its regulatory content has been taken over directly by the Bundesnetzagentur; the institutional structure has changed, the sequence it demonstrated has not. That is the sequence thermal infrastructure needs. The Thermal Plug is step one of three.

The current gap is step three: no standardized heat supply contract for waste heat feed-in to district heating networks exists in Europe. BDEW — Germany's energy industry association — publishes standardized contracts for electricity, gas, and hydrogen. Nothing for waste heat feed-in. AGFW, the German district heating trade association, has not published a model contract for this interface. Every bilateral connection today is a custom legal project. The closest operational precedent — Stockholm's Open District Heating at Stockholm Exergi, operational since 2014, 56 gigawatt-hours traded in 2024, more than 30 data centers connected — works because Exergi is the sole buyer and every deal is bilateral under commercial terms Exergi controls. That is not a market. That is a managed utility monopsony. It proves the value thesis. It does not solve the contract template problem.

There are gaps on the metering and regulatory side that need honest names. A thermal market in the full sense requires MID-certified heat meters at every handoff point — Measuring Instruments Directive Annex MI-004. That requirement is addressable and is already part of the Thermal Plug specification. A settlement and balancing mechanism does not yet exist for distributed thermal markets in Germany. Germany's heat planning law creates heat planning duties for municipalities but creates no market structure. Article 24 of the Renewable Energy Directive (RED II as amended by RED III) encourages district heating operators to connect waste heat sources but does not compel them. There is no enforceable third-party access right to the network today. These gaps are real, and resolving them requires legislative action beyond the TP standard.

The framing that district heating operators should hear as opportunity rather than threat: a thermal market is the operator's upside. When every Thermal Plug node publishes an AAS profile and every connection uses a model contract, the operator can source heat competitively — from multiple certified suppliers, at a known interface, on known terms — instead of being locked into a single bespoke bilateral deal with one industrial partner. The intelligence layer is the tool the operator uses to manage that network. They are not disintermediated. They are upgraded: from a single-source procurement model to a managed portfolio of standardized supply nodes. That is what a thermal market gives the Stadtwerk. Every other commodity market has this infrastructure layer. Thermal does not. Yet.

Sidebar  ·  The Electricity Parallel

Carbon-aware compute scheduling already exists for electricity. Why hasn't it been done for heat?

Carbon-aware batch scheduling for compute workloads is a solved problem in the electricity domain. Tools like WattTime and the broader carbon-aware computing movement have demonstrated that pre-scheduled batch jobs can be timed to the hours when the electricity grid is cleanest — shifting flexible demand to align with variable supply. The structural logic is identical to what the intelligence layer proposes for thermal networks: defer deferrable compute to the hours when the supply signal is most favourable.

The reason it has not been done for heat is not the algorithm. It is the data. Carbon intensity for the electricity grid is published by every European grid operator in real time, via standardised APIs, to anyone who wants it — ENTSO-E, national transmission system operators, and commercial aggregators all make it available programmatically. Thermal availability data for district heating networks does not exist in any queryable form. The waste heat register is an annual spreadsheet. No district heating network publishes its current buffer level, its current fossil-versus-waste-heat mix, or its current heat acceptance capacity to a programmatic endpoint. The dispatch algorithm that thermal-aware load scheduling needs is conceptually identical to carbon-aware compute scheduling. What is missing is the feed.

The AAS profile for each Thermal Plug node is that feed. Once every node publishes its state in a standard format, thermal-aware scheduling becomes a direct translation of a technique already proven in the electricity domain. The data gap is the intelligence layer's founding argument. It is also the exact gap the AAS profile closes.

"The electricity market solved the data layer thirty years ago. Every node, every watt, every price — visible in real time to anyone with the standard query. The thermal market has not started. Yet the heat is there. The pipes are there. The buildings are connected. The intelligence layer is what is missing."

Dimitri Wolf
Outlook  ·  What the intelligence layer asks for next
The standard defines the socket. The intelligence layer makes the network think. The contract template is the work that remains.

Five interviews established the physical architecture of the Thermal Plug: what it is, how it runs in both directions, what the enclosure looks like when built from thermal physics rather than default data center practice, what grows from a stable thermal source, and where every source in Germany is already declared and waiting. The sixth interview adds the intelligence layer: a standardized digital profile on every node, a model-predictive algorithm that dispatches heat across the network, thermal storage that turns a reactive handoff into a scheduled system, and a compute load scheduler that treats the morning cooling window as a network asset.

The AAS submodel profile for a Thermal Plug node covers 30 fields in four functional blocks. Approximately 60 percent of those fields map to published IDTA templates today. The three novel submodels — temperature grade, availability profile, contractual parameters — require TP-specific authoring work that represents weeks, not years. The first-mover position is confirmed: no AAS-native deployment could be found in European district heating. The profile, once authored and submitted to IDTA, positions the Thermal Plug standard at the intersection of two ecosystems — thermal infrastructure and Industrie 4.0 digital twins — at a point where neither has claimed the territory.

The thermal market at the end of this series is not a product the Thermal Plug builds. It is what emerges when the conditions are met: a standard physical interface on every connection, a live data layer on every node, and a contract template that closes deals without five-figure legal fees and two-year timelines. The gas market exists because GasNZV defined access rights, DVGW defined the technical interface, and model contracts made the transaction frictionless at scale. The same sequence applies here. The Thermal Plug is step one of three. Step two is the third-party access right — a legislative matter that requires policy action beyond the standard. Step three is the model contract — a matter for AGFW or BDEW, the industry bodies that publish energy supply contract templates in Germany. When that contract exists, the Thermal Plug standard, the AAS intelligence layer, and the model contract together constitute the infrastructure every bilateral heat negotiation currently rebuilds from scratch.

What the TP programme controls directly is step one and the data layer that makes steps two and three worthwhile when they come. When a regulator considering a district heating access right can point to a live, machine-readable network of AAS-enabled nodes with standardized data and a defined physical interface, the case for the legislative step is not theoretical. It is operational. And the heat that cannot be absorbed by any network — the low-temperature thermal remainder below any district heating minimum — still has somewhere to go. Interview VII asks how far.

The socket is defined. The data layer is being built. The dispatch algorithm is borrowed from power grids and applied here for the first time. The contract template is the gap — and every other commodity market solved it before the market could exist.  —  Interview VII, The Exhaust, takes the heat the network cannot absorb and asks what happens at the limit.
Coming next  ·  Interview VII
The Exhaust
Every thermal network has a floor. Below a threshold temperature, no district heating network accepts the heat. Too cold for industry, too diffuse for agriculture, below the minimum grade for any thermal interface. Interview VII asks what happens at that floor — and finds that the atmosphere itself has an answer. Passive radiative cooling to deep space, through the atmospheric transparency window between eight and thirteen microns, requires no moving parts, no power, and no working fluid. The exhaust valve is the roof. The heat sink is outer space. And the infrastructure to connect them is a coating on a surface that already exists.
Passive radiative cooling PDRC Atmospheric transparency window Sub-ambient cooling Thermal rejection Zero-power cooling