Glages Model Factory Project

Glages is a factory for producing reusable formal models of business processes and business domains for AI automation.

This project was created by Alexander Granovskiy to develop, test, explain, and build the Glages Model Factory as a new software production system and business. The factory produces machine-checkable models that define business activity before programs, LLMs, agents, or external services are allowed to execute it.

The central question is direct: how can reliable AI automation be built when the activity itself has never been represented as a complete formal model?

Glages answers that question by making the reusable formal software model the primary output of the factory.

The model is the automation.

No model — no automation.

Start Here

The best introduction to the project is:

• Glages: The Model Factory for AI Automation — the main overview of the factory, the models it produces, the model hierarchy, company connection, the role of LLMs, and the practical value of formal models.

The remaining articles in the public series develop the factory from several perspectives:

• what the factory produces;
• how reusable process models are created and applied;
• how process models compose into business-domain models;
• how models connect to specific companies;
• how formal models define the automation boundary;
• how LLMs assist production without becoming the source of truth;
• how organizations use models to build software systems and controlled automation;
• how the factory and model library become a growing asset.

What This Project Is About

Modern AI systems can read documents, interpret requests, generate code, call APIs, and select tools. These capabilities make many new forms of automation possible.

They do not, by themselves, define the activity being automated.

In many organizations, the complete meaning of a process remains distributed across documents, software systems, field names, policies, integrations, exceptions, and human experience. A person still determines which facts matter, which source is authoritative, which rule applies, what action is permitted, what result is valid, and when nothing should be done.

An AI agent placed into this environment is often expected to reconstruct that missing model while it is already acting.

Glages separates model construction from execution.

identify the activity
→ construct the formal model
→ verify the model
→ determine its boundary
→ connect it to the company
→ execute only what the model permits
→ preserve the trace

The model defines the permitted world. Programs, LLMs, agents, external services, and human-approved steps may operate inside it.

What the Factory Produces

The Glages Model Factory produces connected layers of reusable software assets.

base concepts and relationships
→ reusable process models
→ process composition
→ composed business-domain models
→ company connection
→ model library

Reusable Process Models

A reusable process model is a formal, machine-checkable model of a process that appears across different industries.

Examples include:

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

Each model defines the participating Entities, relevant states and relationships, required facts, applicable conditions, permitted actions, allowed changes, possible results, and stopping conditions.

The common process meaning remains independent of one company.

A refund model can be used in e-commerce, retail, rental, hospitality, logistics, insurance, and other domains. A payment model can support marketplaces, hotels, medical practices, repair services, property management, and many other business domains.

Composed Business-Domain Models

A business is not one isolated process.

An e-commerce business-domain model may include:

order
+ payment
+ inventory reservation
+ shipment
+ delivery
+ modification
+ return
+ refund
+ claim handling
+ customer service
→ e-commerce business-domain model

A composed business-domain model combines reusable process models with the Entities, states, rules, relationships, and results specific to a class of business activity.

The value of composition is not simply that several processes appear together. Their meanings and dependencies are made consistent across the entire domain.

Company Connection

A reusable model describes the common structure of an activity. A company connection maps that model to the systems and operating environment of a particular organization.

It defines:

• which company records represent model Entities;
• which systems provide authoritative facts;
• which fields represent relevant states;
• which APIs perform permitted changes;
• which local parameters affect the rules;
• which roles possess the required authority;
• which execution mechanisms are available.

The reusable model remains common. The company connection makes it operational in a specific company.

Model Library

The factory maintains a growing model library containing:

• reusable process models;
• composed business-domain models;
• verified relationships;
• tests;
• corrections;
• validated cases;
• explanations;
• traces.

Each completed model strengthens the production of later models. Each verified application can improve the models already in use.

The model library and the production system that creates it are the central assets of the project.

Why Formal Models Matter

An automation model is a formal, machine-checkable description of the part of reality that can be executed without reconstructing its meaning during execution.

The model must define enough structure to determine:

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

A plausible action is not automatically a valid modeled action.

A successful demonstration is not the same as reliable automation.

When a situation is outside the model, the system does not improvise. It can report that a required fact is missing, a reference cannot be resolved, rules conflict, no permitted action exists, an execution mechanism is unavailable, or the case is outside the modeled scope.

This verified boundary is itself a valuable result.

The Role of LLMs

Formal models have always been expensive to produce because model construction requires large amounts of reading, comparison, terminology resolution, formalization, testing, and verification.

LLMs change the economics of this work.

They can assist with:

• reading source material;
• recognizing candidate concepts and processes;
• comparing formulations;
• locating contradictions;
• identifying missing relationships;
• proposing model fragments;
• drafting formal structures;
• suggesting tests;
• mapping conclusions back to evidence.

LLM output is a candidate.

It becomes part of the model only after formal representation and independent verification.

accumulated knowledge and source material
→ candidate model
→ typed formal representation
→ verification
→ reusable model
→ model library

The factory distills probabilistic knowledge into deterministic, reusable, machine-checkable software models.

Controlled Execution

Once a model has been produced, verified, and connected to a company, different execution mechanisms may operate inside it.

A conventional program may perform deterministic work. An external service may execute an approved operation. An LLM may interpret bounded text, extract structured facts, draft content, or choose among explicitly available alternatives. A human-approved step may remain where authority is required.

The mechanism may change. The model preserves the meaning of the activity.

The agent operates only inside the world expressed by its approved typed Input. It does not invent a new process, assume a missing fact, expand the modeled world, or treat an unsupported case as close enough to a supported one.

AI becomes a replaceable mechanism inside the system rather than the foundation of correctness.

What Organizations Can Use the Models For

An organization can use a Glages model as a reusable software foundation for building and verifying automation.

The organization remains responsible for its market, customers, interfaces, integrations, deployment, and support. Glages supplies the formal process or business-domain model on which software systems and automation services can be built.

The same model can support:

• automation-readiness assessment;
• technological due diligence;
• software requirements and test generation;
• integration contracts;
• verification of policies, contracts, APIs, data, and code;
• controlled execution;
• transactional self-service;
• customer-service systems;
• conformance testing and certification;
• compatibility of partner extensions;
• composition of new software systems;
• redesign of business activity and organizational structure.

One reusable model can support several business domains, organizations, software systems, and company implementations.

one reusable process model
→ multiple business domains
→ multiple organizations
→ multiple software systems
→ multiple company implementations
→ recurring model value

Business Results and Technical Failures

A valid negative business result is different from a technical failure.

A refund may be blocked. A payment may be declined. A claim may require more evidence. A request may be outside the modeled scope. These can be correct results of a successfully executed process.

Technical failure includes infrastructure failure, an invalid execution contract, an unavailable external operation, an unhandled exception, or an inability to preserve consistency.

The model keeps these meanings separate so that the system can explain what actually happened.

What Is Being Developed Here

The public Glages corpus develops the model factory through a connected article series.

The Factory and Its Models

• Glages: The Model Factory for AI Automation
  The main introduction to the factory, model hierarchy, company connection, model reuse, the role of LLMs in production, and the practical value of formal models.
• Glages: What the Model Factory Produces
  Reusable process models, composed business-domain models, and company connections.
• Glages: One Process Model, Many Markets
  How one process model creates value across industries, organizations, software systems, and implementations.
• Glages: From Process Models to Business-Domain Models
  How reusable processes compose into a coherent model of an entire class of business.
• Glages: How LLM Makes the Model Factory Possible
  How LLMs change the economics of model production while verification remains independent.
• Glages: The Model Is the Automation
  Why the model is a working software foundation rather than documentation about a process.

Reusable Process Models

• Glages: A Refund Model Is a Reusable Software Product
  How a refund model separates common process meaning from each company connection.
• Glages: One Payment Model Across Many Business Domains
  How one payment model supports many domains while preserving consistent process meaning.
• Glages: Company Connection Makes a Common Model Operational
  How company-specific data, systems, APIs, identifiers, parameters, and roles connect to a common model.

Boundaries, Uses, and Accumulation

• Glages: The Model Reveals the Automation Boundary
  What can be executed, what is missing, and where execution must stop.
• Glages: One Model, Many Uses
  Readiness, due diligence, requirements, testing, execution, verification, self-service, certification, and software-system composition.
• Glages: Models Become a Growing Capital Asset
  How models, tests, corrections, and validated cases strengthen the factory and model library.
• Glages: The Agent Is a Replaceable Mechanism
  Why the activity model remains durable while execution mechanisms change.
• Glages: Business Results Are Part of the Model
  Why a decline, blocked action, missing evidence, or unsupported case may be a valid modeled result.
• Glages: What Organizations Can Build on the Models
  Software systems and automation services that organizations can build on licensed process and business-domain models.
• Glages: Why Building the Factory Is Difficult
  The shared typed core, verification mechanisms, methodology, composition capability, tests, and model library behind the factory.
• Glages: What the Factory Is and Is Not
  The distinction between Glages and agent frameworks, workflow engines, ontologies, rules engines, retrieval systems, and evaluation layers.

Together, these articles explain the software models, production system, application logic, technical boundaries, and business potential of the Glages Model Factory.

Relationship to Experience Capitalization

Experience Capitalization and Glages are separate but connected projects.

Experience Capitalization
→ knowledge and experience created through work can become reusable assets

Glages
→ business knowledge can be distilled into reusable formal models for controlled automation

Experience Capitalization asks how companies can preserve and reuse what work teaches.

Glages produces a specific class of reusable software asset: formal models of business processes and business domains.

The two projects share the principle that valuable knowledge should not disappear after one use. Glages applies that principle to the formal structure required for reliable automation.

Who Is Behind This Project

The Glages Model Factory project was developed by Alexander Granovskiy.

Alexander has worked across highly reliable technical systems, software development, e-commerce, payments, risk, marketplaces, infrastructure, integrations, automation, and daily business operations.

His work has repeatedly involved the same practical problem: software may automate individual operations while people continue to supply the missing model that connects facts, rules, systems, exceptions, and valid results.

Glages develops a systematic answer to that problem.

Who This Project Is For

This project is for people and organizations that need a more reliable foundation for AI automation.

That includes:

• founders of AI and vertical-software companies;
• system integrators;
• product and platform leaders;
• enterprise architects;
• ERP, CRM, and workflow vendors;
• companies building agentic systems;
• technology investors and strategic partners;
• firms working in due diligence, compliance, verification, and certification;
• organizations evaluating which activities are actually ready for automation.

The project is also for people who recognize that stronger agents do not remove the need to define the activity those agents are expected to perform.

Public Professional Background

Alexander Granovskiy's professional background and related public work can be reviewed here:

LinkedIn: https://www.linkedin.com/in/alexander-granovskiy

Personal website: https://www.alexgranovskiy.com/

Medium: https://medium.com/@alexander-granovskiy

Substack: https://granovskiy.substack.com/

GitHub: https://github.com/alexander-granovskiy/

Hugging Face: https://huggingface.co/alexander-granovskiy

Product Hunt: https://www.producthunt.com/@experiencecapitalization

YouTube: https://www.youtube.com/@ExperienceCapitalization

X / Twitter: https://x.com/granovskiy_ec

Contact

To discuss the Glages Model Factory, model production, partnerships, investment, independent review, commercial applications, or possible implementation scenarios, contact Alexander Granovskiy.

Email: contact@experiencecapitalization.com

LinkedIn: https://www.linkedin.com/in/alexander-granovskiy

The Practical Starting Point

Reliable automation begins by determining whether the activity has been modeled well enough to execute.

A formal model first reveals:

what can be executed
what is missing
where execution must stop

It then becomes the reusable software foundation for company connections, software systems, verification, and controlled execution.

The Glages Model Factory project exists to build that foundation systematically.

Glages is the model factory for AI automation.

No model — no automation.