Runtime Operating Model

Blue models regulated operational software as three planes:

1. Declaration
2. Configuration
3. Execution + intelligence

The purpose is not to create another application server for every domain. The purpose is to define a common operating model where domain meaning is declared, site-specific variation is configured, and every request is executed through one explainable runtime.

Runtime loop

Requests in. Effects out. Logic in the middle.

Every source enters through the same protocol. The runtime resolves the declaration and configuration, evaluates the logic brain, writes durable records, and emits effects.

The Core Loop

The runtime shape is:

request in
  -> resolve declaration and configuration
  -> evaluate logic
  -> apply transactions
  -> emit effects
  -> produce records, projections, analytics, and interventions

Requests can come from UI, API clients, workflows, simulations, schedules, or agents. The runtime does not give each source a different execution path. It normalizes requests into query and action operations, evaluates the shared logic, and records what happened.

Effects are the output side of the runtime. A database write is an effect. Audit is an effect. An outbox event is an effect. A realtime signal is an effect. A dry-run record is also an effect. This lets simulation and execution share the same plan without pretending they are different systems.

Replay-Complete Execution

Every attempted action must leave enough durable, ordered, integrity-verifiable facts to explain and reconstruct its execution without consulting mutable current configuration. Results alone are insufficient. The execution envelope also includes actor and scope, immutable declaration and effective configuration identity, decision traces, snapshots, evidence manifests, domain events, effects, failures, and causal lineage.

The normative Execution Replay Contract defines the required envelope, evidence/event/effect boundaries, transaction rules, timeline behavior, and current conformance checks.

System Checks Across Planes

Blue can detect inconsistencies because each plane gives the runtime a different kind of evidence.

Moment	What it catches	Example
Declaration validation	Broken model structure	unknown fields, invalid refs, lifecycle ambiguity, duplicate invariants
System readiness	Declaration, configuration, and state gaps that would prevent the declared system from operating	a release action has no configured approver, a qualification ref is missing, a locked policy value is out of bounds, an external source binding is absent
Request preflight	This actor, payload, and scope cannot execute now	missing evidence, actor not in the actor set, policy denies this action
Execution integrity	Runtime loops, transaction conflicts, invariant failures	recursive outbox command, stale version, post-action invariant breach

The important distinction is that declaration can be valid while configuration is not ready. A plant may have a perfect model but no grant assignments, no qualified users, an unbound LIMS endpoint, or a policy value outside the declared range. That is a configuration inconsistency, and it should be caught by a system readiness report before a production request fails.

System readiness is not a one-time checklist. It is the runtime-facing report that repeatedly compares declared intent, effective configuration, and required state/data witnesses, then keeps surfacing the unresolved gaps until the system is actually ready to accept requests and produce the declared effects.

Invariants Before and After Actions

Invariant checks happen in both directions around an action.

Pre-action invariants run before the write is applied. They protect the transaction from starting when the current state is already incompatible with the declared rule.

Post-action invariants run after the candidate write set is materialized. For transactional invariants, this means after the database write effect has been staged, but before the transaction commits. If a post invariant fails, the transaction rolls back, the action record carries the failure, and outbox-backed external effects are not dispatched.

Some invariants are naturally deferred. Cross-system checks, projection settling, slow aggregate checks, or watcher-grade consistency can run after commit as problem-raising effects. Those should be explicit: the invariant tier should say whether it is an engine check, database constraint, database trigger, or watcher.

This gives Blue a clear model:

before action
  -> resolve declaration + configuration
  -> evaluate actor sets, policy, predicates, preconditions
  -> evaluate pre-action invariants

action
  -> lock rows
  -> stage database write effects
  -> stage audit/action-record effects

after action
  -> evaluate postconditions against candidate state
  -> evaluate post-action invariants
  -> write action record, failures/results, and outbox entries
  -> commit

after commit
  -> dispatch outbox effects
  -> publish realtime signals
  -> update projections/analytics
  -> run deferred watcher invariants

External integrations should not fire directly inside the business handler. They should leave through the outbox after the transaction is safely committed.

So there are two kinds of "after":

• After action, before commit: postconditions and transactional post-invariants. These can still fail the action and roll the transaction back.
• After commit: dispatch, realtime, projections, analytics, and deferred watcher checks. These should produce records, problems, follow-up actions, or alerts rather than pretending the already committed action did not happen.

Simulation and Effect Observation

Simulation should use the same request and effect plan as execution. The source changes, not the model.

ActionRequest(source: simulator)
  -> resolve declaration + configuration
  -> evaluate rules and invariants
  -> produce planned writes and effects
  -> mark effects as wouldApply
  -> produce a SimulationRecord / dry-run record

A dry run can show:

• which rules would pass or fail
• which configuration values were used
• which invariants would be checked before and after the action
• which rows would be written
• which audit records would be created
• which outbox events and realtime signals would be emitted
• which downstream actions could be triggered

This is useful for validation, change-control impact analysis, operator training, and agent planning. An agent can simulate a proposed intervention and show its effect trail before asking a human to approve the real action.

Debug and DevTools Layer

Blue should have a visible runtime debug layer: DevTools for regulated operations.

The debug layer should show the complete path:

1. incoming request
2. resolved declaration
3. resolved configuration and scope values
4. actor set and policy trace
5. predicate and rule results
6. pre-invariant checks
7. planned writes
8. post-invariant checks
9. planned runtime effects
10. committed records, outbox entries, and realtime signals

That view turns the runtime into an inspectable system. When an action is denied, the user can see why. When configuration is inconsistent, the admin can see which declaration it violates. When a simulation produces a surprising effect, the developer can inspect the exact rule, policy, invariant, or template that caused it.

Plane 1: Declaration

Declaration says what the system means.

It includes entities, fields, facets, relationships, lifecycles, actions, predicates, actor sets, invariants, evidence, audit posture, task templates, logs, checklists, and records. These are stable concepts that should not be rewritten for every plant, site, product line, or customer variation.

For regulated industries, declaration is where the defensible shape lives:

• what data exists
• which actions can happen
• which states are legal
• which records must be produced
• which invariants must always hold
• which evidence and audit trails are required
• which templates define recurring operational work

Declaration is the brain stem. Without it, the runtime becomes a pile of custom handlers. With it, the runtime can interpret many domains through one common execution model.

Plane 2: Configuration

Configuration says what varies by scope.

The same declaration may behave differently by tenant, site, plant, area, product, equipment class, role, or policy scope. Configuration covers policy values, IAM grants, group membership, qualification catalogs, training status, thresholds, calendars, assignment rules, retention rules, numbering masks, and master-data bindings.

Configuration should narrow and specialize the declaration. It should not silently invent new behavior. When a site changes a release policy, a cleaning frequency, an approval quorum, or a document review window, the runtime should still be able to explain which declared rule was configured, where the value came from, and why a request passed or failed.

This is also where system readiness belongs. A SystemReadinessReport can answer: is this plant ready to run the declared system? Are grants assigned? Are qualifications present? Are policy parameters valued? Are evidence sources bound? Are required master-data rows, state witnesses, external-system bindings, and evaluator registrations present? That is commissioning and governance, not the transaction gate itself.

Plane 3: Execution + Intelligence

Execution + intelligence says what happens next.

The execution runtime accepts query and action requests, resolves the effective declaration and configuration, evaluates preconditions, postconditions, rules, actor sets, predicates, policies, and invariants, then emits effects.

The same plane also powers intelligence because the runtime produces structured records, explanations, effects, projections, and timelines. Advisory systems and agents can use those facts without bypassing the governance model.

This enables:

• advisory next-best-action surfaces
• agentic interventions with approval and audit boundaries
• analytics and trend reports
• live operational dashboards
• exception queues and release readiness views
• generated log and checklist instances
• dry-run simulation of proposed actions
• realtime updates over committed record and outbox facts

An agent is not a privileged shortcut. It is another request source. It can query, propose, simulate, and request actions through the same protocol used by humans and systems.

Regulated Operations

Blue is first aimed at pharma and manufacturing because these environments need both flexibility and proof.

The same runtime pattern can cover:

Domain	What Blue gives it
HRMS	scoped roles, training status, qualification evidence, work eligibility
OMS	operational orders, assignments, execution status, exception handling, traceability
MES	equipment activity, production execution, IPQC checks, e-log style entries, LIMS-adjacent sample/result context
Asset management	equipment state, calibration, maintenance, qualification, audit
WMS	inventory movements, status transitions, holds, releases, traceability
Cleaning validation	equipment cleaning states, swab results, acceptance checks, rework
DMS	controlled documents, review cycles, effectivity, obsolescence
LMS	training assignments, competency, expiry, role qualification

The domains differ. The runtime loop does not have to.

What Blue Avoids

Blue should not reinvent a separate API server for every action. The API server is generated and driven from declaration. Query and action are the primary request surfaces. Subscriptions and realtime connections are delivery surfaces over records, projections, effects, and outbox state.

Blue should also avoid scattering DDL and transaction logic across domain handlers. The declaration plane gives the compiler and server enough structure to derive schemas, constraints, records, policies, routes, and explainable execution plans.

The long-term goal is a one-stop platform layer for regulated industries: templates, master data, transactions, audit, evidence, analytics, dashboards, reports, simulations, and agent-safe interventions, all flowing through one shared runtime grammar.