Glages: Models for Autonomous and Robotic Systems

Autonomous and robotic systems operate under a different kind of pressure from ordinary software.

A robot, drone, mobile machine, or autonomous device may have to act with limited time, incomplete observations, limited computation, and real physical consequences.

The usual response is to make the runtime system more intelligent.

Glages suggests another direction:

Represent the stable structure of the permitted operational world explicitly, then let runtime systems determine the current state and act inside that structure.

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.

For autonomous systems, a Glages Model can define the part of the world in which the system is permitted to act.

Stable Formal Structure, Runtime State, and Execution Mechanism

A useful autonomous-system architecture separates three things that are often reconstructed together at runtime:

Stable Formal Structure
what kinds of things, states, relationships, processes,
actions, transitions, conditions, and Results exist

+

Runtime State
Contextual / Reference State:
the applicable modeled operating regime, environment,
capability profile, or parameterization

Case-Specific Runtime State:
what is true about the particular environment now

+

Execution Mechanism
perception, planning, learned prediction, control software,
external systems, or human-approved action

The Stable Formal Structure is fixed for a released Glages Model version and does not change from one observation to the next.

A warehouse may contain changing positions, occupied aisles, moving vehicles, open or closed access points, and objects that change state. But concepts such as Location, Package, Shelf, Route, Move, Pick, Place, permitted transitions, and stopping conditions can remain stable across many executions.

The runtime system therefore does not need to rediscover what these concepts mean each time it observes the warehouse.

Contextual / Reference State may establish a modeled operating regime, environment, capability profile, or other model-defined reference condition that applies across many observations, while Case-Specific Runtime State establishes the current facts of this particular environment. The system then determines which modeled action is valid now.

The Device Needs the Relevant Operational World

A warehouse robot needs the formal structure of the operational world relevant to its modeled tasks.

It may need formal structure for:

• locations;
• movement;
• access;
• obstacles;
• tasks;
• handoffs;
• object states;
• required observations;
• stopping conditions.

A drone inspection system may need a different model:

• mission area;
• permitted movement;
• target objects;
• observation states;
• environmental constraints;
• mission completion;
• abort or return conditions.

The useful question is how much of the relevant operational world can be represented explicitly enough that runtime intelligence can focus on establishing the current situation, proposing candidate actions, and operating within an already defined semantic structure.

Perception Establishes Runtime Facts

Physical operation requires observation because the current state changes.

A perception component may determine or estimate that:

• an object is present;
• a package is on a particular shelf;
• a location is blocked;
• a door is open;
• a target changed state;
• a route is available;
• a required condition was observed.

These are runtime facts about a particular environment.

They do not redefine the underlying model.

The Glages Model defines the fact contracts, possible states, transitions, actions, authority requirements where applicable, and validation conditions under which runtime facts and candidate actions have model-defined meaning. Perception, interpretation, planning, and other Execution Mechanisms produce candidate runtime facts, interpretations, predictions, or actions; model-defined validation and Execution Eligibility determine what can govern execution.

perception / interpretation
→ candidate runtime facts
→ model-defined fact / type / provenance / authority validation
→ current Runtime State

planner / learned mechanism
→ candidate action
→ model-defined action validation
+ current Runtime State
→ Execution Eligibility
→ Execute / Stop

A better sensor, a new vision model, a learned world model, or a deterministic recognizer can replace the previous perception mechanism without redefining the operational meaning of Package, Location, Blocked, Move, Pick, or Stop when the replacement satisfies the applicable model-defined role, input/output semantics, authority boundaries, validation obligations, and compatibility requirements.

The Execution Mechanism can change while the model preserves the meaning of the task.

Learned World Models Fit Inside the Same Architecture

A learned world model may be valuable when physical consequences are uncertain or difficult to calculate explicitly.

It may estimate what is likely to happen if a robot grasps an object, moves through a narrow space, changes speed, or applies a particular control action.

That capability belongs naturally in the execution and prediction layer.

The formal model serves a different purpose. It defines the operational world in which those predictions have model-defined meaning: the relevant entities, modeled states, permitted actions, required facts, allowed transitions, authority requirements where applicable, mission constraints, and stopping boundaries.

The two model classes are therefore complementary.

Glages Model
→ defines the permitted operational world

perception / learned state estimator
→ produces candidate observations or state estimates

learned world model
→ produces candidate consequence predictions

planner
→ produces candidate plans or actions

model-defined validation
+ current Runtime State
→ Execution Eligibility
→ governed execution / Stop

The learned component can become more capable without becoming the authority that defines the structure of the operational world.

Specialization Produces Reusable Model Classes

A Glages Model asset in the Accepted or Released lifecycle state may support Model Factory specialization.

Specialization is a production operation that derives a narrower candidate Glages Model.

The narrower model may represent, for example:

• a class of warehouse robots with narrower reusable formal behavior;
• a class of inspection missions;
• a regulatory scope whose binding constraints define narrower reusable model semantics;
• a reusable safety model for a defined class of systems;
• a mission class;
• another repeatable autonomous-system domain scope.

Model-defined operating regimes, capability profiles, environment classifications, and parameterizations that are already available within the released model are represented through Contextual / Reference State rather than requiring a new specialization.

The specialization result begins as a candidate Glages Model and becomes a released product only through the full Model Factory production lifecycle.

broader Glages Model asset in the `Accepted` or `Released` lifecycle state
→ specialization
→ narrower 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 (specialized model)

A specific recipient device, deployment, or mission configuration is downstream application, not a Model Factory specialization. The Factory produces reusable model products; the recipient applies them in a particular operating environment.

Bounded Action Matters More in the Physical World

A physical system should not invent a new action because the action seems reasonable.

A drone should not infer that an unmodeled area is probably acceptable.

A robot should not treat missing state information as permission to continue.

A released Glages Model can define:

• required facts;
• permitted actions;
• allowed transitions;
• mission Results;
• stopping conditions;
• unresolved states.

If the recipient system cannot resolve a required object, lacks a permitted route, cannot obtain a required observation, or encounters an unsupported state, the correct behavior may be to stop, hold position, return, defer, or request external confirmation.

The exact response depends on the model.

The important property is that uncertainty about the current state does not automatically become permission to invent new structure or behavior.

The Model Creates a Verification Boundary

A released model defines the semantic world available to software built against it.

Recipient software cannot silently add a new modeled state, operation, transition, or Result that the model does not define.

This provides a stronger boundary around autonomous behavior.

A perception system may be probabilistic. A planning component may search among alternatives. A learned world model may predict uncertain consequences. Their outputs retain candidate standing where they participate in governed decisions. The formal model defines the available semantic space, and model-defined validation plus Execution Eligibility determine which candidate actions can govern execution in the current Runtime State.

Release, Distribution, Deployment

The Factory produces and releases reusable Glages Models.

After release:

released Glages Model
→ Distribution
→ Recipient
→ autonomous-system application
→ particular deployment

The recipient decides how to apply the released model in a concrete device or system while preserving conformance to the model-defined contracts and Formal Model Interface.

That may involve local sensors, hardware, control software, communications, user interfaces, learned world models, and safety mechanisms.

Those implementation choices do not become Factory model content merely because they are necessary for one deployment.

Reuse Across Devices and Missions

The economic and technical value comes from reusable formal structure.

A model produced for a repeatable class of inspection missions may support many devices.

A safety specialization may support multiple products.

A regulated operating model may be reused across a family of systems.

The same released Glages Model can support multiple recipient applications while preserving one versioned model-defined operational meaning even when their sensors, planners, learned models, or control mechanisms differ.

Evidence From Deployments Has a Controlled Path

Real deployments may produce useful observations.

A deployment may reveal a missing reusable precondition, a domain-level transition, or a model boundary that deserves review.

That observation does not directly modify the released model.

If it appears to have reusable significance, it can be independently generalized into Domain Evidence for later Model Factory evaluation. A reproducible abstract case, where useful, participates as Informative Domain Evidence. Any resulting candidate model change must pass the full production lifecycle before it can become a new released Glages Model version.

This keeps the Model Library centered on Glages Model assets in the Accepted or Released lifecycle state and independently evaluated model evolution.

A Different Way to Think About Autonomy

Autonomy is often described as the ability to make more decisions without human intervention.

Glages suggests another measure.

A system becomes more operationally controlled when the Stable Formal Structure of its relevant world is represented explicitly, the applicable Contextual / Reference State and Case-Specific Runtime State are established, permitted actions are machine-checkable, and Execution Mechanisms operate inside those boundaries.

A Glages Model gives robotic and autonomous intelligence a formally defined, machine-checkable world in which it can act.