The Three Axioms of Text2System
Composition. Specification. Verification.
A system is not defined by the mere existence of its parts. It is defined by the parts we distinguish and the relationships through which they form a whole. To specify a system is to make that organization explicit, state what must hold, and define how those claims can be verified. These are the three axioms of Text2System.
1. The axiom of composition
Let M be the set of modules and R the set of relationships among them. The structural model of a system is:
A module is a bounded unit of responsibility. Its internal state and behavior belong to its definition; its interfaces express what it exposes to the rest of the system. A relationship gives meaning to an interaction or organization among modules: composition, dependency, communication, control, or exchange. Relationships are typed and may carry their own properties and rules.
This definition is recursive. A module can itself be described as a system, with its own modules and relationships. Thus, abstraction changes the scale of observation without changing the language of composition. At one level we see a module; at another, we see the system within it.
Behavior does not have to be added as an unrelated ingredient: modules behave, relationships mediate interaction, and the composed system exhibits behavior arising from both. Constraints can govern a module, a relationship, or the composition as a whole. The environment lies outside the chosen boundary and is represented by the system's external interfaces and interactions.
The equation is intentionally compact. Its power depends on the semantics of M and R, not on treating a bare graph as a complete explanation of reality. A model is useful when its boundaries and relationships are precise enough for the questions we ask of it.
2. The axiom of specification
Composition tells us how to express a system. Specification gives that expression normative force: it distinguishes what is required from what merely happens to exist. It identifies the intended modules, their relationships, their contracts, and the conditions that must hold across them.
We write:
Here S is the intended system model, Q is the set of requirements, and V is the set of verification definitions associated with those requirements. A requirement may be formulated as a predicate over the system or its observable behavior: a proposition whose satisfaction can be assessed. The notation expresses an engineering foundation rather than prescribing a particular file syntax.
A specification is therefore more than a description. It is a contract: an explicit account of what the realization is obliged to preserve, provide, or prevent. Requirements can address individual modules, relationships, or properties of the whole that emerge from their interaction. The specification is authoritative not because it cannot be questioned, but because changes to the intended system must be made there deliberately and traceably.
3. The axiom of verification
Engineering does not end with a statement of intent. For each requirement, we must be able to ask: what would count as evidence that the realized system satisfies it? The answer belongs to the specification. A verification definition connects a requirement to an acceptance criterion and an appropriate method: test, analysis, inspection, measurement, or proof.
The distinction between definition and result is essential. A verification definition belongs to Σ; the evidence produced by applying it belongs to a particular implementation, version, configuration, and environment. The same specification can therefore be used to assess successive realizations without rewriting the requirements to match their outcomes.
Verification is not a ritual of declaring success. It is a disciplined way to justify claims. A passing test establishes evidence within its scope; a formal proof establishes a claim under stated assumptions. Neither should be confused with the system itself. Traceability connects the requirement, its subject in the system model, its verification definition, and the resulting evidence.
These axioms form a single engineering argument. Composition makes a system describable. Specification makes its obligations explicit. Verification makes claims about its realization assessable. None replaces the others.
The specification defines the system. The implementation realizes it. The tests verify it.
In this principle, tests stands for the broader discipline of verification. Text2System seeks to preserve the connection between what is defined, what is built, and what can be demonstrated. That connection is the foundation of an authoritative, verifiable system specification.