10 Operational intent§
AGREED Intent is decomposed rather than composite, and Sequence sits outside it. Both differ from the earlier technical specification; see Decision Record D-1 and D-2.
10.1 Why intent is modeled separately§
A building has three tenses. What it is meant to do. What it is doing. What it did. Systems routinely store the first inside the third — an intent becomes a setpoint value in a database, indistinguishable from any other stored number — and when the system is replaced, the intent is what does not survive.
Modeling intent separately is what lets a receiving system answer the question an operator asks in the first week: not what is this value, but what was this supposed to achieve.
10.2 The intent classes§
| Class | What it carries |
|---|---|
bus:Objective | What is to be achieved, its rationale, a category, and a priority. Prose, deliberately. |
bus:Target | A quantified expectation attached to a point or quantity kind: a value or range, a tolerance, a condition, and a schedule reference. |
bus:Constraint | A limit that holds regardless of objectives, with a constraintKind of safety, limit, deadband, interlock, regulatory, warranty, or operational. |
bus:Schedule | When intent applies. Segments carry an [RFC5545] recurrence rule, local clock bounds, and a value. Exceptions carry explicit dates. |
Each is separately addressable, which is what makes it possible to say twenty years later that this specific target was relaxed on a date, by a person, for a reason. A composite intent object is easier to author and blurs exactly that audit trail; authoring convenience is a tooling problem and addressability is not.
bus:Objective is prose because objectives are not reducible without loss. The rationale field carries what a later engineer most needs and most rarely gets: why the number is what it is.
10.3 Sequences§
bus:Sequence is the logic that implements an intent, connected by bus:implements. It is not part of intent. A sequence names the language it is written in — prose, ashrae-231-cdl, ashrae-guideline-36, iec-61131-3, iec-61499, sedona, niagara-wiresheet, function-block, vendor — and carries either inline source or a resource reference. The vocabulary is open per 7.5: an unlisted token is valid and MUST be preserved.
NOTE ANSI/ASHRAE Standard 231-2026, Control Description Language, published February 2026, is the first citable machine-readable form for control sequences. It is design-time: it describes what logic should be, not what a deployed controller is running. BUS-1 references sequences rather than extracting them for that reason, and extraction remains open (Annex E).
10.4 Constraints and safety§
A constraint MAY carry a machine-readable expression, which MUST name its language. This standard does not define an expression language and does not require a receiver to evaluate one. Naming the language is what lets a receiver decide honestly whether it can.
Constraints are also referenced from write bindings (13.7), so that a limit enforced at the graphic is the same limit recorded in the model rather than a second copy that will diverge.
10.5 Design intent and deployed logic§
PROVISIONAL New in v0.3. The envelope is specified. Extraction is not, and Annex F.1 keeps it as an open gap.
A sequence in a package is one of two very different things, and through v0.2 there was no way to say which. It is either the sequence of operation from the submittal — what the building was specified to do — or it is what the controller is actually running.
Those two diverge, and they diverge in the direction nobody documents. An override becomes permanent. A loop is retuned during a hot week. A vendor patches a program on site at two in the morning and writes nothing down. Ten years later the submittal is a description of a building that no longer exists, and it is indistinguishable in a package from a description of one that does.
Which of the two a sequence is, is the single most valuable fact about it in a migration, and it was inexpressible.
10.5.1 The deployment block§
bus:Sequence carries an OPTIONAL deployment block. Where it is present, state is REQUIRED.
| Field | Requirement |
|---|---|
state | REQUIRED. asDesigned — from the specification, submittal, or design intent. asDeployed — extracted from the controller that runs it. unknown — the exporter cannot tell. |
controllerRef | RECOMMENDED where the state is asDeployed. The bus:Asset that executes the program. |
programIdentifier | RECOMMENDED where the state is asDeployed. How the controller names the program. Opaque, and preserved verbatim. |
extractedAt, extractedBy | RECOMMENDED where the state is asDeployed. When the logic was taken off the controller, and by whom, as an agent per 14.1. |
checksum | OPTIONAL. A digest of the program as extracted, so that a later export can be compared against this one without the controller being available. |
"deployment": {
"state": "asDeployed",
"controllerRef": "urn:uuid:...053",
"programIdentifier": "AHU1_ECON_v7",
"extractedAt": "2026-06-18T14:02:00-05:00[America/Chicago]",
"extractedBy": { "kind": "system", "name": "busref 0.3.0" },
"checksum": { "algorithm": "sha-256", "value": "9f2c..." }
}Without the second of those, an exporter can be technically conforming and materially false. It ships the submittal’s control description, declares intent complete, and the receiving system is told the building runs logic it stopped running in 2019. Nothing in the package is untrue on its face and the whole of it is misleading. This is the same failure 7.8 was written to close for properties, appearing again one clause over.
10.5.2 What this version does not do§
v0.3 does NOT define control-program extraction, and it does NOT define a control language.
There is no prior art to follow. Project Haystack 4.0.0 has no sequence, program, or control-logic construct anywhere in its 719 defs; Brick 1.4.4 has none in its 1,433 classes. The nearest constructs in either model describe what produced a value, not what logic runs the plant. ANSI/ASHRAE 231-2026 is design-time by construction — it describes what logic should be — and IEC 61131-3 is a programming standard, not an exchange format for a program already running in a controller. Annex F.1 is right that extraction has no precedent in any standard, and a specification that invented one here would be guessing in public and asking implementers to pay for the guess.
What v0.3 does instead is make the gap visible and measurable. A package can now say that its sequences are design intent, or that nobody knows, or that a named agent read a named controller on a date and here is the digest of what came back. An owner can count how many of their sequences are asDeployed. That number is unknowable today, and it is the number that decides whether a migration is a transcription or a re-engineering.
NOTE The language vocabulary was extended in the same pass, with the formats a deployed program is actually held in rather than the formats a design is written in. Naming the format is not reading it; it is what lets a receiver decide honestly whether it can. The full token list is in 10.3.
10.5.3 Explicit non-goal and opaque attachment§
BUS-1 does not define extraction of proprietary controller programs, and does not define a control language. A sequence carrying state asDeployed asserts exactly this much: an agent read a named controller on a named date and obtained a program whose checksum is recorded. It does not assert that any receiving system can execute, interpret, or diff that program, and a reader who takes the deployment block as a claim that extraction is solved has been misled by nothing in this document.
An exporter MAY attach the opaque program bytes, or a resource reference to them, under the existing resource mechanism — together with the language token 10.3 already requires and the checksum in the deployment block. The attachment is a byte-preserving convenience for the integrator who must re-commission; it is not a portable semantic representation of control logic. A receiver that cannot interpret the language token MUST still preserve the resource and the deployment metadata, which is 2.4 applied and not a new obligation.
This subsection does not close the extraction gap recorded in Annex F.1. It fixes the boundary of what is claimed, and provides a non-destructive place for later standards or vendor tools to land extracted artifacts without breaking the reconstruction guarantee.
Promotion criterion — packages from at least two controller platforms emit `asDeployed` with checksum, and the distinction survives a third-party import.