From Configured Software to Composed Software

1. What We Are Building

The request may sound ordinary: “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.” What opens afterward is not a mockup and not scaffolding for a developer to finish. It is a screen bound to real data, constrained by real permissions, and governed by the framework’s real rules.

The mechanism is configuration generation. A language model emits a proposal containing the rows that describe the screen. A deterministic validator checks those rows against the live component catalog, data contracts, commands, permissions, and metadata vocabulary. If the proposal is sound, the framework builds the screen exactly as it builds every other configured screen.

Plain-language request
        ↓
Model proposes configuration rows
        ↓
Deterministic validation against the live system
        ↓
Isolated preview through the production runtime
        ↓
Human approval and transactional promotion

The distinction between generating code and generating configuration is the point. It is what separates a compelling demonstration from an operational product.

2. Why Configuration Generation Is Different

Language models are useful code-writing partners when a developer has an editor open. Turning generated application code into an end-user product feature is harder for structural reasons.

Generated code must be compiled, reviewed, packaged, and deployed. Its output space is effectively unbounded, so review must consider not only whether the code works but also everything unexpected it might do. Reversing a change normally means reverting source, rebuilding, and redeploying. A compiler can prove that code is well formed; it cannot prove that the resulting screen matches the user’s intent.

When the screen is data, the control surface is much smaller:

Code generation	Configuration generation
Compile, package, deploy, and release	Validate and insert rows
Unbounded output space	Finite catalog of registered components
Review by reading arbitrary code	Validate references and structure by querying
Revert through source and deployment	Revert by withdrawing promoted rows
Compilation proves syntax and types	Validation proves structural compatibility before rendering

That last distinction is deliberately narrow. Structural compatibility is provable. Whether the composition solves the right business problem is not. The architecture is valuable because it can state exactly where machine certainty ends and human judgment begins.

3. The Deterministic Gate

A language model is probabilistic. At some rate it will propose something incomplete, nonexistent, or inappropriate. No prompt removes that fact. A serious product therefore needs an answer to one question: what catches a wrong output before it reaches a user or touches production configuration?

Here, the answer is a program. The configuration references facts that either exist or do not:

• Does every named component exist in the component registry?
• Does every referenced data source exist, and may the requesting user read it?
• Does every referenced command exist, and is it available in this context?
• Is the parent-child tree acyclic, and does each parent accept the proposed child type?
• Are the metadata keys and value types valid for the component to which they are attached?
• Do the proposed fields exist on the entity being displayed or edited?

Those questions are decidable against the same live system that will render the result. The model proposes; the validator disposes.

A failed check is not merely a rejection. It becomes a precise, machine-readable correction: no component is registered under that alias, the named data source does not exist, or this field is not part of the selected entity. The message returns to the model for bounded revision. Propose, reject with cause, revise, and stop after a configured limit.

The model never writes to the system. It writes a proposal. A deterministic program decides whether that proposal may become real.

4. Why This Framework Specifically

Many applications have configuration files. That alone is not enough. Five properties make I.T.S. Framework a suitable substrate, and all five existed before language models were part of the design.

The screen is already data

A screen is a tree of rows resolved at runtime. The framework walks that tree recursively, instantiates registered controls, obtains the configured data, and binds the result. There is no separate AI rendering path and no build step between changing valid configuration and changing the screen. The generator proposes what an experienced configurator would otherwise enter.

The component vocabulary is finite and named

Reusable components are registered under short aliases and resolved by the runtime. The model cannot invent an arbitrary WinForms control or event handler; it selects from a catalog of known parts with documented capabilities and parameters. That reduces the output space from anything expressible in C# to a structured composition of trusted components.

Behavior is declared, not improvised

Rules are expressions evaluated against row, grid, selection, user, and runtime state. Command availability follows those rules. Parameters are collected through a layered context chain in which each participant contributes what it knows. A composed screen can therefore be interactive and rule-governed without generated event handlers.

The data model is discoverable at runtime

The database is the authoritative contract. A DataSet carries related tables, each DataTable carries tabular schema and rows, and each DataRow is the runtime entity bound directly to the WinForms UI. The composer can ask which fields exist, which types they carry, and which lookups or relationships apply. Grounding and execution consult the same contract, so they cannot silently drift into separate models.

The system can inspect itself

Dataset explorers, cache inspectors, component documentation, configuration traces, and explanations for disabled commands exist because a data-driven UI cannot be debugged only by reading source code. Those capabilities now serve another purpose: an automated process can compose a screen, open it through the real engine, inspect what the runtime resolved, and verify expected behavior. The loop can close on evidence.

5. Draft, Preview, Promote

Configuration is shared. Writing a generated screen directly into live metadata could expose a bad composition to every user with access to that module. Generation therefore targets an isolated draft area with the same contract as production configuration.

The screen builder can resolve its component tree from either source. A draft consequently renders through the real engine, against the author’s real permissions and an approved data context. Preview is not a visual approximation; it is the proposed screen running in isolation through the same code path that will render it after promotion.

Draft configuration  →  validate  →  preview in real runtime
                                              ↓
                                      authorized review
                                              ↓
Shared configuration ← transactional promotion

Promotion is separate, deliberate, permission-controlled, and transactional. The reviewer has seen the composition working before it becomes shared. The promoted rows are versioned or otherwise traceable so the change can be withdrawn without rebuilding the application.

For regulated work, that sequence is the control: no model proposal becomes shared merely because it passed structural validation, a person approves what other users will receive, and the promoted configuration remains auditable and reversible.

6. Why the Target Is Clinical

The meaningful test for a platform claim is a domain with enough variation to expose weak abstractions. Clinical and health-administration systems provide that test.

Structurally, an electronic health record and its surrounding workflows contain thousands of distinct entities: encounters, orders, results, medications, allergies, problems, immunizations, referrals, prior authorizations, claims, eligibility, and care plans. Each has fields, states, validation rules, permissions, relationships, and audit obligations. Each appears in lists, detail editors, work queues, and relationship screens. Then specialty, payer, site, and jurisdiction multiply the combinations.

This is not only a feature problem. It is a variation problem. Historically, much of that variation has been absorbed through implementation labor: consultants configure a deployment, developers customize it, or both. The cost and delay can leave clinicians working inside software shaped by what was practical to implement rather than by the workflow they actually need.

Clinical-system demand	Framework response
Many entities needing list, detail, workflow, and relationship screens	Compose screens from a catalog instead of writing each one independently
Recurring regulatory and operational field changes	Change the authoritative schema and governed configuration without a UI code release
Variation by specialty, payer, site, and jurisdiction	Represent deployment variation as data without forking the application code
Relationships across encounters, orders, plans, policies, providers, and members	Configure reusable relationship engines for each contract
Audit obligations across many entity types	Attach shared history and audit capabilities through configuration
Contextual rules that change often	Evaluate governed expressions against runtime state
Strict access control and data residency requirements	Run the application beside the data and send the interactive client rendered pixels rather than database records

The last point is specific to the deployment model. I.T.S. Framework executes on controlled Windows application servers close to SQL Server, and users connect through RDP or RDS. The interactive endpoint receives pixels, keyboard input, and mouse input rather than a public HTTP API carrying an application data model.

That does not automatically authorize clinical data to be sent to an external model. AI features still require an approved provider and hosting arrangement, minimum-necessary context, user-scoped permissions, appropriate agreements, audit trails, retention controls, and the option to keep sensitive fields out of the prompt entirely. The runtime boundary reduces one class of exposure; it does not erase the governance obligations of another.

7. The Honest Comparison

Claiming parity with mature EHR products today would be false. Those systems contain decades of accumulated clinical content: order sets, documentation templates, decision support, interface libraries, certification work, operational knowledge, and the compliance apparatus around them. That body of work is enormous. Architecture alone does not replace it, and a language model cannot simply generate it into existence.

What is comparable is the structural problem. A costly part of a major clinical deployment is adapting a shared product to the way a particular organization works. When more of that variation can be expressed as governed configuration—and configuration can be proposed by a model, validated by a program, previewed in the real runtime, and approved by a clinician or authorized analyst—the economics and cadence of adaptation can change even while the clinical-content problem remains.

This framework does not make us Epic or NextGen. It is an attempt to make continuous adaptation of trusted components less dependent on one-time implementation labor.

A clinician saying, “I need intake to show the latest A1C next to the medication list,” is normally submitting a change request. Here, that request can become a proposal, a validated preview, and an approval—with a deterministic gate between the model’s suggestion and any shared clinical workflow.

8. What Is Actually Hard

Three difficulties should be explicit from the beginning.

Structural validity is not semantic correctness

A composed screen can pass every mechanical check—components exist, the tree is sound, fields are real, and permissions are respected—yet still solve the wrong problem. Only a knowledgeable person, or an acceptance test written from that person’s requirements, can catch that. Preview and approval are not optional ceremony; they are part of the correctness model.

Rules are harder than layout

Composition is close to mechanical. Rule expressions and context-derived parameters carry semantics across components. A subtle error may produce no visible failure; it may simply enable a command that should remain disabled or select the wrong record set. Layout and passive composition should arrive first. Rules, commands, and persistence require tighter validation, stronger tests, and review proportional to their consequence.

Grounding must be exact and current

The model needs more than a list of component aliases. It needs curated guidance about when to select a relationship screen instead of two lists, a pivot editor instead of a grid, or a search control instead of a combo box. That catalog is a production input. If its documentation drifts from the runtime, composition quality degrades quietly. The catalog, validator, and deployed assemblies must therefore be versioned and checked together.

9. The Operating Boundary

The active I.T.S. Framework desktop runtime and its desktop modules target .NET 10 for Windows. The production stack includes Windows Forms, ADO.NET, DataSet/DataRow, and SQL Server 2025. It is designed to run on application servers close to SQL Server while users work through RDP or RDS. Within that controlled environment, direct binding and database-driven contracts are deliberate choices.

That topology may run on premises, in a private cloud, or on AWS or Azure. SQL Server may be local to the environment, hosted on a cloud virtual machine, or supplied through a compatible managed service. Latency, security, integration, feature compatibility, data residency, and operational requirements determine the fit.

This pattern should not be generalized unchanged to a public browser application, an offline client, an untrusted network, or a system that requires an independently versioned public API or domain contract. Those environments need explicit transport and authorization boundaries. A configuration composer may still produce artifacts for them, but its validator and promotion model must respect their different runtime architecture.

Related Reading

Continue with the runtime and AI foundations that make this composition model possible.

• The AI Layer of the I.T.S. FrameworkSee how the model receives governed context, requests controlled data, and operates through bounded provider seams.
• The I.T.S. Framework Component ArchitecturePlace composed screens inside the .NET 10 runtime, DAL, metadata-driven UI, and business-module layers.
• Entity ManagementSee how reusable editors, relationships, properties, permissions, and metadata already compose operational screens.