> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/agent/universal-reasoning.md). # 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
Source-linked World Model views and agent and Context Graph definitions inform several decision procedures. Authorized tools execute under runtime-specific controls, and observed outcomes remain separate from accepted requests. The composition does not imply automatic routing among every model.

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](/agent/agents.md) supplies the role and interpretive perspective. The [Context Graph](/agent/context-graphs.md) describes the work. The [World Model](/data/world-model.md) supplies evidence. The [Reasoning Engine](/agent/reasoning-engine.md) 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](/platform-overview/core-concepts.md) and [Build and Prove a Workflow](https://docs.concurrence.com/developer-guide/guides/build-and-prove) for the implementation path; the [Glossary](/reference/glossary.md) 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](/agent/context-graphs/dynamic-behaviors.md) 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](/agent/reasoning-engine.md#design-direction-universal-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.
Design responsibilities for a universal processing engine: a cut policy forms bounded processing packets from signals, a consumer dispatch policy selects independent programs, and effect arbitration coordinates their optional intended outputs before channel execution. Observed outcomes are separate from proposed effects.

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](/agent/reasoning-engine.md#concurrency). ### 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](/agent/reasoning-engine.md#the-pipeline) documents current paths. The [Universal Reasoning Harness](/agent/reasoning-engine.md#design-direction-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](https://typesafe.ai/blog/introducing-system-one-models-and-jev) as a System One model for decisions inside software. The open [Laya project](https://github.com/NandhaKishorM/laya) 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](/data/world-model.md#evidence-facts-and-application-views) distinguishes source assertions, selected facts, and application views. [Platform Functions](/agent/platform-functions.md) 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](/agent/pattern-discovery-and-reuse.md) and [Deployment Model](/platform-overview/deployment-model.md). 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](/data/healthcare-interoperability.md) 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](/agent/reasoning-engine.md) for signals, effects, navigation, and current channel behavior. * [World Model](/data/world-model.md) for events, projections, provenance, and data access. * [Context Graphs](/agent/context-graphs.md) for authored problem definitions. * [Platform Functions](https://docs.concurrence.com/developer-guide/platform-api/functions) for supported computation and registration. * [Data to Verified Action](https://docs.concurrence.com/developer-guide/guides/data-to-verified-action) for an implementation path across evidence, tools, and outcomes. * [Verify an Integration Action](https://docs.concurrence.com/developer-guide/guides/verify-an-integration-action) for checking external completion. * [Evaluation Packet](/platform-overview/evaluation-packet.md) for evidence and acceptance decisions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/agent/universal-reasoning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.