Where should a frequently-updated, per-asset operational value live in the core data model? (replacing what the classic asset metadata bag did)

What we need, and why it is per-asset.

We ingest from OPC-UA. One extraction pipeline serves a production line carrying several machines. The PLCs publish on change, so a tag going quiet is completely normal — and from the data alone it is indistinguishable from the source having stopped.

Our calculations forward-fill. So before forward-filling a value we have to know up to what point it is safe to do so: the last moment we know that machine was actually reporting. That is a property of the machine, not of any individual time series — every tag on a machine shares the same liveness — so what we need is one current value per asset, kept up to date continuously and read on every calculation.

How we did it with classic resources. We wrote a Last Synchronized key into the classic asset's metadata bag. One small write per asset per cycle, and it cost nothing against data-modelling limits.

Why this is awkward in the core data model. CogniteAsset has no free-form property — none of its 23 properties is key/value or JSON. So we authored our own container with a JSON property and published a new version of our asset view, and we write to it ourselves. That works, but it converts a cheap non-data-modelling write into a data-modelling write, at a cadence data modelling does not look designed for: ~205 asset nodes rewritten every five minutes, roughly 77 000 instance writes per day, each carrying a single timestamp.

The obvious alternative is worse. Every machine already publishes a Watchdog tag, so a per-machine heartbeat time series already exists, and we could read liveness from there instead of from the asset. Two problems with it. It is still a data-modelling operation — in the core data model a CogniteTimeSeries is itself an instance, addressed by instance id. And setting the accounting aside entirely, it would mean that every time series read has to be paired with a second read of that machine's heartbeat series, purely to learn how far the first one may be forward-filled. 

So we would like your advice. Where should a per-asset operational value live when it changes every few minutes and is read by every calculation? And the general version of the same question: when a classic resource carrying a metadata bag is migrated to the core data model, where is that metadata meant to live for assets? We would much rather adopt the recommended pattern than keep extending our own schema around the gap.