Independent components cooperate through shared protocols.

The parameter chain distributes context ownership.

A traditional form often assembles every command parameter in one click handler. That approach couples the form to every child control and makes the same command difficult to reuse from another context. In the I.T.S. Framework, the request begins with a list of required parameters and passes through layered contributors.

SC contributes current-user and security values. The form contributes window-level context. CtrlV contributes view identity. Toolbar fields contribute filters and options. CtrlG contributes current or selected rows. CtrlXBase contributes relationship context. Each participant marks the values it supplied, leaving unresolved requirements visible for later contributors or validation.

Components can reference one another while resolving context, so the chain carries an invocation trace. Before a participant is invoked, the trace determines whether it is already active in the same resolution path. That protection stops infinite recursion without removing legitimate collaboration between composites.

Validation projects runtime state into expressions.

Business commands depend on more than field validity. They may require exactly one selected row, no unsaved changes, a particular entity status, a permission, a nonempty working set, or a valid relationship context. Embedding those conditions in every button would produce duplicated rules that cannot explain themselves.

WFValidator projects row, grid, selection, form, and security state into variables available to configured expressions. A rule can evaluate those variables using the same expression semantics carried by the relational runtime. When state changes, the validator recalculates and the command surface reacts.

The result is not merely true or false. It is an MC value that identifies the rule and the user-facing reason. WFValidatorGrp aggregates validators across a composite such as CtrlXBase; WFValidatorView specializes the view case. The StatusValidator member exposed by controls and forms is a property typed WFValidator, not a separate validator class.

Failures occur when a projected variable is missing, a rule references the wrong type, or a composite fails to refresh after child state changes. Runtime diagnostics expose variable and validator state so maintainers can inspect the evaluated context rather than guess from button behavior.

MC unifies rule identity, language, interaction, and flow.

Applications often maintain separate identifiers for validation rules, resource strings, dialog icons, confirmation choices, and command return behavior. Those parallel systems drift: a rule changes but its message does not, or a translated message loses the decision semantics expected by the command.

MC uses one code as the shared identity. The code resolves user-facing text, localization, message style, dialog behavior, and whether processing should continue or cancel. MCExt supplies the operations that turn the code into an interaction rather than leaving callers to interpret integers independently.

A validator can therefore return an MC; a command can ask the same MC whether execution is allowed; a dialog can display the resolved localized explanation; and logging or diagnostics can retain the same identity. One contract crosses rule evaluation, user communication, internationalization, and control flow.

SC makes user context structural.

When security context depends on every screen remembering to add a user parameter, omission becomes a security defect. The framework instead places SC at the beginning of parameter resolution so every named request begins with current-user and governed context.

The context is represented in the same row-oriented runtime used elsewhere. It can supply identity, permissions, language, organizational scope, and other values required by contracts. Forms and controls consume that context without owning the authentication or lookup process that established it.

SC does not replace database authorization or claim that UI context alone is a security boundary. It ensures that application-level scope is carried consistently into every request while the database remains responsible for enforcing its own contract. Its failure modes are missing initialization, stale session context, or a named contract that fails to require the appropriate scope; these remain explicit operational concerns.

The cache degrades through layers instead of failing as one bucket.

A long-lived application shell repeatedly requests configuration, lookups, icons, definitions, and reference datasets. Re-querying and reconstructing those objects would make the runtime spend more time rediscovering stable information than executing business work. A single unbounded dictionary, however, would turn reuse into memory growth.

CacheITS coordinates specialized caches built from memory, dictionary, weak-reference, cleanup, and lifecycle policies. A request follows the fastest applicable tier; misses or expiry move it toward slower reconstruction. Occupancy and usage influence retention so heavily used categories remain responsive while less valuable items can degrade or be collected.

Components participate by requesting through the cache contract and by declaring category, lifetime, or cache eligibility rather than owning private dictionaries. Failure modes include stale policy, an invalid cache key, excessive retention, or caching state that should remain request-specific. FrmCacheStatus makes occupancy and expiry visible in the running application.

EvQueue treats event pressure as an architectural concern.

Windows Forms events can arrive much faster than the work they trigger should execute. Typing into a filter, resizing a composite, moving selection, or refreshing validator state can create bursts that repeatedly perform the same query, layout, or evaluation.

EvQueue derives from a generic EvQueueT<T>, allowing a delayed callback to carry a typed payload. Every Start stops and restarts the timer, collapsing a burst into one execution. The queue retains its owning Control, disposes itself when the control is disposed, checks that the control and handle remain alive before invocation, and tolerates disposal races.

DebounceIntervals is the calibration policy. The values are named by interaction category and cost, even when several currently share 150 milliseconds. That naming allows one category to be retuned later without hunting for numeric literals or changing unrelated behavior.

TPars provides an extensible metadata dialect.

Configuration schemas become rigid when every optional behavior requires a new column. Controls need to evolve with settings for style, layout, aliases, commands, filters, images, dimensions, flags, and relationships without forcing a schema migration for each addition.

TPars parses compact key-value metadata into typed parameters. Core code reads integers, booleans, colors, sizes, identifiers, aliases, and other values through one parser rather than duplicating string splitting and conversion. ExtTPar bridges those typed values into WinForms properties.

The mechanism is intentionally constrained: metadata describes variation supported by compiled components. It is not an unrestricted scripting language. Unknown keys, invalid values, and missing aliases must produce traceable defaults or diagnostic failures; complex behavior that the contracts cannot express still belongs in a new compiled component.