Context is the information that makes a reading or model output meaningful for a particular physical system. A sensor value alone cannot tell a digital twin whether a condition is normal, dangerous, or worth acting on. The twin must connect readings to the equipment, operating rules, history, and other data streams relevant to the decision. section 5.2 section 3.1
The same reading, two decisions
A reading of 85°C is normal for a furnace whose specified operating temperature is 85°C. For a cooling pump with a 70°C maximum, it is a critical alert. Diagnosing the pump also requires linking the sensor to its specifications, piping diagrams, and maintenance records—information often scattered across separate systems. section 5.2
Four kinds of context help make those links:
- Spatial context places an entity at a location or relative to other objects. section 5.2.1
- Temporal context attaches a time and history, revealing trends rather than isolated values. section 5.2.1
- Relational context identifies connections such as which valve controls a pipe or which schedule applies to a pump. section 5.2.1
- Physical context places components within assemblies, such as a sensor within an HVAC unit, room, and building. section 5.2.1
Figure 5.4 An example of how raw data produced by a moisture sensor in my garden can be contextualized with temporal, spatial, physical, and relational context
The garden moisture example combines a falling reading with sensor location, sprinkler connections, and shared watering rules to identify a specific action. section 5.2.1
Building context is a knowledge-engineering task, not simply a matter of adding sensors. Specifications and records may be disconnected, while experienced operators hold useful patterns that were never documented. Human observations can fill gaps: a manual pool test can record water clarity and debris alongside its numerical reading. Consistent collection matters if those observations are to remain useful. section 5.1.2 section 3.4.3
Context also conditions generated answers. A general-purpose language model cannot reliably know a particular pump’s specifications or maintenance history. Supplying current and historical twin data can ground an equipment-specific answer and support analysis such as comparing vibration with operating hours and a maintenance schedule. section 5.2.3
In production, retain the context behind decisions as well as the context used to make them: input values and timestamps, model versions and parameters, rules, and resulting actions. Without that trail, an unsafe recommendation is difficult to attribute to bad data, a model change, a policy override, or an automated action. section 10.5.4
{
"specversion": "1.0", #1
"id": "5c7c25c6-9328-4942-887e-892a096328a3",
"type": "com.home.twin.command.irrigation",
"source": "/digital-twin/models/soil-v2",
"time": "2026-01-15T13:05:00Z",
"datacontenttype": "application/json",
"data": { #2
"command": {
"action": "activate_zone",
"zone": "front_garden",
"duration": 15
},
"context": {
"soil_moisture": 85.0,
"rain_prob": 0.05,
"temperature": 35,
"cloud_cover": 75,
"humidity": 21
},
"governance": { #3
"status": "DENIED",
"reason": "Soil moisture > 80%",
"policy": "data.digital_twin.irrigation.allow_operation"
}
}
}
This command event records an irrigation request, its sensor context, and a governance denial, making the attempted decision inspectable. section 10.5.4
