magnus919_agent-skills/semantic-spacetime/references/applications-infrastructure.md

Applications in Infrastructure — CFEngine, Convergence, and the Descendant Ecosystem

Load this file when you need the empirical record behind Semantic Spacetime (SST): what the convergence/promise line actually did in thirty years of real infrastructure — CFEngine's mechanism set, the declarative-IaC / Kubernetes / GitOps / IBN / MAPE-K descendants that each inherited a piece of it, the time-and-space machinery (Lamport causality, event sourcing, bi-temporal records, versioned data namespaces) SST's line implies, and the distilled, citable lessons for designing convergent systems.

What belongs here: the infrastructure history and its lessons — CFEngine, the descendant ecosystem, "dynamics always trumps semantics," SLOs as semantic contracts, promise-keeping-as-data, and the record-of-time layer (event sourcing, bi-temporal axes, arXiv:2204.00470). What does not belong here: the formal SST model itself (definitions, γ(3,4), proper time, the promise substrate — see foundations.md); agent-team coordination and the agentic-AI literature (see agent-coordination.md); named design patterns (see patterns.md); and the diagnosis procedure (see diagnosis-and-debugging.md). Where promise-level machinery is involved (promise, offer/acceptance, assessment, convergence mechanics), this file links to promise-theory rather than re-teaching it.

Provenance. Every factual claim below carries exactly one marker: [VERIFIED] (confirmed in a primary source fetched during the research phase; source named), [UNVERIFIED] (secondary, opinion, or inferred; reason named), or EXTRAPOLATION (this skill's own synthesis, explicitly labeled). Do not drop markers when reusing this content.

---

1. The lineage at a glance

The SST line has a concrete, traceable industrial ancestor. CFEngine was written by Mark Burgess in 1993 at the University of Oslo, initially to automate workstation management [VERIFIED — CFEngine Wikipedia; InfoQ CFEngine article]. Its core ideas — convergence to a desired end-state, classes, promises as the unit of policy, the immunity model of self-repair, and compliance measured by the repair loop itself — are the same ideas SST later formalizes as a graph model of meaning over time. The interpretive framing that "CFEngine is the working prototype / reference implementation of the SST/promise-theory line" is this research phase's own synthesis, not a claim in any cited source [EXTRAPOLATION — research synthesis, infrastructure-applications report §1]. It must not be read as "CFEngine was built from SST": CFEngine (1993) predates Promise Theory (~2004–05, first presented at DSOM 2005) and SST (2014, arXiv:1411.5563) by a decade or more [VERIFIED — CFEngine Wikipedia; academic foundations]. What the lineage claim means is the reverse: SST formalizes, with time and semantics added, the machinery CFEngine already ran in production.

The mechanism set itself is well documented and tagged [VERIFIED] throughout §2. The industry that followed inherited the machinery piecemeal (§5), and the recurring gap is that the record of promise-keeping was never stored as data (§6) — exactly the semantic-time capability SST's versioned record axis would supply (§8).

2. CFEngine: the mechanism set (all [VERIFIED])

Sources for this section: Burgess's own A Tiny Overview of CFEngine: Convergent Maintenance Agent (markburgess.org/papers/tiny_intro.pdf), the InfoQ article "CFEngine's Decentralized Approach to Configuration Management" (2014), and the CFEngine Wikipedia article. All quotes below are from those fetched sources.

1. Convergence to a desired end-state (fixed point). A convergent operator satisfies O(q0) = q0 and O^2 = O at the desired endpoint; "idempotence requires only O^2 = O, while convergence is relative to a specific policy state q0" [VERIFIED — Burgess, A Tiny Overview]. Convergent semantics behave "like a ball rolling into a potential well"; once converged, agent action desists [VERIFIED — same source]. The Wikipedia framing adds that convergence is "now often inaccurately just called idempotence" [VERIFIED — Burgess Wikipedia].
2. Statistical convergence, never exact. "A complete specification of policy determines an approximate configuration of a software system only approximately over persistent times. There are fundamental limits to the tolerances a system can satisfy with respect to policy compliance in a stochastic environment" [VERIFIED — A Tiny Overview]. Desired state is a fixed-point attractor in a stochastic environment, not a guarantee; the approach rate is set by "the ratio of the frequency of environmental change to the rate of CFEngine execution" [VERIFIED — A Tiny Overview; On the theory of system administration via Wikipedia].
3. Classes. Promises are conditioned on classes — OS type, time, user-defined contexts — so the same policy text applies different promises under different conditions [VERIFIED — InfoQ CFEngine article; CFEngine Wikipedia]. (SST's later framing calls coarse-grained context flags "classes" too, in Burgess's knowledge-graph essays [VERIFIED — Medium, The Role of Intent and Context, 2025].)
4. Promises as the unit of policy. CFEngine 3's documentation is explicit that promises are the central concept and everything else is an abstraction for declaring them; agents on every host pull and cache policy and decide locally whether to keep it [VERIFIED — CFEngine 3 docs via InfoQ]. Policy is federated: "an agent cannot be forced into submission by an external authority" [VERIFIED — InfoQ].
5. The immunity model of self-repair. Health = policy compliance, deviation = sickness, and repair is modeled as error correction over a noisy channel in Shannon's sense — the "Computer Immunology" (1998) manifesto for self-healing systems [VERIFIED — LISA98 Computer Immunology; A Tiny Overview]. Independent convergent operations commute: "multiple orthogonal, convergent operations will always lead to the correct configuration, no matter which part of the configuration is incorrect, or in what order things occur"; failed steps can be repeated later [VERIFIED — A Tiny Overview].
6. The default 5-minute repair loop. Agents "verify whether these promises are kept (and usually takes measures to keep them) every five minutes, by default" [VERIFIED — InfoQ CFEngine article].
7. Compliance without independent monitoring. CFEngine yields "immediate and continuous measurements of compliance based on a documented model of intent, without the need for independent monitoring" [VERIFIED — InfoQ CFEngine article].

Two further CFEngine-era lessons matter for SST: (a) the "congruence" alternative — destroy-and-rebuild, proposed by S. Traugott — versus convergent repair; Burgess's rebuttal was that "only the convergent approach can be used for realtime maintenance" [VERIFIED — A Tiny Overview]. (b) Burgess's 2014 stance that "immutability" is "politics, not science," preferring "disposable computing — throw away a broken process rather than trying to fix it" [VERIFIED — InfoQ, In Search of Certainty review/interview]. Both debates re-ran later in containers and immutable infrastructure.

3. "Dynamics always trumps semantics" — meaning requires measurement

The single most load-bearing lesson for SST practitioners: "It is not possible to reason about semantics without taking into account the underlying dynamics" [VERIFIED — InfoQ, In Search of Certainty book review and interview, 2014]. Meaning cannot be asserted before the dynamics are measured. The corollary is that measurement must happen at the right scale: "the ability to distinguish and separate scales is closely allied with our notions of simplicity," and different scales yield contradictory measurements — a system can look healthy at the requests-per-second scale while its disks are filling and its semantics (as users experience them) are degrading [VERIFIED — same source].

This is the operational form of SST's measurement duality (spacelike ensemble vs. timelike cognitive measurement) developed in foundations.md §7; the infrastructure phrase is the earlier, engineering-tested statement of the same rule. Practically: any SST analysis that reasons about meaning without an explicit measurement plan (what to observe, at what scale, how often) is guesswork.

4. SST's time lineage: Lamport causality, event sourcing, bi-temporal records

SST descends from Lamport's causal time. Lamport's 1978 "Time, Clocks, and the Ordering of Events in a Distributed System" (CACM 21(7):558–565) establishes that "there is no invariant total ordering of events in space-time… there is only a partial order in which an event e1 precedes an event e2 iff e1 can causally affect e2" [VERIFIED — Lamport via Microsoft Research]. Burgess explicitly places SST in this line: "The view of time as a relative transition system goes back to the work of Leslie Lamport… time can at best be understood as a precedence relation, in a discrete spacetime context" [VERIFIED — markburgess.org, Semantic Spacetime — What is it?]. Wall-clock time is not the ordering primitive; causality is. This section is SST's semantic-time territory, not a promise-theory restatement: the promise machinery of offers and acceptances lives in promise-theory.

Two further record-of-time mechanisms belong to the same lineage:

• Event sourcing (Fowler, 2005): "capture all changes to an application state as a sequence of events" — enabling complete rebuild by replay, temporal query of state at any point in time, and event correction [VERIFIED — martinfowler.com, Event Sourcing]. Fowler's documented caveat: external systems "don't know the difference between real processing and replays," so gateways must be replay-aware and external queries must be logged; temporal corrections lead to "bi-temporal behavior" and "this stuff can get very messy, don't go down this path unless you really need to" [VERIFIED — same source]. Event logs are the honest time dimension of state: semantic correctness over time (what did we believe when) requires recording both fact and belief.
• Bi-temporal databases: a temporal database tracks valid time (when a fact is true in the real world — the world axis) and transaction time (when it was recorded — the record axis), optionally decision time; "historical information… is provided by the valid time. Rollback… is provided by the transaction time" [VERIFIED — Temporal database Wikipedia]. The two answers can differ: "the database may have been altered since 1992" [VERIFIED — same source]. SQL:2011 adopted a reduced version (application-time period tables, system-versioned tables); the richer TSQL2 proposal was killed in committee after criticism by Date and Darwen [VERIFIED — same source].

The lesson for SST: any "state over time" system must separate the world axis from the record axis. Conflating them is the classic audit failure, and — as §6 and §8 show — it is precisely the axis SST's promise-keeping capability supplies.

5. The descendant ecosystem: who inherited what, and the gap each leaves

Each descendant below is stated with its inheritance mechanism and its gap/lesson, all from the fetched sources named.

5.1 Declarative IaC — Terraform, Ansible, Chef, Puppet, Nix

• Terraform: declarative config; plan diffs desired configuration against actual state; apply executes; drift is "when the real-world state of your infrastructure differs from the state defined in your configuration" [VERIFIED — HashiCorp, "Detecting and Managing Drift with Terraform"]. The state file maps config to real resources; refresh reconciles before every plan/apply; lifecycle flags tune reconciliation [VERIFIED — same source]. Gap: Terraform is invoked, not a loop — "Terraform cannot detect drift of resources… that are not managed using Terraform" [VERIFIED — HashiCorp]. The sharper 2026 reading — "terraform plan diffs one file against another file. It does not observe your infrastructure. Between applies, Terraform has no awareness" — is opinion, marked [UNVERIFIED — webframp.com, 2026]. A state file is memory of a past action, not perception; drift accumulates until a human runs the tool.
• Ansible: idempotent modules — "most Ansible modules check whether the desired final state has already been achieved and exit without performing any actions if that state has been achieved" [VERIFIED — Ansible docs]; control node pushes tasks over SSH; --check previews; ansible-pull "inverts the Ansible architecture so that nodes check in to a central location instead of you pushing configuration out to them" [VERIFIED — Ansible docs]. Gap: default mode is push/command-and-control; the target has no daemon, no local reasoning, no self-assessment. Module-level idempotency is a local, weaker cousin of convergence; without scheduled local evaluation, drift between runs is invisible — Ansible's own docs warn "not all playbooks and not all modules behave this way" [VERIFIED — Ansible docs].
• Chef and Puppet: pull-based agents on a schedule, converging toward declared state and reporting back [UNVERIFIED — the ~30-minute Chef default and "blind outside declarations" details come from the webframp analysis, not from official docs fetched in this research]. The agent-observation-scoped-to-declaration point — "if you did not write a resource for it, the agent does not see it" — is [UNVERIFIED — webframp.com, 2026; consistent with verified pull-based mechanisms].
• Nix / NixOS: "purely functional package manager" — builds without side effects, immutable content-addressed store, atomic upgrades and rollbacks; NixOS builds "the entire operating system… from a description in a purely functional build language" [VERIFIED — nixos.org]. Gap: deterministic builds ≠ deterministic running state — even NixOS exempts "mutable state (such as the stuff that lives in /var)" [VERIFIED — nixos.org]. Nix realizes the end-state purity extreme — eliminating stochastic repair by making state immutable and rebuildable — closer to Traugott's destroy-and-rebuild "congruence" than to CFEngine's convergent repair [interpretive framing].

5.2 Kubernetes: reconciliation controllers as institutionalized convergence

Kubernetes controllers are "control loops" that watch state and "try to move the current cluster state closer to the desired state"; the thermostat is the canonical example [VERIFIED — kubernetes.io/docs/concepts/architecture/controller]. The inheritance mechanism is the same fixed-point metaphor as CFEngine's ball-in-potential-well: spec = desired state, controller loop = the map applied repeatedly. The gap doctrine is explicit: "potentially, your cluster never reaches a stable state. As long as the controllers… are running and able to make useful changes, it doesn't matter" [VERIFIED — kubernetes.io]. "Controllers can fail, so Kubernetes is designed to allow for that" [VERIFIED — same source]. Lesson: design simple, separable, fail-tolerant reconcilers and assume convergence never "finishes."

5.3 GitOps: the closest industry instantiation of "the promise as data"

GitOps (coined by Weaveworks, 2017) per CNCF: (1) the whole system is declarative; (2) the canonical desired state is versioned in Git; (3) changes apply automatically; (4) software agents continuously reconcile and alert when reality diverges — "software agents also help ensure that the whole system is self-healing" [VERIFIED — CNCF, GitOps 101]. Interpretive framing: GitOps is the closest the industry built to storing the promise as data — intended state durable, versioned, diffable, time-ordered (git history is a temporal log of intent), with the reconciling agent as promise-keeper [interpretive — labeled, not verified as a claim in the source]. "You won't achieve immediate deployment or reconciliation until you achieve a new canonical state"; the repo is the contract and drift becomes a first-class, auditable condition [VERIFIED — CNCF]. Mark the "promise as data" reading [UNVERIFIED] as an interpretive gloss unless separately sourced.

5.4 Intent-Based Networking: intent as a productized semantic layer

IBN (RFC 9315 lineage) defines intent as "a high-level, declarative statement" of a "desired operational or business goal without specifying the detailed method of implementation," and runs a closed loop translation → activation → assurance → optimization [VERIFIED — WashU IBN survey citing Zeydan & Turk 2020 and RFC 9315]. Architecture: three layers — Business, Intent (Knowledge/ontology + Agent + Data), Network (telemetry closing the loop); the Knowledge module "includes ontologies and models for understanding semantics" [VERIFIED — same survey]. The hard problem is assurance — "continuously validating whether the actual network behavior satisfies the intent" — and open challenges include intent-interpretation reliability, multi-domain coordination, and explainability: "today's IBN systems sometimes act like 'black boxes'" [VERIFIED — WashU survey]. Lesson: intent is only as good as its assurance loop; the semantic layer is where intent is won or lost.

5.5 MAPE-K and operators: the autonomic loop codified

IBM coined "autonomic computing" in 2001; Kephart & Chess (2003), The Vision of Autonomic Computing (IEEE Computer 36:41–50), define an autonomic manager + managed resource running the MAPE loop — Monitor, Analyze, Plan, Execute — with shared Knowledge (MAPE-K) [VERIFIED — Kephart & Chess 2003 via ScienceDirect; researchr]. The IBM blueprint's component-level details were not fetchable in the research phase and are [UNVERIFIED — IBM blueprint bibliography entry only]. CFEngine Wikipedia asserts Computer Immunology (1998) "laid out a manifesto for creating self-healing systems, reiterated a few years later by IBM in their form of Autonomic Computing" [VERIFIED — CFEngine Wikipedia]; Burgess & Couch's 2006 paper is literally titled Autonomic Computing Approximated by Fixed-Point Promises [VERIFIED — archive.org copy]. MAPE-K and CFEngine's converge-and-repair loop are independent formulations of the same monitor → compare → act cycle. Lesson: the "K" (shared Knowledge) is what makes the loop semantic; without a durable knowledge model, self-* systems repair without understanding [interpretive].

6. The most-cited gap: promise-keeping was never stored as data

The recurring critique of the whole CFEngine-to-IBN line: systems answered "is this promise kept right now?" but never stored promise-keeping as queryable data — no record of what the configuration looked like last Tuesday, how often a promise was repaired, or which hosts drifted together [UNVERIFIED — webframp.com, The Promise None of Them Kept (2026), an opinionated practitioner analysis; the current-state compliance behavior it describes is consistent with the verified CFEngine mechanisms of §2]. The framing: CFEngine's assessment "is a verdict rather than a record" [UNVERIFIED — webframp.com, 2026]. This claim is attributed to the CFEngine lineage — the opinion source analyzes CFEngine and its successors, not SST — and must not be presented as a verified fact or as an SST discovery.

In SST terms, this is the missing record axis of §4 (valid vs. transaction time) applied to promises: the world axis is the state of the system, the record axis is the versioned history of what was promised, what was measured, and what was repaired. SST's semantic-time capability — a versioned record of meaning over time — is what would close the gap, and §8 names the concrete machinery.

7. SLOs as working semantic contracts

SLOs are the operational form of "meaning over time": a promise about future measured behavior with an explicit time horizon, sitting inside a control loop [interpretive framing; the facts below are verified]. Terminology (Google SRE book, Ch. 4): an SLI is "a carefully defined quantitative measure"; an SLO is "a target value or range of values… measured by an SLI"; an SLA is an agreement "with consequences." The mnemonic: "what happens if the SLOs aren't met?" [VERIFIED — sre.google]. SLOs sit inside control loops: "SLIs and SLOs are crucial elements in the control loops used to manage systems: 1. Monitor and measure… 2. Compare… 3. …figure out what needs to happen… 4. Take that action" [VERIFIED — sre.google] — the same loop CFEngine's agent runs and MAPE-K codifies (§2, §5.5), with meaning made explicit and quantifiable. Error budgets: "it is better to allow an error budget — a rate at which the SLOs can be missed — and track that"; "an error budget is just an SLO for meeting other SLOs" [VERIFIED — sre.google]. Selection lessons (depth evidence): "keep it simple," "avoid absolutes," "have as few SLOs as possible," "perfection can wait," and "don't overachieve" — Chubby introduced planned outages because it was too available [VERIFIED — sre.google].

SST's reading: an SLO is a scalar promise with a measurement loop and a time horizon — a minimal, production-proven instance of "meaning over time." When you model a system in SST terms, your observations and drift checks are, operationally, SLOs over semantic state. For the promise-level machinery (offer/acceptance, assessment, breach), link to promise-theory rather than restating it here.

8. Time and space in systems: the versioned-record-axis machinery

The record axis of §4 needs concrete machinery. The relevant lineage, all verified:

• Lamport clocks — logical clocks imposing a total order consistent with the causal partial order, the distributed-systems backbone for "no global clock" [VERIFIED — Lamport 1978 via Microsoft Research].
• Distributed tracing — OpenTelemetry spans form a parent-child hierarchy; span links "exist so that you can associate one span with one or more spans, implying a causal relationship" [VERIFIED — opentelemetry.io]. Causality must be carried in context (trace-context propagation), not reconstructed from timestamps [VERIFIED — same source]. This is Lamport's partial-order causality made observable — the closest working analogue to SST's "timeline cognitive semantics" [interpretive].
• Event sourcing — §4, state as a function of time with replay caveats [VERIFIED — Fowler 2005].
• Bi-temporal databases — §4, world axis vs. record axis [VERIFIED — Temporal database Wikipedia].

Continuous Integration of Data Histories into Consistent Namespaces (Burgess & Gerlits, 2022, arXiv:2204.00470) is SST's own temporal-consistency scheme for data pipelines — the concrete machinery behind the record axis [VERIFIED — arXiv:2204.00470; academic-foundations report §2.2 S9]. The mechanism: "we thus establish an invariant global ordering from a spanning tree over all shards… this forms a versioned coordinate system (or versioned namespace) with consistent semantics" [VERIFIED — arXiv:2204.00470]. In other words: versioned coordinates over distributed data history give every record a stable address in time, so "what was the meaning at time T" is a query, not archaeology. This is exactly the capability VAL-APPS-006's gap (promise-keeping never stored as data) requires: a promise ledger is a namespace of versioned data histories over promises, observations, and repairs [EXTRAPOLATION — applying the versioned-coordinate scheme to promise-keeping; the paper's own framing is about data pipelines]. The Aljabr/Dianemo smart-data-pipeline lineage behind the paper is documented [VERIFIED — Wikipedia citation + arXiv reference].

9. Distilled lessons — citable

Each lesson below carries its marker and its named source; use these as the citation spine when a design conversation needs the empirical record.

1. Convergence ≠ idempotence; convergence is relative to a declared policy state. "Idempotence requires only O^2 = O, while convergence is relative to a specific policy state q0" (O(q0)=q0). [VERIFIED — Burgess, A Tiny Overview of CFEngine; Burgess Wikipedia]
2. Desired-state convergence is statistical, never exact, in a stochastic environment. "A complete specification of policy determines an approximate configuration… only approximately over persistent times." [VERIFIED — A Tiny Overview; On the theory of system administration via Wikipedia]
3. Make convergence order-free where possible; repeat failed steps. "Multiple orthogonal, convergent operations will always lead to the correct configuration, no matter which part… is incorrect, or in what order things occur." [VERIFIED — A Tiny Overview]
4. Converge for realtime maintenance; recreate if you can afford downtime. Traugott's "congruence" is the philosophical opposite; "only the convergent approach can be used for realtime maintenance." [VERIFIED — A Tiny Overview]
5. Continuous promise evaluation yields compliance measurement for free. "Immediate and continuous measurements of compliance based on a documented model of intent, without the need for independent monitoring." [VERIFIED — InfoQ CFEngine article, vendor-authored but primary]
6. Autonomy and weak coupling survive scale; strong coupling transmits failure. Centralization is "the first idea people come back to" but propagates Byzantine failures. [VERIFIED — InfoQ CFEngine article; Burgess interview]
7. Autonomy without memory = a verdict, not a record. CFEngine could say whether a promise is kept now, not what changed when or how often it was repaired, because "promise-keeping was never stored as data." [UNVERIFIED — webframp.com 2026, opinion source]
8. Dynamics trumps semantics — measure first, then attach meaning. "It is not possible to reason about semantics without taking into account the underlying dynamics"; scale changes what you can conclude (steady RPS vs. full disks). [VERIFIED — InfoQ, In Search of Certainty review/interview]
9. Model time as causality, not wall clocks. Lamport: "only a partial order in which an event e1 precedes an event e2 iff e1 can causally affect e2." OpenTelemetry span links "implying a causal relationship" are the productionized form. [VERIFIED — Lamport via Microsoft Research; opentelemetry.io]
10. Separate "world" time from "record" time in any state-over-time store. Bi-temporal modeling (valid vs. transaction) is what makes audit and rollback coherent; SQL:2011 supports a reduced form. [VERIFIED — Temporal database Wikipedia]
11. Event sourcing gives time-travel state; gate external side effects. Replays must not re-fire external messages; external query answers must be recorded. [VERIFIED — Fowler, Event Sourcing]
12. Reconciliation loops should assume they never "finish." "Potentially, your cluster never reaches a stable state. As long as the controllers… are running and able to make useful changes, it doesn't matter." [VERIFIED — kubernetes.io]
13. If a declarative tool is invoked rather than looping, drift accumulates silently. Terraform detects drift only when a human runs plan/refresh; it "cannot detect drift of resources… not managed using Terraform." [VERIFIED — HashiCorp] (the "blind between applies" framing is [UNVERIFIED — webframp.com])
14. Version your intended state; that makes drift auditable and recovery reproducible. GitOps's canonical-desired-state-in-git, enforced by converging agents, is the industry's best institutionalization of "the promise as data." [VERIFIED — CNCF GitOps 101; the "promise as data" gloss is interpretive]
15. Intent is only as good as its assurance loop. IBN's closed loop (translation → activation → assurance → optimization) and the finding that today's IBN systems "act like black boxes." [VERIFIED — WashU IBN survey]
16. SLOs are the operational form of semantic contracts. They sit inside control loops (monitor → compare → act), carry error budgets, and their selection rules ("few SLOs," "avoid absolutes," "perfection can wait") are the art of turning meaning into measurement. [VERIFIED — Google SRE book Ch. 4]
17. Causality must be carried in context. Distributed causality cannot be reconstructed later from timestamps alone. [VERIFIED — opentelemetry.io]
18. Versioned coordinates over data history make "meaning at time T" a query. "We thus establish an invariant global ordering from a spanning tree over all shards… this forms a versioned coordinate system (or versioned namespace) with consistent semantics." [VERIFIED — Burgess & Gerlits, arXiv:2204.00470]

10. Status and limits

Two honest disclosures apply to everything in this file. First, the theory behind it is semi-formal and deliberately unrefereed: Burgess published the SST series as self-published notes ("I have no interest or intention of seeking to publish any of this work beyond making these notes available seeking trusted review"), with some proofs left to the reader [VERIFIED — markburgess.org]. Use the SST lens here as a reasoning aid, not a proof system. Second, several market-level claims in the descendant literature could not be verified: CFEngine's market decline has no authoritative post-mortem (only Burgess's own "reached its limits as a tool in the mid 2000s" [VERIFIED — InfoQ interview] and the 2017 Northern.tech rename [VERIFIED — Wikipedia]); Chef/Puppet defaults and the CFEngine-vs-successor comparisons rest on opinion or vendor sources [UNVERIFIED]. Where a claim in this file is labeled [UNVERIFIED] or [interpretive], treat it as a hypothesis to test, not a fact.

Sources and routing

The full annotated source list with URLs is in bibliography.md. Key sources for this file: InfoQ CFEngine article and In Search of Certainty review/interview; Burgess, A Tiny Overview of CFEngine (tiny_intro.pdf); markburgess.org (Semantic Spacetime — What is it?); Lamport 1978 (Microsoft Research); martinfowler.com (Event Sourcing); Temporal database Wikipedia; kubernetes.io (Controllers); HashiCorp (drift); Ansible docs; nixos.org (How Nix Works); CNCF (GitOps 101); WashU IBN survey; RFC 9315; Kephart & Chess 2003; sre.google (SLO chapter); opentelemetry.io (Traces); webframp.com (2026, opinion); Burgess & Gerlits, arXiv:2204.00470. For the promise vocabulary used in §2–§7 (promise, offer/acceptance, assessment, breach), load promise-theory and its applications-infrastructure reference; for the formal SST model, foundations.md; for patterns, patterns.md.