Glages: A Valid Model Is Not Yet a Product

A model can be completely valid and still not be ready for release. This distinction is central to the Glages Model Factory.

Program Acceptance determines whether a candidate Glages Model satisfies the formal validity requirements for entry into the Accepted lifecycle state. Product release requires another question: does the accepted model adequately cover the process class and scope it claims to represent?

Glages calls this second determination Model Adequacy. The distinction prevents a common category error: formal correctness is not the same as sufficient domain coverage.

A Formally Valid Model Can Still Be Incomplete

Imagine a Refund Model whose source compiles, whose Glages structure is valid, whose states are internally consistent, and whose Result contracts are well formed. Suppose, however, that the declared scope includes partial refunds and an applicable mandatory payment-network rule, while the model covers neither.

Nothing inside the model may be contradictory. The defect is what is missing.

The model may therefore be formally valid and still be inadequate for release as a reusable Refund Model product for its declared scope. That is not primarily a compiler problem; it is a Factory product-quality problem.

Program Acceptance and Model Adequacy Answer Different Questions

Glages separates the two gates explicitly:

Program Acceptance
=
formal validity

Model Adequacy
=
domain sufficiency for declared scope

Program Acceptance is deterministic under the defined language, model, and verifier conditions. Model Adequacy is established through an evidence set showing that the accepted model has sufficient coverage and competence for the declared process class and scope.

Without successful Program Acceptance, the candidate Glages Model does not enter the Accepted lifecycle state. Without Model Adequacy, an accepted model may be formally valid but still insufficient for its declared scope.

What Adequacy Evidence Can Include

Model Adequacy is established from an evidence set rather than from one undifferentiated source category. Domain meaning and coverage claims are grounded in applicable Binding and Informative Domain Evidence and, where relevant, Glages Model assets in the Accepted or Released lifecycle state. The adequacy process may also use generated coverage questions, verified scenario corpora, Passing and Failing Model-Verification Cases, factory tests and corrections, independent coverage review against documented Domain Evidence where useful, and Demonstration Runtime evidence. Those verification and production assets support evaluation, regression, diagnostics, and coverage testing; they do not independently establish domain semantics. LLM-generated material may support discovery, comparison, and coverage exploration, but it remains candidate production material rather than evidence authority.

For regulated scopes, the requirement is stronger. Model Adequacy must establish coverage of the binding laws, regulations, mandatory standards, governing protocol or network rules, and other mandatory external constraints identified as applicable to that declared scope.

Different model classes may use different evidence profiles, but the underlying principle is stable: release requires evidence of coverage, not compilation alone.

Normative Executable Models After Release

This gate matters because a released Glages Model is a normative executable model of a declared process class and scope.

The released model defines the formal structure software may rely on for that process class: concepts, relationships, states, required facts, rules, conditions, Input, Result, Output, declared operations, and stopping boundaries.

Recipient software built against the model is expected to remain within that semantic space. A strong normative claim therefore requires a disciplined release process, not merely code that passed analyzers.

After Release, the Model Defines the Normative Process Class

A recipient may operate differently from the released model. That difference can mean different things.

A difference observed in a recipient application can indicate a legitimate narrower reusable process class suitable for Model Factory specialization, a potentially reusable gap that should be independently reformulated as Domain Evidence for Factory evaluation, or recipient-specific behavior that remains outside the released model's executable scope.

This preserves the normative character of the model by keeping the released product centered on the executable formal structure of its declared class and scope.

Specialization Is a Factory Production Operation

Specialization starts from a Glages Model asset in the Accepted or Released lifecycle state and derives a narrower candidate Glages Model with reusable value. The derived candidate has its own identity and version and must pass its own production path:

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

Only then does the specialization become another released Glages Model product.

A recipient-specific deployment is application of an already released model. It is not itself a Factory specialization.

After Acceptance, Package Construction Prepares the Model for Release

Even an accepted model for which Model Adequacy has been established is not yet ready to distribute. The Factory constructs a candidate release package containing the model identity and version, the approved distributable representation, dependencies, a complete machine-readable candidate interface representation for the accepted model, verification identity, Model Adequacy evidence and determination metadata, compatibility information, documentation, and integrity information. That candidate interface representation is production material; after Release moves the model into the Released lifecycle state, it becomes the Formal Model Interface of the released model product.

The verified release package lets another party determine exactly which model and version the package represents, which dependencies it requires, which candidate interface representation has been verified against the accepted artifact, and which Program Acceptance result and Model Adequacy determination belong to the prospective release.

The package is therefore part of making the model durable as a product.

Package and Integrity Checks Protect Product Identity

The candidate release package is checked for completeness and internal consistency. The Factory verifies that required dependencies are identified, the package corresponds to the accepted model version, the complete candidate interface representation is included and consistent with that accepted artifact, compatibility information is attached, and integrity information is available. Successful package and integrity checks produce the verified release package used by Release.

The canonical relationship is:

Program Acceptance
+
Model Adequacy
+
package construction
+
package and integrity checks
→ Release Eligibility

Release Eligibility means that the production conditions required for release have been satisfied. Release is the separate production decision that moves the model into the Released lifecycle state.

Distribution Begins After Release

The downstream sequence is:

released Glages Model
→ Distribution
→ Recipient
→ Application

Distribution may include licensing, package delivery, version delivery, documentation delivery, and access to released artifacts. Recipient application begins after the released model has been delivered.

This boundary keeps the Model Factory focused on production and release of model products while allowing recipients to build many kinds of software systems, automation, verification tools, simulations, and other applications on top of them.

After Release, the Model Carries a Verification Boundary

A released Glages Model transfers more than formalized information. It defines the semantic space available to software built against that model version.

Software that assumes model concepts, facts, states, transitions, Result values, or declared operations outside the released structure fails Glages verification. The product therefore transfers:

formalized domain meaning
+
verification boundary

That is substantially stronger than delivering documentation alone.

Recipient Observations Have a Controlled Path to Model Evolution

Recipient applications may produce observations that appear to reveal a reusable gap. Those observations do not directly rewrite the released model.

The controlled path is:

recipient application observation
→ independently generalized Domain Evidence
  └── reproducible abstract case where useful as Informative Domain Evidence
→ independent Model Factory evaluation
→ candidate model change
→ Program Acceptance
→ accepted Glages Model
→ Model Adequacy
→ package construction
→ candidate release package
→ package and integrity checks
→ verified release package
→ Release Eligibility
→ Release
→ possible new released Glages Model version

This separation prevents local implementation behavior from silently mutating the common model. Model evolution remains a Factory production activity.

Why the Distinction Matters Commercially

A recipient should know exactly what release means. A Glages Model enters the Released lifecycle state only after Program Acceptance has moved it into Accepted, Model Adequacy has been established, package and integrity checks have produced the verified release package, Release Eligibility is positive, and Release has moved the model into Released together with that package.

A released Glages Model supports a more precise claim: the artifact is formally valid, its declared scope has been evaluated for adequacy, its package is complete, its identity and dependencies are explicit, and its Formal Model Interface is defined and its lifecycle state is Released.

This structure makes the model easier to license, maintain, compare, certify, version, and evolve.

The distinction can be summarized simply:

candidate Glages Model
→ Program Acceptance
→ `Accepted` lifecycle state

`Accepted` lifecycle state
+ positive Model Adequacy determination
+ verified release package
+ positive Release Eligibility determination
→ Release
→ `Released` lifecycle state
→ reusable model product

Glages inserts a production discipline between AI-generated candidates and released model products. That discipline is what allows the Factory to manufacture durable formal assets rather than merely generate plausible code.