From configured software to composed software.

A request becomes a working screen without becoming generated application code.

A user might ask, “Build an intake screen with the patient’s latest A1C beside the medication list,” or, “Give claims reviewers a work queue with the denial reason and supporting documents.” The target is neither a mockup nor scaffolding for a developer to finish. It is a screen bound to real data, constrained by real permissions, and governed by the Framework’s existing runtime rules.

The language model proposes the rows that describe the screen. A deterministic validator checks those rows against the deployed component catalog, data contracts, commands, permissions, and metadata vocabulary. Only a sound proposal reaches an isolated preview, where an authorized person can evaluate it before anything becomes shared configuration.

The AI business module already exists; composition is the new layer being built.

ITSAI is a completed standard business module. It already provides governed model conversations, application-supplied context, controlled requests for additional data, multimodal input, conversation limits, token and cost awareness, and reusable agent surfaces. It is an available capability of the platform, not a future architectural layer.

The current work uses that capability together with several other mature parts of the Framework:

The difference is important. The AI module supplies the disciplined communication boundary with the model. The composer uses that boundary to create a very specific artifact: governed application configuration.

Generating configuration creates a smaller and safer output space than generating code.

Generated application code must be compiled, reviewed, packaged, deployed, and evaluated for everything unexpected it might do. A compiler can prove syntax and type compatibility, but it cannot prove that an arbitrary implementation matches the user’s request.

Configuration is more constrained. The model selects from a finite catalog of registered components and a known metadata vocabulary. The result can be verified by querying the same runtime contracts that will execute it.

Structural compatibility is deliberately narrower than business correctness. The machine can prove that the parts fit. A knowledgeable person still decides whether the resulting composition solves the right problem.

A deterministic gate stands between probabilistic output and the application.

No prompt can guarantee that a language model will never propose a missing, incomplete, or inappropriate element. The design therefore does not ask the prompt to be the safety boundary. A program evaluates facts that are decidable against the deployed environment:

• Every component alias must exist in the component registry.
• Every data source and field must exist, and the requesting user must be allowed to use it.
• Every command must exist and be valid in the proposed context.
• The parent-child tree must be acyclic, and each parent must accept the proposed child type.
• Metadata keys and values must be valid for the component receiving them.
• Rules, relationships, and parameters must resolve through supported Framework contracts.

A failed check becomes a precise correction rather than a vague rejection: the alias does not exist, the field is not part of the entity, the parent cannot host that child, or the user lacks the required permission. The model may revise the proposal within a configured attempt limit. It cannot bypass the validator.

Draft, preview, and promotion remain separate states.

Framework configuration is shared. Writing generated rows directly into the live metadata could expose a defective composition to every user who can open that module. Generation therefore targets an isolated draft area that implements the same contract as production configuration.

The existing screen builder can resolve its component tree from either source. A draft is consequently rendered through the real production engine, with the author’s actual permissions and an approved data context. The preview is not a picture or a parallel simulator; it is the proposed screen executing in isolation through the same code path that would render it after promotion.

The Framework was already shaped for composition before an LLM entered the design.

Configuration files alone would not make this approach possible. The necessary properties accumulated through years of building a data-driven application platform:

The initial target is clinical and health-administration variation.

Clinical systems are a meaningful test because they combine many entities, strict permissions, audit obligations, complex relationships, and continuous variation by specialty, payer, site, and jurisdiction. Encounters, orders, medications, results, allergies, authorizations, claims, eligibility, and care plans repeatedly appear in list, detail, queue, and relationship views.

The goal is not to claim present-day parity with mature EHR products or to manufacture decades of accumulated clinical content. The target is the expensive adaptation layer: allowing an authorized clinician or analyst to describe a needed arrangement, receive a validated real-runtime preview, and approve the result without starting every change as a conventional development project.

A request such as, “Show the latest A1C beside the medication list during intake,” can then become a proposal made from trusted controls and governed data rather than an unrestricted code-generation exercise.

The difficult boundary is knowing what the system can prove.

A composition can be structurally perfect and still solve the wrong business problem. Rules and context-derived parameters are also more consequential than passive layout: a subtle mistake may enable the wrong command or select the wrong records without producing an obvious rendering failure. The work therefore advances from composition toward rules and persistence with validation and review proportional to the consequence.

The component catalog is itself a production dependency. It must explain not only which controls exist, but when a relationship editor is more appropriate than two lists, when a pivot belongs instead of a grid, and which parameters each part requires. The catalog, validator, and deployed assemblies must remain versioned and checked together.