A team proposes a digital-twin platform for 20,000 HVAC units: every sensor reading and every attribute change written to an event-sourced graph database with full per-attribute version history, a rules engine evaluating 400 conditions per device per minute, and a 3D visualisation of each site. The goal is "predictive maintenance and remote diagnostics". Review it. What would you remove, what would you change, and what would you leave alone?

What is actually required

Strip the proposal to the outcomes someone will be judged on: a technician arrives with the right part, and an engineer can answer what a unit was doing before it failed without a site visit. Both need three capabilities: the unit's current reported state, its desired state with the gap between them, and enough recent history to see a trend. Nothing in that list requires a graph, event sourcing, or 3D.

What I would remove, and why it is safe to

• The graph database. Twin state for HVAC is a shallow hierarchy — site, unit, component, reading — which relational tables model with less operational risk, and the query that matters is "one unit over a time range", which is a time-series access pattern, not a traversal. Keep a graph only if there are queries that genuinely traverse arbitrary depth, and there are not.
• Per-attribute full version history. 20,000 units x 400 attributes with every change retained is a storage growth curve nobody has budgeted, and nobody will read it. Replace with: current state, plus a change log of commanded changes (who set what, when — the audit question that does get asked), plus downsampled telemetry with a stated retention.
• The 3D visualisation. It photographs well and it is not on the path to either outcome. It also fixes the data model early around geometry, which is expensive to change later.
• 380 of the 400 rules. Each rule is an alert that a human must eventually triage. Start with the ones tied to a known failure mode with a known action, and add a rule only when someone commits to owning its output.

The one change that matters

Make staleness explicit in the model. A twin is a cache of a physical object, and the mistake that ruins these platforms is presenting a value without its age, so an operator looks at a dashboard reading from a unit that stopped reporting yesterday and concludes it is fine. Every field carries its observation timestamp, the UI renders age, and a unit that has not reported within its expected interval is a state, not an absence. The corollary is the alert that most fleets lack: not "a device reported a bad value" but "a device stopped reporting".

What I would leave, even though it looks odd

• The reported-versus-desired split, which is the one genuinely good idea in the proposal. Storing desired state rather than a queue of commands is what makes an operator's two changes to an offline unit converge correctly instead of replaying in order. This is the shape device shadows have had in the major IoT platforms since 2015, and it is worth keeping because it is the part that survives contact with a fleet that is offline half the time.
• A rules engine rather than hard-coded thresholds. Thresholds change per site and per season, and a service engineer should be able to change one without a firmware release.
• The event-driven ingest path. It is the right shape for telemetry even though the event-sourced storage is not.

How I would argue this in the review

Not as "this is over-engineered", which invites a defence of each part. Ask what the first predictive-maintenance model will actually be trained on, and the conversation moves to data quality and labelled failures, which is where the difficulty really lives: you need records of units that failed and what preceded them, and most fleets have a few dozen labelled failures rather than the thousands a model needs. Then offer the trade: ship current state, gap, downsampled history at 90 days of retention and 20 rules in one quarter, and use the year of data that produces to decide whether the graph was ever needed. The proposal's cost is not the infrastructure, it is the twelve months before anyone gets a usable answer.

When not to remove any of it

If the fleet is 200 units of safety-critical equipment under a regulatory duty to reconstruct any historical state, the full per-attribute history stops being waste and becomes the requirement, because an auditor's question is exactly "what did this unit believe at 14:02". Choose retention from the question someone is obliged to answer, not from the volume you can afford.