12 Events§

AGREED New in v0.2. An event is not a time-series sample and does not belong in the deferred history domain.

12.1 What an event is§

A bus:Event is a timestamped occurrence attached to a subject: an alarm raised, cleared, acknowledged, or shelved; an override applied or released; a mode change; a command; a setpoint change; a service action; a commissioning activity; a fault; a configuration change; an outage.

The subject is intrinsic. An event without a subject is meaningless, so unlike ordinary contextual facts it is carried on the entity rather than as a relationship (5.3.1).

12.2 Why events are core§

Folding events into time-series history and deferring both would mean the core cannot express the sentence that matters most in a migration: someone overrode this in 2019 and never took it out. That fact appears on no drawing, in no database field, and in no tag. It is precisely the class of understanding this standard exists to preserve, and it is cheap to carry because events are sparse where trend data is dense.

{ "type": "bus:Event",
  "eventKind": "override",
  "subject": "urn:uuid:...067",                    // VAV-2-01 damper command
  "at": "2017-05-09T11:20:00-05:00[America/Chicago]",
  "by": { "kind": "person", "name": "D. Okafor", "partyRef": "urn:uuid:...004" },
  "priorValue": 18.0, "value": 24.0, "priority": 8,
  "message": "Minimum damper command raised to 24 percent to clear the binding band.
              Override left in place deliberately; see KN-AHU1-OAD." }

12.3 Completeness§

An event log is rarely complete and completeness is not required. An exporter carrying a subset MUST declare the events domain as partial with a reason (16.6). A partial event history is materially better than none, and a standard demanding completeness here would be widely ignored.

An importer MUST preserve an event’s subject reference. An override event that loses its subject is a failure (test RT-23), because it becomes an anecdote rather than a fact about a point.