Glages: The Model Is the Automation

Most organizations describe automation through workflows, prompts, integration code, and operational instructions. The actual meaning of the activity remains spread across those artifacts and the people who interpret them.

Glages uses a stricter formula:

The model is the automation.

The Glages Model is not a picture of the automation or documentation about it. It is the explicit, machine-checkable program foundation that defines what may be executed.

What the Model Must Contain

A working Glages Model for automation must define enough of the modeled reality to determine:

• what exists;
• what facts are required;
• which states and relationships matter;
• which actions are available;
• which conditions permit or block them;
• which changes are allowed;
• which results may be produced;
• when execution must stop;
• which evidence must be preserved.

A refund cannot be automated merely because an API named CreateRefund exists. The system must know which payment the request refers to, whether the payment is refundable, how much remains available, whether authority exists, and what result follows if any required fact is missing.

Those meanings belong in the model.

Execution Operates Under the Model

The formula does not mean that the model performs every technical operation by itself. A payment provider may capture money. A carrier service may create a label. An LLM may interpret a customer message. A conventional program may calculate an amount.

These are execution mechanisms.

The Glages Model defines the permitted world in which execution mechanisms operate. Runtime components use that authority to determine which facts are required, which actions are permitted, and how Results are interpreted.

A mechanism may change without changing the modeled process. The company may replace one payment provider with another or one LLM with a newer model. The business meaning remains stable because it is not stored inside the provider or the prompt.

More Than Requirements

A released Glages Model can serve several functions that are usually separated.

Before development, applying a released Glages Model can reveal missing required facts, unavailable authoritative sources, implementation mappings, and execution mechanisms. During development, the model can define requirements, contracts, test cases, acceptance criteria, state transitions, and trace expectations. During execution, it remains the authoritative source for whether an action is permitted. After execution, traces and results can be checked for conformance and diagnostics; persistent model evolution remains a controlled Model Factory process grounded in generalized domain evidence.

The same structure therefore connects planning, implementation, runtime, and review.

A Visible Boundary

An important property of real automation is the ability to stop correctly.

If a required fact is missing, model-governed execution cannot proceed by guessing. If a case is outside the released model's declared scope, execution reports that boundary rather than inventing new semantics.

This leads to the second canonical formula:

No model — no automation.

The formula is not a rejection of partial automation. It is a requirement that the automated part be explicit. A system may automate eighty percent of a process and identify the remaining twenty percent precisely. That is more useful than claiming full automation while silently relying on runtime interpretation.

A Reusable Software Asset

Because a released Glages Model contains operational meaning, it can be licensed and reused. Licensees can integrate the same released model with their own facts, systems, APIs, and execution mechanisms without rebuilding the process definition for each implementation.

The released Glages Model becomes a reusable means of production for software rather than a document delivered at the end of a project.

That is why the model is the automation.