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 model is not a picture of the automation or documentation about it. It is the formal program foundation that defines what may be executed.

What the Model Must Contain

A working automation model must define enough of 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.

The Program Executes Inside 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 model defines the permitted world in which they operate. It determines what information they receive, which choices are available, and how the result is 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 formal model can serve several functions that are usually separated.

Before development, it can reveal missing facts, conflicting rules, unsupported states, and unavailable execution mechanisms. During development, it can define requirements, contracts, test cases, acceptance criteria, state transitions, and trace expectations. During execution, it can determine whether an action is permitted. After execution, verified cases can be compared with the model and used to improve it.

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, the model does not authorize the agent to guess. If two rules conflict, the system does not choose the one that sounds most plausible. If a case is outside the modeled scope, execution reports that boundary.

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 the model contains operational meaning, it can be licensed and reused. It can be connected to different companies without rebuilding the process definition for each one.

The model becomes a means of production for software rather than a document delivered at the end of a project.

That is why the model is the automation.