This wasn't a conscious architectural decision. It was a gut feeling that turned out to be correct — the kind of instinct that only makes sense to articulate forty years after the first instance of the pattern.
A declarative specification describes what a system should be. A deterministic runtime interprets that specification and produces behavior. The author writes the spec; the runtime handles the execution. The two halves are separate by design — you can reason about each independently.
This pattern is 40 years old in this career. It appeared first in 1985. It reappeared in 2025. The machinery is completely different. The architecture is identical.
At Teknowledge, the work was knowledge engineering on Xerox Lisp Machines running Interlisp-D. The stack:
| Role | Component |
|---|---|
| Specification | Knowledge base — facts, rules, heuristics encoded in Oyster objects |
| Runtime | Inference engine — EMYCIN / S.1 / M.1 shells that interpreted the KB |
| Author | Knowledge engineer — encoded domain expertise, not algorithms |
| Environment | Interlisp-D — live, inspectable, everything observable at runtime |
The discipline was explicitly not procedural. You didn't write "do this, then do that." You described what was true, what rules applied when, and what conclusions followed. The inference engine handled the rest. The knowledge base was the spec. The shell was the runtime.
The live environment mattered too. Interlisp-D let you inspect the system's state at any point — walk the inference chain, see what rules fired, observe what was true. The specification and the runtime were both fully visible.
Forty years later, the YAML-driven UI platform:
| Role | Component |
|---|---|
| Specification | YAML spec — state, elements, actions declared in a single document |
| Runtime | Juris — parses the YAML, manages state, drives UI updates |
| Author | Spec author — describes behavior declaratively, not imperatively |
| Environment | Proofs mode — live, inspectable, state panel + action log + annotated YAML visible at runtime |
The discipline is again explicitly not procedural. You don't write DOM manipulation. You declare what state exists, what elements respond to it, and what actions change it. Juris handles the rest. The YAML spec is the spec. Juris is the runtime.
Proofs mode is Interlisp-D. The observation that "the probabilistic part stays in the authoring phase; once the YAML is fed in, the runtime is deterministic and fully observable" is the same design philosophy that made Interlisp-D the right platform for expert systems: you can always see what the system is doing and why.
The connection runs deeper than spec-and-runtime. Expert systems were built on production rules: IF conditions THEN actions. A rule fires when its conditions match the current state of the knowledge base.
The action–state pattern:
actions:
incrementCounter:
type: setState
target: clickCount
value: "{{clickCount + 1}}"
This is a production rule. When the action fires, it evaluates conditions against current state and produces a state transition. The event bus is the working memory. The actions are the rule set. The state store is the fact base.
The action–state pattern wasn't derived from production rule systems — it emerged from front-end architecture. But the structural isomorphism is exact.
The YAML platform wasn't designed by saying "I'll apply knowledge engineering principles to UI." It was designed by recognizing — instinctively, before the reasoning caught up — that a declarative spec with a deterministic runtime was the right shape for the problem. The reasoning came later. The instinct came from 1985.
This is what forty years of pattern recognition looks like. The surface changes — Lisp machines to React, EMYCIN to Juris, Oyster objects to YAML — and underneath, the same structure keeps being the right answer. Not because it was planned. Because the problem didn't change.
This slug exists because the connection was tacit until April 2026 — never explicitly stated, only lived. The graph had no edge from the vault's AI-history cluster to the research cluster because the argument had never been made out loud.
Now it has been. The vault and the research cluster are the same work, separated by forty years.