Model Harness — Describing Software as Models

The first installment introduced the harnesses supporting AI development. The Model Harness provides a foundation for development and execution by describing software close to domain knowledge. Parts 2–4 address the Model Harness, followed by Architecture in Part 5, Programming in Part 6, and Runtime in Part 7. Part 8 addresses the Knowledge Harness: linking Literate and Object Models through a glossary, checking their correspondence, and making that knowledge available to AI through MCP. Part 9 covers the Observed Model as a projection of execution results, and Part 10 covers the Verification Harness, completing the feedback to models.

The preceding series established model-driven development, using models as the foundation for describing, developing, and executing software. Its checking and execution mechanisms also constrain AI-generated changes. Object Models retain formal structure and behavior; Literate Models retain context, requirements, scenarios, and decisions; Knowledge Models retain semantic relationships, grounds, and sources. A glossary manages names, meanings, synonyms, identities, and applicable contexts, supporting correspondence among the three. Business knowledge expressed in prose remains available for reference and revision throughout development.

These foundations support Domain, Use Case, and Application Models organized by purpose. Static and dynamic perspectives concern their structure and behavior: domains have behavior, and applications have structure. Machines can detect inconsistencies in explicit references and constraints, while people judge whether business meanings agree. Part 8 details the mechanisms for preparing, providing, and admitting knowledge.

The concepts, elements, relationships, and rules of the static models discussed previously provide a basis for describing software structure. Behavior, collaboration, and state transitions can be made explicit as state machines and workflows. People and AI work with structure and behavior at the same abstraction level, while processors check and execute those descriptions.

Part 2 presents the shared principle: describe software as models and apply constraints through interpretation, checking, and execution. Part 3 develops static structure, and Part 4 develops dynamic behavior, including state machines. These are corresponding aspects of the same software.

The motivation for model-driven development is to reduce impedance mismatch: the distance between domain concepts and their program representation. Recasting those concepts, relationships, and rules into substantially different implementation-oriented vocabulary and structures increases the effort of understanding and change. Models let software be described, generated, and changed at an abstraction close to the domain.

When developers describe software as models and AI supplies the missing implementation, the model effectively becomes their programming language. In SimpleModeling, Textus directly executes executable models written in CML, and AI automatically supplies necessary programming-language implementation beyond what the model provides. Developers can reduce their direct involvement in those implementation details and concentrate on concepts, relationships, rules, and behavior in the model.

State machines make dynamic behavior explicit. In conventional programming-language implementations, states, events, transition conditions, and destinations tend to be dispersed across variables, branches, and event handlers. A state machine brings them into one explicit structure. People and AI can reason about permitted behavior in that structure, and processors can check and execute it. Part 4 develops dynamic models, including state machines, in detail.

Processors statically check the models that form the foundation of model-driven development and directly execute their executable parts. Their structure, rules, and behavior govern actual development and operation. These mechanisms also constrain models and complementary implementation generated or changed by AI. Incorporating model constraints into checking and execution is what makes this foundation function as a Model Harness.

CML grammar defines the model elements and structures that processors handle. BoK manages the glossary and links Literate, Object, and Knowledge Models through shared meanings and identities. The semantic basis used by AI during generation and change can thus be retained as external project knowledge.

Reviews in textus-cbd-support examine contradictions in both executable models and non-executable models such as Use Cases. Build-time static model checks examine structural and rule inconsistencies before execution. Textus runs executable models directly and applies their constraints at runtime. Review, static checking, and direct execution work together, providing evidence for human decisions about revision and adoption.

CML describes models, Cozy transforms models into software, and Textus runs executable models. AI automatically supplies programming-language implementation where the model alone is insufficient for a complete program. Combining direct model execution with complementary implementation lets developers work at the model’s abstraction level. The complementary implementation must also reflect the model’s structure, rules, and behavior. Types and implementation discipline for that code are addressed by the Programming Harness in Part 6.

Correspondence with requirements establishes what the modeled software is intended to achieve. Retaining mappings and decision grounds among requirements, Use Cases, structure, behavior, and realizations supports checking both formal consistency and fitness for user goals. Traceability provides a means of examining purpose alongside model description, checking, and execution.

Moving directly from requirements to implementation can scatter AI-supplied assumptions and business choices across code, increasing the effort of checking correspondence. Making those assumptions and choices explicit in models and mapping them to realizations makes the reasons for a change and its impact available for examination.

Model Up/Down is a model-development concept specific to SimpleModeling. Model Down concretizes requirements and models toward realization. Model Up derives and displays an abstracted model suited to a review purpose. It makes models used in development and execution available in representations that stakeholders can understand.

Concretizing Use Case intent into execution is an example of Model Down. Domain facts and rules are connected to Use Case goals and scenarios and concretized into Application Models and admitted commands. Retaining identities and decision grounds at each stage makes the correspondence between intended meaning and realization traceable.

Natural-language intent is connected to execution through Typed Intent or commands. Making targets, values, preconditions, and authorization checkable gives the application explicit admission conditions.

A Use Case Harness compares Use Case goals and scenarios with corresponding model states, operations, and execution-check results. CML-based structural checks and AI-assisted semantic comparisons support stakeholders in judging agreement with requirements. This mechanism checks correspondence between requirements and realization.

A typical example of Model Up converts a workflow described as a state machine into a flowchart or activity diagram. State and transition details are abstracted for the review purpose, presenting a model of the business flow. Deriving an actor-goal list from a Use Case Model is another example. When the source model has undergone execution checks, its review abstraction lets stakeholders assess requirements against the model actually used for execution. Retaining correspondence with the source model allows feedback to return to development. In a requirements-model harness, this mechanism connects the model used for execution with stakeholder review.

A Domain Model represents facts, concepts, and rules in the subject world. An Application Model combines domain functions to achieve user goals. Placing shared business rules and state management in the domain, and application-specific collaboration and flow in the application, enables applications with different needs to use a common domain.

Changes in user needs or usage context prompt changes to Application Models. New facts about the domain or changes in the business itself prompt changes to Domain Models. Reasons for change are mapped to this distinction, and changes to a shared domain are assessed for their impact on the applications that use it.

Groups of Use Cases yield Application Capabilities offered to users, while individual scenarios yield Component Capabilities needed for realization. Capabilities are an intermediate representation for managing the abilities provided by the software. At runtime, the mapped operations and workflows execute.

Mappings link each Capability to its realizing operations and workflows and to verification examples. This intermediate representation lets the provided ability and its verification remain traceable as the realization changes.

Executable models express general structure, behavior, and rules and are mapped to implementation. Execution Example Models express concrete scenarios and interactions and are mapped to verification examples. Comparing both with execution results helps examine how rules relate to concrete behavior and supports model improvement.

Models and views are assessed for clarity, consistency, validity, and accuracy: whether they admit a common interpretation, avoid conflicting definitions and relationships, answer concerns necessary for their purpose, and match domain facts and rules. Structural checks are complemented by user and domain-expert judgment and by observation and execution results.

Performance, reliability, and security are quality attributes of the resulting software. They are assessed across requirements, models, architecture, implementation, and execution. The later Verification Harness connects checks and evidence from the different harnesses.

Views organized by purpose and concern present requirement mappings, candidate differences, grounds, change impacts, and verification results. The underlying models and glossary retain meanings and identities, while the views present decision-relevant information. People judge business meaning, priorities, and candidate adoption.

For order confirmation, a static model describes orders, payments, stock reservations, and their relationships, while a dynamic model describes transitions following payment success or failure. Business rules explicitly state how to handle a stock reservation and which audit records to retain after payment failure, with links to realizing operations and verification examples. Comparing execution results makes the required failure behavior examinable. This example illustrates the correspondence.

The Model Harness describes software close to domain knowledge and constrains generation and change through processor checks and execution. Correspondence with requirements also supports checking the software’s purpose. Part 3 develops static structure through concepts, relationships, and rules; Part 4 develops dynamic behavior, including state machines.