Aether

Aether in Module Suite 4.1.0¶

Introduction¶

Aether is the Module Suite service that runs every Generation run. In Module Suite 4.1.0 (Polaris), CARL, the AI Form Builder, the Component AI Builder, the Content Script editor, and Application Builder send their generation requests to Aether. Aether turns a natural-language request into a Module Suite artifact: a Content Script, a form, a Shell component, a smart page, a workflow, or an Application Builder manifest.

One create or refactor request from an editor is one Generation run. Aether owns that run from the starting snapshot to the published version. It picks the model, grounds the run on approved knowledge, validates the result, and waits for a person to review it before anything is published.

Aether is a SaaS service

Aether is delivered as a SaaS service. An on-premises deployment of Aether might be available in a future release.

Configure Aether first

The AI Form Builder, the Component AI Builder, CARL, and Application Builder do not generate without Aether. Configure Aether before you use these editors.

This page describes what Aether does for the editors and what a developer or administrator configures. For the full detail of model selection, the Content Server API dictionary, environment context cards, client tool approval, and limits, see Generation runs in Module Suite 4.1.0.

What Aether does¶

Runs every generation as one durable run. The run keeps its state and its events, and can pause for the editor and resume.
Resolves the model. An editor sends only the id of the model the user selected from the list of models AnswerModules offers in Aether, or nothing for Auto.
Grounds the run. A run reads the Content Server API dictionary that the host supplies, approved evidence from the knowledge corpus, and any environment context cards the user picked.
Validates deterministically. Code, not the model, compiles, lints, checks schemas, packages, and publishes the result.
Keeps humans in charge. A validated candidate waits for review. Only an approved run is published, and every publication creates a new version.
Counts token use per tenant. Token use is counted for the tenant that started the run.

Architecture¶

Aether sits between the Module Suite editors and the model providers. The editors run on Content Server and on Module Suite Runtime (MSR). Aether calls the model providers, and it keeps the runs, the knowledge corpus, and the tenant data.

flowchart LR
    subgraph CSHost["Content Server"]
        CARL["CARL"]
        CSEditor["Content Script editor"]
        AIFB["AI Form Builder"]
        CAIB["Component AI Builder"]
        AppB["Application Builder"]
    end
    subgraph MSRHost["Module Suite Runtime"]
        MSREditor["Content Script editor"]
        MSRBuilder["Component AI Builder"]
    end
    CSHost -->|"Generation runs"| Aether["Aether"]
    MSRHost -->|"Generation runs"| Aether
    Aether -->|"Model calls"| Providers["Model providers"]
    Aether --> Store[("Runs, knowledge corpus, tenant data")]

An editor starts a run and follows its events. The approved result goes back to the host that asked for it: a new node version on Content Server, or a new immutable artifact version on Module Suite Runtime.

Party	Role
Editors on Content Server	Start Generation runs, answer pauses (such as the API dictionary request and environment context card reads), review, and publish to Content Server
Editors on Module Suite Runtime	Start Generation runs for artifacts served by MSR, and publish them as new MSR artifact versions
Model providers	Serve the model calls of each attempt

What Aether keeps:

Runs: each run with its starting snapshot, its attempts, its ordered events, its pending actions, its review, and its publication records. A plain Content Script keeps only its Groovy source as node content on Content Server; the transcript, the generation and validation metadata, and the published version reference stay in Aether.
Knowledge corpus: the curated, reviewed, versioned knowledge that runs consult. See Knowledge corpus.
Tenant data: tenants, their token use, and the Content Server API dictionaries their hosts supplied.

Aether is separate from the Content Script API

The list of models AnswerModules offers in Aether is not configured in a Content Script profile. The llm and openai Content Script services and their profiles are configured separately. See LLM services.

Tenants and authentication¶

A tenant is the owner of Generation runs. Aether uses it to keep tenants apart and to count token use. Aether is a SaaS service: all customers use one Aether, and their tenants are separated inside it.

The Module Suite editors connect to Aether on behalf of your tenant, and AnswerModules provides the tenant when Aether is enabled for you.

Configuration¶

On the Module Suite side¶

Content Server can narrow the models that its editors offer. Set this parameter in the Base Configuration :

Parameter	Where	Description
`amcs.aether.allowedModels`	Content Server	Ids of the models, from the list AnswerModules offers in Aether, that the editors show in their model picker. The editors filter the picker with it. A display filter of the model picker

Not a spending limit

amcs.aether.allowedModels only filters the picker. Tenant quotas apply across all models, so Module Suite 4.1.0 has no enforced per-model spending limit.

Model selection¶

Auto or a selected model¶

An editor either leaves the selection on Auto or sends the id of a model from the list of models AnswerModules offers in Aether. Auto is the default and is always available. On Auto, Aether uses the model configured for that kind of run. A selection is accepted for content-script, form, shell, smart-page, and workflow runs. Manifest planning, manifest generation, and script repair always keep the configured model.

The choice is kept on the run when it starts, and retries and repairs reuse it. A new run, including a follow-up that continues the conversation, uses the editor's current choice.

Aether rejects an unknown model with 400 unknown_model and a model the run cannot use with 400 model_not_available_for_recipe. The editor then resends the same request once on Auto and tells the user, so the prompt is not lost.

Tenants, models, and token use¶

flowchart LR
    Tenant["Tenant"] --> Run["Generation run"]
    Allowed["amcs.aether.allowedModels on Content Server"] -.->|"filters the picker"| Picker["Editor model picker"]
    Catalog["Models AnswerModules offers in Aether"] --> Picker
    Picker -->|"modelId or Auto"| Run
    Run --> Provider["Provider and model"]
    Run --> Usage["Token use"]
    Usage --> Count["Counted for the tenant, by session, provider, and model"]
    Count --> Quota["Tenant quota, across all models"]

Token use is counted for the tenant that started the run, and recorded for the session, the provider, and the model. Tenant quotas apply across all models.

The Generation run lifecycle¶

A Generation run executes one recipe: manifest, content-script, form, shell, workflow, or smart-page. The recipe prepares a workspace. A model attempt edits all affected files together. Deterministic code then validates and packages the result, and the run waits for review and publication.

flowchart TD
    Intake["Intake: create request, model choice, attachments"] --> Preparing["preparing"]
    Preparing --> Generating["generating: one fresh attempt"]
    Generating -->|"NeedsKnowledge"| Knowledge["needs_knowledge"]
    Knowledge -->|"approved evidence"| Generating
    Generating -->|"NeedsInput"| Input["needs_input"]
    Input -->|"user answers"| Generating
    Generating -->|"Answered"| Answered["answered"]
    Generating -->|"Candidate"| Validating["validating"]
    Validating -->|"invalid"| Repairing["repairing"]
    Repairing --> Generating
    Validating -->|"valid"| Review["awaiting_review"]
    Review -->|"rejected"| Rejected["rejected"]
    Review -->|"approved"| Approved["approved"]
    Approved --> Publishing["publishing"]
    Publishing -->|"retryable failure"| Approved
    Publishing --> Published["published: new version"]
    Generating -->|"Failed"| Failed["failed"]

Each attempt starts fresh and ends with one outcome:

Outcome	What happens
Candidate	The result is validated. An invalid candidate starts a focused repair attempt
NeedsKnowledge	The attempt ends with one focused query. Aether retrieves approved evidence and starts a fresh attempt
NeedsInput	The run asks the user one question and continues with the answer
Answered	The run ends with an answer and no change. Offered only to a Content Script run opened by the Content Script editor, where the request may be a question about the script
Failed	The attempt ends with a reason. A retryable failure can be resumed

What a developer should know about the lifecycle:

Review before publication. Only awaiting_review accepts a review, and only approved publishes. A publication failure that can be retried returns the run to approved.
Retry and Start over. A retry of a retryable failure starts a new attempt from the files of the last attempt, not from the original starting snapshot. Start over creates a new run and keeps the old one in history. Automatic transient retries may run up to twice before the run rests in failed.
Interruption by an Aether update. When an update of Aether interrupts an active attempt, the attempt is marked interrupted and the run becomes retryable. A new attempt never restores a provider conversation.
Events. The editor follows the events of the run while it works. The run state in Aether is the authoritative state.
Package. A generated package includes chat.json, generation.json, and validation.json.

Compile without generation¶

The Compile button of an editor validates and packages the current files without a model attempt. It does not change your source.

Attachments¶

A run can attach files, such as a mockup, a scanned form, or a Word document.

Constraint	Value
Accepted types	PNG, JPEG, GIF, WebP, PDF, DOCX
Files per run	4
Size per file	10 MB

The declared type is checked against the content of the file. A refused file fails the request with 400 invalid_attachments. Attachments are inputs to the run, not part of its artifact, and are kept for a few hours only.

Knowledge corpus¶

The knowledge corpus is the curated, reviewed, versioned store of Content Server knowledge that a Generation run consults. The corpus is global for every tenant. In Module Suite 4.1.0 it includes category attribute type codes and a document-categorization agent.

The corpus is organized in items, each with revisions, sections, and blocks. An item is a concept, a reference, a guide, an index, or an example.
Only the active approved revision of an item can be found.
An example marked as a template can seed a run: when the starting script is empty, Aether starts from a structural template chosen for the target and the kind of change.
The evidence a run uses is recorded on the run, so the generation trace shows which items, revisions, and sections were read.

For the retrieval rules, see Knowledge corpus.

Generation trace¶

Each run keeps a trace of the model, the knowledge it used, and its tool calls, so the result can be reviewed.

Availability¶