Glages: The Model Factory for AI Automation

AI automation is often built around agents that must reconstruct a business activity while they are already acting. They receive messages, records, documents, APIs, and a goal, then determine which facts matter, which rules apply, what action is permitted, and what the result means.

Glages takes a different approach.

Glages is a formal-model production technology for creating explicit, machine-checkable Glages Models from generalized domain knowledge.

The Glages Model Factory provides the production system for creating, verifying, composing, specializing, packaging, releasing, and maintaining them systematically.

One major commercial application is the Glages Business-Domain Model Factory, which produces reusable Glages Models of business processes and business domains for AI automation and software systems.

The central problem is not simply a lack of agent capability. Many activities have never been represented as complete formal models.

The Product Is the Model

A Glages Model is a formal, machine-checkable representation of a declared process class or other computational domain.

For a business process, a model may define:

• participating Entity and Process concepts;
• states and relationships;
• required facts;
• conditions and rules;
• permitted actions and changes;
• Input, Result, and Output;
• stopping conditions;
• evidence and trace requirements.

The model gives software an explicit semantic space in which to operate.

A model becomes a reusable product only after Program Acceptance, Model Adequacy, package construction, package and integrity checks, positive Release Eligibility, and Release.

A released Glages Model is a reusable model product.

This distinction matters. A candidate model is not yet a product merely because it compiles or looks plausible.

From Process Models to Business-Domain Models

The Business-Domain Model Factory can produce reusable process models such as:

• payment;
• refund;
• reservation;
• shipment;
• delivery;
• approval;
• claim handling;
• document verification;
• repair;
• invoicing;
• obligation modification.

These models may then participate in Model Factory composition.

base concepts and relationships
+
compatible process Glages Model assets in the `Accepted` or `Released` lifecycle state
→ Model Factory composition
→ candidate composed business-domain model
→ Program Acceptance
→ accepted Glages Model
→ Model Adequacy
→ package construction
→ candidate release package
→ package and integrity checks
→ verified release package
→ Release Eligibility
→ Release
→ released Glages Model

A composed e-commerce model, for example, may connect order, payment, inventory reservation, shipment, delivery, modification, refund, and claim handling within one coherent formal structure.

Composition is not merely packaging several files together. Relationships among the processes must remain explicit and compatible.

The result of composition is a new candidate Glages Model. If Program Acceptance succeeds, that model enters the Accepted lifecycle state. Model Adequacy must then be established, package construction must produce a candidate release package, package and integrity checks must produce the verified release package, Release Eligibility must be positive, and Release must move the model into the Released lifecycle state before the result becomes a reusable product.

How the Factory Produces Models

Model Factory production begins from generalized domain knowledge represented through Domain Evidence, together with Glages Model assets in the Accepted or Released lifecycle state where relevant. Large language models process these production inputs and help generate candidate concepts, comparisons, questions, tests, and formalizations. Their output is candidate production material rather than an evidence authority.

The Factory distinguishes two Domain Evidence classes. Binding Domain Evidence includes applicable laws, regulations, mandatory standards, governing protocol or network rules, and other mandatory external constraints. Informative Domain Evidence may include public technical specifications, public documentation, research and reference literature, verified public or generalized cases, and reproducible abstract cases. Binding Domain Evidence remains traceable to the authoritative source that establishes the applicable constraint. LLM-recalled material and secondary summaries can support discovery and interpretation, but they do not by themselves establish a binding constraint.

Accepted or released Glages Models are reusable production assets rather than Domain Evidence. Factory tests and corrections are also retained as separate reusable production assets.

The production flow is:

Domain Evidence representing generalized domain knowledge
├── Binding Domain Evidence where applicable
└── Informative Domain Evidence where useful
+
Glages Model assets in the `Accepted` or `Released` lifecycle state where relevant
→ candidate model structure
→ Glages formal representation
→ candidate Glages Model
→ Program Acceptance
→ accepted Glages Model
→ Model Adequacy
→ package construction
→ candidate release package
→ package and integrity checks
→ verified release package
→ Release Eligibility
→ Release
→ released Glages Model

The Model Library participates across this lifecycle. It begins retaining a model asset when Program Acceptance moves it into the Accepted lifecycle state and continues retaining the same asset after Release moves it into the Released lifecycle state, together with distributable release packages and supporting production evidence.

LLM output is candidate material. Formal representation makes the candidate machine-checkable; Program Acceptance determines whether the candidate Glages Model enters the Accepted lifecycle state.

Program Acceptance and Model Adequacy answer different questions. Program Acceptance establishes that the artifact is formally valid under Glages rules. Model Adequacy asks whether that formally valid model actually covers enough of its declared process class and scope to be released as a reusable product. A model can therefore be completely valid and still be inadequate because important process variants, exceptional paths, or binding constraints are missing. Adequacy is established through evidence of coverage, not through compilation alone.

The Formal Model Interface

Every released Glages Model includes a Formal Model Interface.

The Formal Model Interface is the complete machine-readable public surface of the released model. It exposes model identity and version, formal concepts and relationships, Entities and Processes, required facts, states and allowed changes, rules and conditions, Input, Result, Output, declared operations, dependencies, compatibility information, traceable semantic relationships, and other machine-readable obligations defined by the released model.

It is part of the released model product.

It is not a separate integration layer.

Recipient software is built against this interface and can be checked for conformance with the released model.

Release, Distribution, and Application

The Factory production lifecycle ends with release.

After that, the relationship is different:

released Glages Model
→ Distribution
→ Recipient
→ Application

Distribution covers licensing and delivery of the released model, package, versions, documentation, and access to released artifacts.

The recipient decides how to apply the model.

Applications may include vertical software products, AI automation, transactional self-service, customer-service systems, ERP or CRM extensions, verification and certification tools, readiness assessment, due diligence, simulation, planning, and other software systems built against the released Glages Model.

The recipient remains responsible for its own software, integrations, deployment, customers, and operating environment.

Glages licenses the released Glages Model and provides the machine-checkable boundary against which software can be built and verified.

The Model Defines the Boundary

The licensed model does more than provide reusable knowledge.

It constrains the semantic space of software built against it.

Software that assumes model concepts, facts, states, transitions, Results, or declared operations outside the released model fails Glages verification.

This is one of the central product properties.

The model defines both the formalized meaning available to software and the boundary of meanings that recipient software may use while remaining conformant.

A released Glages Model is normative rather than descriptive. It defines the formal structure a declared process class must satisfy to be represented, verified, and executed through stable software semantics. A difference observed in a recipient application can indicate a legitimate narrower reusable process class suitable for Factory specialization, a potentially reusable gap that should be independently reformulated as Domain Evidence for later Factory evaluation, or recipient-specific behavior that remains outside the released model's executable scope.

For AI automation, this produces the operating principle:

The model is the automation.

and:

No model - no automation.

An LLM may interpret text. A conventional program may execute deterministic logic. An external service may perform an approved operation. A human-approved step may remain where authority is required.

These mechanisms may change when a substitute satisfies the applicable model-defined role, input/output semantics, authority boundary, validation obligations, and compatibility requirements.

The applicable released Glages Model remains the machine-checkable semantic authority for model-governed behavior.

The Growing Production Asset

The long-term asset is the production system and the Model Library that allow many models to be produced systematically and reused across applications.

The Model Library begins retaining model assets in the Accepted lifecycle state and continues retaining those same assets after Release moves them into the Released lifecycle state, together with versions, dependencies, verification evidence, adequacy evidence, tests, corrections, Passing and Failing Model-Verification Cases derived from generalized Domain Evidence and Glages Model assets in the Accepted or Released lifecycle state where relevant, documentation, provenance, and distributable release packages.

Accepted or released Glages Model assets can become reusable production inputs for later models.

Composition and specialization create new candidate models.

Each new candidate again passes Program Acceptance, Model Adequacy, package construction, package and integrity checks, Release Eligibility, and Release before it becomes a reusable product.

This is why the word Factory matters.

The Model Factory is a production system for creating reusable Glages Model products that recipients can use as foundations for many different applications. The commercial model centers on producing, verifying, releasing, licensing, and distributing those reusable model products.