Universal Reasoning and the Liquid World Model

How problem definitions, source-linked world-model views, exact programs, fast decisions, and deliberative models compose into a reasoning system.

Concurrence combines a shared data foundation with configured applications and agent workflows. The world model supplies source-linked context; agent and Context Graph definitions describe the work; supported runtimes and tools interpret requests and perform authorized operations. Agents are one consumer of that foundation, not its entire purpose. Applications retain responsibility for their own tasks, transactions, and completion records.

Universal reasoning names this composition across supported tasks and channels, not unlimited competence or a separate API resource. A workflow can combine exact computation, bounded classification, model interpretation, and authorized actions without assigning all of them to one model.

The central design principle is to use the least expensive procedure that meets the task's evidence and outcome requirements. SQL can answer a precisely specified data question. A classifier can recognize a familiar condition. An LLM can interpret an unfamiliar request or reconcile competing objectives. Software defines the boundaries within which those procedures operate.

This page explains the composition. Existing agent, graph, data, and tool contracts remain the authority for supported behavior. A general learned controller that chooses among all these procedures, automatically distills new policies, or optimizes measured entropy is a research direction, not an existing Platform API capability.

Four Parts of One System

These are composable responsibilities, not a mandatory sequence or a promise that every procedure is built in. A deployment chooses and evaluates the procedures its workflow needs.

Part	Question it answers	Responsibility
World model	What evidence is available, about whom, and from when?	Retain supported observations and derive scoped, source-linked views
Problem definition	What counts as useful, permitted, and complete?	Define objectives, states, evidence requirements, tools, and completion conditions
Decision procedures	Which interpretation or next step fits this situation?	Apply exact programs, rules, classifiers, or model reasoning
Execution runtime	What can run now, and what happened?	Coordinate signals, state, tool execution, channel delivery, and observable results

These are responsibilities rather than four mandatory serial calls. A signal can update context without producing a response. A known transition can avoid deliberation. A difficult case can require additional retrieval, a tool result, or a person before proceeding.

The Agent Core supplies the role and interpretive perspective. The Context Graph describes the work. The World Model supplies evidence. The Reasoning Engine coordinates the supported execution paths.

What You Configure Today

The architectural roles map to existing product objects. Their availability and execution rules remain specific to the selected API, runtime, and deployment.

Need	Configuration surface	Boundary
Define perspective and workflow	Agent versions, Context Graph versions, and state-tool bindings	Authored guidance steers the model; authorization and validation enforce permissions
Select deployed behavior	Services and version sets, including navigation and engagement model preferences	A version set can pin agent and graph versions; it does not freeze data, every tool, or channel behavior
Retrieve and compute	Registered Platform Functions and workspace data queries	Supported SQL, AI, Python, and table-valued computations are read-only; registration, loading, runtime, and bindings determine exposure
Change an external system or record an observation	Configured integration and dedicated write tools	A requested or accepted operation is not evidence of external completion
Add a specialized decision model	A separately implemented and evaluated integration	Jev and Laya are external examples, not built-in model options or announced integrations

A general learned controller, automatic policy distillation, and predictive world dynamics are research directions. None is required to build a workflow with the existing objects. Start with Core Concepts and Build and Prove a Workflow for the implementation path; the Glossary fixes the terminology used here.

Software Defines the Problem Space

A task is more than an instruction to produce text. It has an object of work, relevant observations, admissible actions, objectives, and a way to recognize completion. Those elements make a problem reviewable and testable.

For appointment rescheduling, the object is a specific appointment for a resolved person. Relevant evidence includes the caller's request, current availability, and booking state. Permitted actions depend on authorization and the configured workflow. Completion requires evidence from the scheduling system, not merely an agent saying that the appointment moved.

Context Graphs encode part of this problem definition through states, objectives, transitions, guidance, and tool bindings. Their intentional incompleteness leaves room for interpretation within the authored workflow. A graph can narrow the available actions without making model-driven navigation deterministic. Server-side permissions, validation, and approval controls enforce the boundaries that require enforcement.

Dynamic adaptation also needs an explicit owner. Dynamic Behavior sets are a Classic API mechanism for changing turn-level guidance and tool candidates. Platform services use conditional graph states, transitions, guidance, turn policies, and tool bindings. A broader background behavior selector belongs to the proposed reasoning harness.

The Broader Universal Processing Engine

Reasoning is only one responsibility in a continuously operating system. A universal processing engine is the broader architectural design: select which incoming signals belong together, dispatch eligible computations, and coordinate which intended effects may reach the outside world. A model call is optional; a visible response is optional. This term does not name another Platform API resource or claim that current runtimes implement one complete universal executor.

These are design boundaries, not a claim of one shipped pipeline across channels. Queue choice, worker layout, and packet concurrency can change without changing the responsibilities.

Three Policies, Three Different Decisions

Policy	Question	Boundary
Cut policy	When should a processing packet be formed, and which evidence belongs in it?	A packet is a bounded processing input, not necessarily one transport message. Forming it does not itself interrupt output or invoke a model.
Consumer dispatch policy	Which programs are eligible to consume this packet?	A packet can have no consumer or several independent consumers. A consumer can use code, rules, classifiers, decision models, or an LLM and need not emit an artifact.
Effect arbitration policy	Which proposed outputs may proceed, on which tracks, and under which conditions?	Priority does not override authorization, unmet dependencies, capacity limits, or relevance checks. Accepting an effect is not proof of its completion.

These conceptual policies are not interchangeable with the existing per-state TurnPolicy, tool-dispatch settings, or Classic Dynamic Behavior sets. Those resources implement particular controls with their own contracts; they do not expose the entire proposed policy system.

A simple text message can already be a complete processing packet. A more complex design may group a burst of related messages or align a transcript with separately derived acoustic annotations. Grouping changes what a consumer can interpret; it does not make an inferred meaning true. Packet formation should retain source, time, and missing-evidence distinctions rather than silently treating nearby signals as causally related. Fixed windows and intent-based boundaries require evaluation against the task, not one universal timing rule.

Coordinate Effects, Not Just Model Answers

An output track is a logical capacity and ordering boundary in this design. Foreground speech may allow only one active utterance, while independent tool work may proceed concurrently within a limit. Those are different scheduling requirements. Dependencies can connect tracks: a response may require a tool result, while an authorized control event may need to stop speech without waiting for that tool.

Independent programs should submit typed artifacts or intended effects through the agreed interface rather than race to mutate shared output state. Effect arbitration owns the applicable exclusivity, dependency, preemption, and capacity checks. A priority queue is one implementation option, not the architecture's defining property. Serial packet processing is another simplifying choice, not a requirement that all reasoning or tools run serially. Alternative implementations still need explicit ordering and concurrency guarantees for the resources they share.

Keep proposed output separate from reports of work already performed. Current effect types do not all mean deferred commands: some report an executed tool invocation. An adapter must follow the specific type's contract rather than execute such a report again. The general arbitration design does not retroactively make every current tool call pass through a new scheduler.

Consider an illustrative call: an availability lookup runs while the caller changes Friday to Monday. The cut policy determines the next relevant input boundary. Eligible consumers can interpret the correction and retrieve new options. Effect arbitration should prevent an obsolete Friday response from taking over the speech track merely because it finishes last. A separate authorized operator-takeover event may require stopping agent speech while the application retains the lookup's outcome. This is a design acceptance test, not a claim that every current runtime implements universal stale-work rejection.

Stopping playback does not undo a completed booking. Requesting cancellation does not prove that a worker stopped. A consumer's artifact, an accepted effect, an external submission, and a confirmed result therefore need distinct records. See the current concurrency boundaries.

Preserve the Contracts, Not One Implementation

Channel adapters translate supported inputs and outputs while retaining channel-specific authority, lifecycle, and delivery semantics. A phone call adds conference participation, takeover, and transfer concerns beyond an audio stream. Asynchronous messages add different persistence and recovery requirements. Shared World Model evidence can help authorized applications retain context across channels; it does not automatically merge sessions, transfer permissions, or make every channel appropriate for the same information.

Provider-owned realtime voice can remain a separate execution path when its available controls differ from this design. Compare the simpler supported approach with explicit orchestration on the actual workload: interruption handling, required tool controls, outcome verification, latency, operator effort, and total cost. More orchestration earns its place through those results, not through an obligation to build every box in the diagram.

The Reasoning Engine documents current paths. The Universal Reasoning Harness describes broader proposed execution ownership and context-validity controls. The distinction lets the architecture guide a rewrite without turning historical data structures or a target design into a product guarantee.

System 1 and System 2 Are Execution Roles

The System 1/System 2 analogy distinguishes fast, familiar decisions from more expensive deliberation. It does not identify an agent definition with a neural architecture or divide all model families into two fixed categories.

An authored agent is a semantic specification: the role, perspective, and guidance the system should apply. A fast policy or decision model can implement one bounded part of that specification. An LLM can supply deliberation, but it can also perform a simple classification or extraction. A deterministic rule can serve the same fast execution role without being a learned model.

Recent examples make this distinction concrete. TypeSafe presents Jev as a System One model for decisions inside software. The open Laya project describes typed decisions without autoregressive text generation. These are external examples of a useful component category, not announced Concurrence integrations or evidence that a particular model meets a healthcare workflow's requirements.

The question for a deployment is which procedure is appropriate for each decision, using the actual input distribution, failure costs, and operating constraints.

Procedure category	Potential role in a design	What still needs checking
SQL or ordinary code	Explicit joins, calculations, validation, and defined rules	Input semantics, freshness, null handling, access, and correctness of the rule
Rules or classifiers	Bounded routing, eligibility signals, or familiar categories	Coverage, false negatives, drift, and behavior outside the evaluated domain
Typed decision model	Choosing or scoring declared alternatives from context	Candidate completeness, calibration, abstention policy, and task-level error costs
LLM interpretation or deliberation	Ambiguous language, extraction, planning, and explanation	Grounding, missing evidence, tool permissions, and outcome verification
Human judgment	Exceptions or decisions requiring accountable review	Relevant evidence, ownership, and a usable handoff

An LLM need not mediate every step. Conversely, a fast model should not silently decide a case whose evidence, options, or consequences exceed its evaluated scope.

The World Model Is Liquid Through Its Views

Here, liquid describes a representation that can produce different, revisable views of shared evidence as tasks and observations change. It does not mean that facts lose their provenance or that every view refreshes instantly.

The same retained evidence can support several derivations:

• Deterministic projections select current entity values under defined precedence rules.
• SQL transformations join and aggregate facts for a particular task.
• Classifiers assign bounded interpretations where configured and evaluated.
• LLM-based extraction and memory processing produce source-linked interpretations that can remain incomplete or wrong.
• Application views select what a particular reader is allowed and needs to see.

The World Model distinguishes source assertions, selected facts, and application views. Platform Functions provide supported read-only SQL, AI, Python, and table-valued computations. Applications and dedicated write tools own authorized mutations.

Reproducible deterministic derivation requires fixing all relevant inputs, configuration, and logic, including evaluation time for time-relative fields. For example, an upcoming-appointment indicator can change when recomputed later even if no appointment event changed. Retained events and a projection version alone do not guarantee identical output. This does not establish a general historical replay API or make an LLM-generated narrative deterministic. Source-class confidence determines precedence in supported projections; it is not a calibrated probability that a statement is true. A confident interpretation cannot promote itself into authoritative evidence.

This operational world model also differs from a learned simulator that predicts future states under hypothetical actions. Predictive models could become additional derived products, but source-linked state and workflow execution do not establish learned causal dynamics by themselves.

Entropy Stratification as a Design Discipline

Entropy stratification means allocating freedom and computation according to the uncertainty and consequence of a particular decision. It is a design discipline, not a documented runtime setting or a claim that the platform measures one universal entropy score.

Separate three things:

1. Uncertainty about the situation. Evidence may be missing, stale, contradictory, or unfamiliar.
2. Freedom in the action space. Several responses may be acceptable, or only one operation may be permitted.
3. Consequence of an error. Two equally uncertain decisions can warrant very different controls.

A missing appointment preference can justify a clarification. Uncertain authorization requires an authorization check, regardless of how confident a classifier sounds. An urgent exception can require escalation without waiting for extensive deliberation. More uncertainty does not always mean granting the agent more freedom.

Where a distribution over named outcomes is available, information entropy can help characterize ambiguity. It should not be computed from source-precedence constants or treated as a substitute for measured error rates, probability calibration, consequence, novelty, and freshness. Low entropy can describe a confidently wrong model.

The practical rule is to make exact work explicit, evaluate fast decisions within their operating region, and spend additional retrieval or reasoning when it can change the decision enough to justify its cost. Preserve abstention and human handoff when the requirements cannot be met.

One Request Through the Composition

Consider a synthetic request: "Move my visit to Friday afternoon. I cannot get there in the morning."

Step	Contribution	Evidence required to continue
Interpret	The agent's role and language model identify a scheduling request and preference	Resolved subject and the correct appointment; ambiguity remains explicit
Define the task	The graph selects the relevant workflow and eligible tools	Workflow scope, permissions, and required verification
Read	A supported query or tool obtains relevant context and availability	Appropriate freshness and source; absence is not proof of no appointments
Decide	Rules, a validated classifier, or model reasoning narrow the next step	Valid alternatives and enough evidence for the specific decision
Act	An authorized operation requests the change	Required confirmation and target-system result
Observe	The application records the result and reports it accurately	Accepted request, external completion, and projected visibility remain separate

This is an architectural decomposition, not a claim that the native runtime currently routes scheduling through Jev or Laya. A real deployment must use its supported tools and validate its actual channel behavior.

If the availability result is stale, the system needs a fresh check. If the booking call times out, it needs reconciliation before an unsafe retry. If the person changes the request while work is pending, the application must check whether the result remains relevant. A convincing response cannot repair these missing mechanisms.

Improving the Blend

Improvement first requires an observable workflow. An intake conversation, a follow-up form, and an externally confirmed appointment are connected work with separate execution and outcome records. A useful evaluation identifies the agent and graph versions, the actual tool and data-view definitions, the evidence available, where a failure occurred, and who owns recovery. This is a recommended trajectory contract, not a claim that every current channel exposes a complete connected trace.

Engineers need execution detail, operators need an understandable account of what happened, and business owners need defined outcome measures. Permissioned drill-down should connect these views while preserving data access boundaries. Comparing workflow versions requires comparable cohorts and reliable measurement; it does not by itself constitute a clinical study or prove a patient benefit.

Repeated tasks can reveal work that is suitable for a narrower procedure: a calculation becomes SQL, a stable condition becomes a rule, or a recurring bounded judgment becomes a classifier. Treat each change as a new implementation. The responsible owner should review the exact change and its validation evidence before release. Agent and Context Graph versions can be pinned; Platform Function definitions are replaced in place, without native versions or aliases. Preserve the reviewed definitions and recovery steps for functions and other non-versioned settings in the release record. A model-generated candidate rule is not automatically safe to deploy. See Continuous Improvement and Deployment Model.

Compare the complete workflow against simpler alternatives, including ordinary software and a single-model baseline. Measure accepted outcomes, costly mistakes, abstentions, data freshness, latency, and cost per accepted outcome. Exercise contradictory evidence, unseen inputs, revoked permissions, delayed tools, duplicate requests, and external failures. Component accuracy alone cannot establish system reliability.

Fit the Existing Data Environment

Shared context earns its setup cost when several workflows need the same authorized evidence, identity mapping, or transformation. A narrow task may be better served by a direct integration. Assess the complete setup and operating cost rather than requiring every task to pass through a new data foundation.

Declarative transformations make semantics reviewable and can help teams carry definitions across their existing data platforms. Portability still requires checking SQL dialects, identity assumptions, permissions, data types, and freshness. Transport support is a separate capability: a parser, an event store, and an operational connector with acknowledgements and recovery are different parts of an integration. See Healthcare Interoperability for the current boundary.

Customer records and public or licensed external data can inform a richer application view when access and intended use permit. Shared representation does not authorize pooling data across customers. Identity resolution, purpose, source permissions, and permitted reuse must be established for the specific sources and readers.

This is the connection between universal reasoning and a liquid world model: representations can evolve, and computation can specialize, while evidence, authority, and completion remain explicit. The useful unit of improvement is a verified workflow outcome.

Continue Reading

• Reasoning Engine for signals, effects, navigation, and current channel behavior.
• World Model for events, projections, provenance, and data access.
• Context Graphs for authored problem definitions.
• Platform Functions for supported computation and registration.
• Data to Verified Action for an implementation path across evidence, tools, and outcomes.
• Verify an Integration Action for checking external completion.
• Evaluation Packet for evidence and acceptance decisions.