Glages Model Factory Project

Glages Model Factory Project
Glages Model Factory Project

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

Glages Models are a new type of AI model: explicit formal, machine-checkable models whose stable meaning can be inspected, verified, reused, composed, and specialized independently of the probabilistic model that may help produce them.

The Glages Model Factory Project develops the production system required to create Glages Models systematically and at scale, including the language, model-production architecture, Program Acceptance, Model Adequacy, composition, specialization, release machinery, and Model Library.

The Glages Business-Domain Model Factory is one major commercial application of Glages. It applies the same technology to business processes and business domains for AI automation and software systems.

The central idea is simple: many computational systems repeatedly reconstruct the same meaning while they are already operating. They interpret documents, infer states, resolve relationships, decide which facts matter, reconstruct rules, choose actions, and determine what is allowed. Much of that knowledge could instead be represented once as an explicit formal model, verified, reused, specialized, composed with other models, and applied across many systems.

The project is intended to make the production of such models systematic.

Glages does not begin with a particular interface, agent, workflow, application, or industry. It begins with the knowledge that a system needs in order to understand what exists, what can happen, which facts matter, which conditions apply, which actions are valid, which changes are allowed, which results are possible, and when the system must stop.

The output is not merely documentation about that knowledge.

After Release, the product output is a reusable Glages Model.

The Central Problem

Modern AI systems are increasingly capable of reading documents, interpreting requests, generating software, calling APIs, analyzing images, selecting tools, and coordinating actions.

Capability, however, is not the same as an explicit model of the world in which those capabilities are used.

A system may be able to answer a question about a payment without having a complete payment model. It may be able to plan a robotic task without having a reusable task model. It may be able to interpret a procedure without having a machine-checkable representation of the states, conditions, actions, exceptions, and stopping boundaries defined by that procedure.

When the model is missing, meaning must be reconstructed at runtime.

That reconstruction may depend on:

  • natural-language interpretation;
  • prompt context;
  • retrieved documents;
  • human assumptions;
  • software conventions;
  • hidden relationships between data fields;
  • previous cases;
  • probabilistic inference;
  • ad hoc code;
  • agent reasoning.

This can work surprisingly well in individual cases.

It does not automatically create a reusable, verifiable model.

Glages addresses a different question:

What knowledge can be formalized before execution so that a computational system does not need to reconstruct the same meaning every time it operates?

That question applies far beyond one software category or one business process.

What Glages Produces

A Glages Model is an explicit, formal, machine-checkable model of the Entities, Processes, states, relationships, facts, conditions, actions, changes, results, and boundaries required for a defined computational purpose. Candidate, Accepted, and Released are lifecycle states of a Glages Model.

Across applications, the canonical Glages Model properties are:

  • formal structure;
  • verifiability;
  • reuse;
  • composition;
  • specialization;
  • explicit stopping boundaries;
  • reduced dependence on runtime inference.

A model may be broad or narrow.

It may describe an entire domain, one reusable process, one robotic task, one verification problem, one planning structure, or only the subset of knowledge required by a constrained device.

Accepted or released Glages Model assets can also serve as parent assets for Model Factory Specialization.

A broad parent model does not have to define every released specialization. The Model Factory can produce narrower specializations for defined application classes or computational constraints.

This is an important distinction from systems that depend on one large model carrying all knowledge at runtime.

The Model Production Path

The Glages Model Factory converts generalized domain knowledge into Glages Models and can reuse accepted or released Glages Model assets as production inputs.

generalized domain knowledge
+ accepted or released Glages Model assets where relevant
→ model-production workspace
→ candidate Glages Model
→ Program Acceptance
→ `Accepted` lifecycle state
→ Model Adequacy
→ package construction
→ candidate release package
→ package and integrity checks
→ verified release package
→ Release Eligibility
→ Release
→ `Released` lifecycle state
→ reusable Glages Model product

Generalized domain knowledge may include binding evidence such as laws, regulations, mandatory standards, network rules, and authoritative technical requirements, together with informative evidence such as public technical documentation, public APIs and specifications, research, industry documentation, and verified public cases.

The factory separates several activities that are often mixed together.

Recognition

The system identifies candidate Entities, Processes, states, facts, conditions, actions, relationships, changes, and results.

Resolution

Different names, descriptions, sources, and representations are reconciled into a consistent formal meaning.

Construction

The resolved candidate meaning is expressed as typed Glages Model source.

Verification

Candidate model structure is checked for formal consistency, contradictions, unsupported assumptions, invalid relationships, and other machine-checkable defects. Program Acceptance determines whether the candidate enters the Accepted lifecycle state. Model Adequacy is a separate determination for the accepted model's declared scope.

Reuse and Composition

Accepted or released Glages Model assets can be reused as production inputs or combined through Composition.

Specialization

The Model Factory can derive a narrower candidate Glages Model from an accepted or released Glages Model asset for a defined market, task class, device class, mission class, application class, or computational constraint while preserving the required inherited semantics. The specialized candidate then follows the same Program Acceptance, Model Adequacy, packaging, Release Eligibility, and Release path as any other candidate model.

Application

After Release, the model can serve as a formal foundation for execution, verification, planning, simulation, software design, autonomous behavior, or another computational purpose.

The long-term asset is therefore not one model.

It is the capability to produce and maintain many compatible models systematically.

Why a Factory Matters

Formal models already exist in many areas of engineering and software.

The difficulty is that they are usually created manually, for one project, one organization, one system, or one narrow purpose.

That makes formalization expensive.

It also limits reuse.

The project is based on the hypothesis that modern AI can change the economics of formal model production.

This hypothesis does not stand alone. Formal methods provide the long-established engineering basis for explicit machine-checkable structure, while recent work in neuro-symbolic AI, compiled AI, deterministic verification, agentic business process management, and enterprise ontology systems shows growing practical interest in separating probabilistic interpretation from explicit operational structure.

AI systems can assist with reading large bodies of material, identifying candidate concepts, comparing definitions, resolving terminology, finding contradictions, proposing structures, and generating candidate formal fragments.

But candidate generation and model verification are different tasks.

LLM output is candidate production material.

It can contribute to a candidate Glages Model only after it is expressed in typed model source. Program Acceptance then determines whether that candidate enters the Accepted lifecycle state.

The purpose of AI inside the factory is therefore not to replace formal structure.

It is to make formal structure cheaper and faster to produce.

Formal Models Before Runtime Inference

One of the most important potential effects of Glages is moving knowledge from repeated runtime inference into reusable formal structure.

Consider a system that repeatedly needs to infer:

  • what state it is in;
  • which facts matter;
  • which rule applies;
  • which action is allowed;
  • what result is valid;
  • whether the case is supported;
  • when execution must stop.

If those relationships are already represented in a verified formal model, the system may no longer need to reconstruct all of them every time.

This can matter even when an LLM remains part of the runtime.

The LLM can work inside a much smaller and more explicit world.

It may interpret bounded text, classify evidence, map observations to modeled alternatives, or choose among explicitly available options.

The model supplies the stable structure.

The AI handles the parts that genuinely require probabilistic interpretation.

This distinction creates a different architecture:

model defines the permitted world
→ runtime receives the relevant subset
→ AI interprets only what must be interpreted
→ execution remains inside explicit boundaries

Models Can Be Different Sizes

A reusable Glages Model does not have to be deployed as one indivisible object.

The same underlying knowledge can be organized into different levels and subsets.

A broad model may describe a large domain.

A specialized model may contain only the knowledge needed for one task.

A constrained system may receive an even smaller subset.

This matters for:

  • edge devices;
  • robotics;
  • drones;
  • autonomous systems;
  • low-power hardware;
  • air-gapped environments;
  • systems with limited memory or compute;
  • applications where latency matters;
  • applications where repeated inference is expensive.

The relevant question is not whether every device can run the largest possible AI model.

The question is how much knowledge can be made explicit before runtime, and how much of that formal knowledge a particular system actually needs.

Application Domains

Glages is not limited to one business domain or one form of automation.

The same formal-model production approach can be applied wherever a computational system benefits from explicit reusable knowledge.

AI Automation and Software Systems

Business activity is one major application.

A formal model can define business processes, states, facts, rules, conditions, actions, exceptions, results, stopping boundaries, and relationships between processes.

These models can support software development, AI automation, self-service, verification, integration, testing, and controlled execution.

This application is developed through the Glages Business-Domain Model Factory.

Autonomous Systems

Autonomous systems need explicit representations of what exists, which state matters, which actions are available, what conditions permit those actions, what results are expected, and when the system should not act.

Glages Models can provide reusable formal structure for such decisions instead of requiring the system to infer the entire operating meaning continuously at runtime.

Robotics

Robotic systems repeatedly perform tasks that contain reusable structure.

A task can include:

  • participating Entities;
  • preconditions;
  • state transitions;
  • permitted actions;
  • physical or logical constraints;
  • expected results;
  • stopping conditions;
  • failure conditions.

Reusable task and process models may allow robotic systems to share formal task knowledge rather than rebuilding it separately for every implementation.

Formal Verification and Certification Systems

A formal Glages Model can serve as an explicit machine-checkable specification.

Software, behavior, documents, interfaces, or other models can then be compared against that specification.

This creates potential applications in:

  • conformance testing;
  • certification;
  • compatibility verification;
  • behavioral validation;
  • requirements verification;
  • repeated verification after system updates.

Simulation and Planning

Simulation and planning depend on explicit representations of entities, states, transitions, conditions, possible actions, and results.

Reusable Glages Models can provide a common structure that can be used by different planning or simulation systems.

The same model can potentially support both analysis before action and controlled execution later.

Software Design

Formal models can also become design artifacts.

A model may define the structure that software must implement before code is written.

This can support:

  • requirements;
  • state and transition structures;
  • software contracts;
  • APIs;
  • test generation;
  • acceptance criteria;
  • integration rules;
  • composition of larger systems from reusable model components.

Edge and Inference-Constrained Systems

Many systems cannot rely on unlimited runtime inference.

They may have strict limits on compute, memory, power, latency, connectivity, or access to large external models.

A Glages Model can move part of the required knowledge into explicit formal structure before deployment.

A released specialization can contain only the subset required by its declared application class or computational constraint.

This creates a possible path toward stronger behavior without requiring a larger runtime model.

The Business-Domain Model Factory

The Glages Business-Domain Model Factory is one major application of the broader Glages technology.

It produces reusable Glages Models of business processes and business domains for AI automation and software systems.

Its structure is:

base concepts and relationships
→ process Glages Model assets in the `Accepted` or `Released` lifecycle state
→ Composition
→ candidate business-domain Glages Model
→ Program Acceptance
→ `Accepted` lifecycle state
→ Model Adequacy
→ package construction
→ candidate release package
→ package and integrity checks
→ verified release package
→ Release Eligibility
→ Release
→ `Released` lifecycle state
→ Model Library

Reusable Process Models

A reusable process model represents a process that appears across many industries.

Examples include:

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

A process model remains independent of one company.

The same payment model may be used in e-commerce, hospitality, insurance, marketplaces, repair services, and other domains.

The same refund model may be used in retail, rental, logistics, hospitality, and other environments.

Composed Business-Domain Models

Reusable processes can be combined into a larger coherent model of a business domain.

An e-commerce model may include:

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

The value is not simply that these processes appear together.

Their Entities, states, facts, rules, relationships, conditions, actions, changes, and results must remain consistent across the composition.

The Model Is the Automation

For AI automation, Glages uses a simple rule:

The model is the automation.
No model - no automation.

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

It must define enough structure to determine:

  • what exists;
  • what can happen;
  • which facts are required;
  • which states matter;
  • which relationships must hold;
  • which conditions permit or block actions;
  • which actions are available;
  • 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.

If required facts are missing, rules conflict, no valid action exists, or the case is outside the modeled scope, the system can stop explicitly instead of improvising.

That boundary is part of the model.

Controlled Execution

After Release, a licensee may connect a Glages Model to its own environment, where different execution mechanisms can operate inside the model-defined boundaries.

The mechanism may be:

  • conventional software;
  • deterministic rules;
  • an external service;
  • an LLM;
  • a human-approved step;
  • another computational system.

The mechanism may change.

The Glages Model preserves the permitted meaning.

An AI agent can interpret bounded text, extract structured facts, classify evidence, draft content, or choose among modeled alternatives.

It does not need to invent the process itself.

It operates inside the world defined by the model.

One Model, Many Uses

A reusable Glages Model can create value beyond one runtime execution.

Within business systems, the same model can support:

  • automation-readiness assessment;
  • technological due diligence;
  • requirements;
  • test generation;
  • integration contracts;
  • policy verification;
  • contract verification;
  • API verification;
  • data validation;
  • controlled execution;
  • transactional self-service;
  • customer-service systems;
  • conformance testing;
  • certification;
  • compatibility testing;
  • composition of new software systems;
  • redesign of business activity.

In other domains, a formal model may support planning, simulation, autonomous behavior, verification, certification, or specialized deployment to constrained systems.

The common asset is the model.

Its application can change.

Reuse Creates a Different Economic Structure

Traditional automation projects often create value once for one organization.

Reusable Glages Models create a different possibility.

one released Glages Model
→ multiple systems
→ multiple applications
→ multiple organizations or environments
→ repeated use
→ accumulated model value

For business-domain models, the reuse chain may be:

one released reusable process Glages Model
→ multiple business domains
→ multiple licensees
→ multiple software systems
→ multiple licensee implementations

For other Glages applications, reuse may occur across devices, tasks, software systems, simulation environments, verification systems, or autonomous platforms.

The exact commercial model may differ by application.

The underlying asset remains the reusable Glages Model.

The Model Library

The Model Library begins storing a Glages Model asset when it enters the Accepted lifecycle state and continues to retain that same asset after Release.

The Model Library may contain:

  • accepted and released Glages Model assets;
  • model versions and dependencies;
  • Program Acceptance results;
  • Model Adequacy evidence and determinations;
  • composition and specialization relationships;
  • analyzer and verification evidence;
  • tests and traces;
  • release records;
  • verified release packages;

Each accepted or released Glages Model asset can strengthen later production through reuse.

Model-production findings and generalized domain evidence can reveal missing states, incorrect relationships, unsupported assumptions, or opportunities for reuse.

The library therefore becomes more valuable as the factory produces more models.

The production methodology and the accumulated model library together form a central long-term asset.

Relationship to Experience Capitalization

Experience Capitalization is the intellectual origin of Glages.

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

Glages
→ generalized domain knowledge can be converted into explicit, reusable, machine-checkable Glages Models

Business-Domain Model Factory
→ released Glages Models can serve as reusable foundations for business processes, business domains, AI automation, and software systems

Experience Capitalization asks how knowledge and experience created through work can become durable reusable assets.

Glages applies that principle to formal computational models.

Glages applies the Experience Capitalization principle through generalized domain knowledge: binding and informative documentary evidence is converted into explicit Glages Models, while accepted and released model assets and factory verification evidence become reusable production capital.

What Is Being Developed

The Glages Model Factory Project is developing the technology, methodology, architecture, and model-production approach required to determine whether reusable Glages Models can be produced systematically across materially different domains.

The project includes work on:

  • formal model structure;
  • model-production methodology;
  • model verification;
  • reusable process and domain models;
  • model composition;
  • model specialization;
  • model libraries;
  • released specializations for defined application classes or computational constraints;
  • AI-assisted model production;
  • reduced dependence on runtime inference;
  • controlled execution;
  • model reuse across different systems and environments.

The project is intentionally testable.

Not every domain will necessarily benefit equally.

Not every type of knowledge will necessarily be economical to formalize.

A model factory is valuable only if useful models can be produced, verified, released, reused, composed, and specialized more efficiently than rebuilding equivalent knowledge separately for each application.

Who This Project Is For

Glages is relevant to people and organizations working on systems where explicit reusable formal knowledge may improve reliability, efficiency, verification, reuse, or computational requirements.

That includes:

  • AI and software companies;
  • autonomous-system developers;
  • robotics teams;
  • formal-methods and verification teams;
  • edge AI and constrained-compute developers;
  • research agencies and advanced R&D programs;
  • vertical-software companies;
  • system integrators;
  • enterprise software vendors;
  • product and platform teams;
  • technology investors and strategic partners;
  • organizations evaluating AI automation;
  • organizations developing certification or conformance systems.

Different groups may use Glages for different purposes.

The common question is whether important knowledge can be moved from repeated interpretation into explicit reusable formal structure.

Public Materials

The public articles on Experience Capitalization and Glages form one connected body of work.

Experience Capitalization establishes the broader idea that accumulated experience and relevant source material can be reconstructed into explicit reusable model assets. Glages develops a formal computational realization of that idea by converting generalized domain knowledge into explicit, machine-checkable Glages Models and by accumulating accepted and released model assets, verification evidence, Composition and Specialization knowledge, and release machinery in the Model Library.

The articles below present the current Glages corpus and the principal bridge from Experience Capitalization.

Foundational Glages Articles

  • Glages: A Different Kind of AI Model
    Glages defines a different class of AI model: explicit, machine-checkable formal models whose stable meaning can be inspected, verified, reused, and applied independently of probabilistic inference.
  • Glages: Scientific and Practical Foundations
    Research in formal planning, neuro-symbolic AI, executable knowledge, compiled AI, verification, and operational ontologies provides scientific and practical foundations for the Glages Model Factory.
  • Glages: Every Model Begins With Other Models
    Every reliable model inherits tested concepts, structures, and evidence from earlier models, then strengthens the system through further verification.
  • Glages: Structural Meaning Makes a Model Precise
    A Glages Model becomes precise through explicit machine-checkable relationships among facts, states, rules, actions, results, authority requirements, and boundaries.
  • Glages: The Human Is the Missing Model
    Many routine jobs exist because people supply the missing model that connects facts, rules, systems, decisions, and actions into a complete process.
  • Glages: The Missing Link Between Models and Automation
    Existing models become automation when a common activity model connects their meanings, boundaries, actions, results, and evidence into execution.
  • Glages: The Model Is the Automation
    Glages treats the formal model itself as the automation: the model defines the entities, facts, states, conditions, permitted actions, results, and boundaries that govern execution.
  • Glages: The Model Reveals the Automation Boundary
    A Glages Model makes the automation boundary explicit by showing what is modeled, what facts and actions are permitted, and where execution must stop or require clarification.
  • Glages: Why the Model Is Code
    In Glages, the model is typed code so compilers, analyzers, generators, tests, runtimes, and engineering tools can inspect and enforce its formal structure directly.

The Factory and Its Models

Reusable Process and Business-Domain Models

Uses, Boundaries, and Accumulation

  • Glages: One Model, Many Uses
    One released Glages Model can support requirements, readiness assessment, testing, controlled execution, self-service, verification, certification, product design, and other applications.
  • Glages: What Organizations Can Build on the Models
    Organizations can build applications, AI systems, automation, verification tools, interfaces, and domain products on reusable Glages Models while controlling their own implementation environment.
  • Glages: Business Results Are Part of the Model
    Glages Models represent business results separately from technical failures so outcomes such as declines, blocks, missing evidence, and unsupported requests retain their correct operational meaning.
  • Glages: The Agent Is a Replaceable Mechanism
    Glages keeps stable operational meaning in the formal model, allowing agents and other execution mechanisms to change without redefining the modeled business activity.
  • Glages: Models Become a Growing Capital Asset
    Glages turns completed formalization work into a growing capital asset as released models, tests, corrections, relationships, and verified structures accumulate in a reusable model library.

Experience Capitalization and Formal Models

Broader Glages Application Domains

Together, these articles present one continuous progression: Experience Capitalization explains why reusable model structure can become a durable asset; Glages develops the production technology for creating, verifying, reusing, composing, and specializing formal models; and the Business-Domain Model Factory and other application areas show how the same model-production approach can be applied across computational environments.

Who Is Behind This Project

The Glages Model Factory Project was developed by Alexander Granovskiy.

His professional background includes highly reliable technical systems, software development, e-commerce, payments, risk, marketplaces, infrastructure, integrations, automation, and daily business operations.

Across these environments, the same structural problem repeatedly appears: software can perform individual operations while people or runtime AI systems still supply much of the missing model that connects facts, states, rules, systems, exceptions, actions, and valid results.

Glages is a systematic attempt to move more of that missing structure into reusable Glages Models.

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 Glages, model production, research collaboration, 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

The practical starting point is not a larger runtime model.

It is identifying which knowledge a system repeatedly reconstructs and determining whether that knowledge can be represented as a reusable Glages Model.

A useful Glages Model should make the system's world more explicit:

what exists
what can happen
what facts matter
what conditions apply
what actions are valid
what changes are allowed
what results are possible
where the model stops

From there, a candidate Glages Model can pass Program Acceptance and enter the Accepted lifecycle state. Model Adequacy can then be established for that accepted model, after which package construction produces a candidate release package, package and integrity checks produce the verified release package, Release Eligibility determines whether the accepted model and package satisfy release requirements, and Release moves the model to the Released lifecycle state. Accepted or released Glages Model assets can serve as inputs to later Composition or Specialization, while licensees apply released models in their own computational environments.

**Glages converts generalized domain knowledge into explicit, reusable, machine-checkable Glages Models.

The Glages Model Factory Project develops the production system required to create, verify, release, reuse, compose, and specialize those models systematically.**
The model can then become a reusable computational asset rather than knowledge that must be reconstructed again at runtime.