Abstract
The preceding papers in this series define a formal system for behavioral ontology specification 1, develop its algebraic structure 2, examine the computational power of its expression language 3, and formalize the relationship between specification and interpreter 4. All four treat the Dynamic Behavioral Ontology (DBO) as the highest-level artifact in the formal system. But a DBO specifies how a system behaves — not what it is for. The purpose that motivated the specification — the teleological intent — exists only transiently: it is the natural-language request consumed during construction and then discarded. The running system holds its behavior but not its reason for behaving. This paper proposes making teleological intent a stored, first-class, stratified layer that sits above the DBO. It defines three strata of intent — Identity (what the system essentially is), Guardrails (what it must never violate), and Goals (what it must achieve) — stratified by mutability: Identity and Guardrails are immutable; Goals are mutable. It defines a purpose-anchored self-modification loop in which a system re-authors its own DBO to pursue its stored Goals while being unable to violate its immutable strata. And it confronts honestly the fundamental limit of this approach: the irreducible gap between mechanical verification and true fidelity to the creator’s intent. The constitution-check gate that validates proposed modifications is necessary but insufficient. The ultimate arbitration authority is the human who defined the system’s purpose. Acknowledging this limit precisely is more valuable than claiming to solve it.
SECTION 1
Introduction: The Missing Layer
The companion paper Behavioral Ontology: A General Theory of Declarative Automation 1 defines a Dynamic Behavioral Ontology (DBO) as a formal specification of what a system is and does. The specification is declarative, persistent, directly interpretable, and — critically — dynamic: it can be modified while the system is operational. Paper 4 4 establishes that a self-modifying DBO creates a trajectory through specification-space: S₀ → S₁ → S₂ → ..., where each state is a complete specification and each transition is a modification to the running system’s behavior.