CSM-1: Utilizing Dart's Clinical Simulation Machine for Petabyte Scale Health System Data

Executive summary

For as long as health systems have had data warehouses, one problem has had no solution: nobody can tell whether a number is right. An analyst writes a query for "patients admitted today," a dashboard displays it, a committee acts on it — and whether it used the right encounter class, the right timestamp, the right deduplication rule, or the right join is a matter of institutional memory. Agents that write SQL made it faster to produce such numbers. They did not make it possible to check them. The reason is structural: production data cannot tell you whether an answer is correct, because production data has no answer key.

CSM-1 gives it one. Starting from nothing more than the institution's data as it exists and a stated goal, it builds a digital twin — a structured, versioned set of artifacts that encode what every table, column, and metric means and how the data came to look the way it does — and then verifies that digital twin by running a simulation through it: a synthetic run that shares the production schema, reproduces production's defects, and knows the true answer to every question because it generated the data. The digital twin is the model: run forward, its own artifacts produce the simulation. Accuracy becomes an exact, measurable quantity; every failure is attributable to a specific artifact; every repair is durable and compounds across all future questions. What was an unmeasurable problem becomes a measured one, and a measured problem can be driven to zero.

CSM-1 runs in three modes: training mode, offline, where the digital twin is constructed and verified; serving mode, where the Conversational Suite answers real requests against it; and continual learning mode, which runs alongside serving and feeds what it learns back into training. The method behind training mode is Sparse Context Training. Messy, undocumented, heavily customized data is the expected starting condition, not an obstacle. Whatever context exists — a handful of dashboards, some reports, query logs — is decomposed into reusable primitives and amplified; where it does not exist, the data's own shape, thirty days of observing how the institution actually operates, and simulated analysts dreaming the questions nobody has asked yet supply what documentation never did. The result is a digital twin far larger than anything the institution could have written by hand, in which every entry carries the evidence that produced it and a measured confidence.

The digital twin is consumed by the Conversational Suite in serving, where every answer carries lineage and a predicted accuracy. A continual learning mode reads how it is used, surfaces the knowledge worth keeping for a simple approve-or-reject decision by the institution's own data team, and caches what is approved. One machine serves an institution, pointed at one use case at a time by the goal placed in context, writing what it verifies into a single, growing digital twin — and because the improvement loop can only move in one direction, it is safe to run unsupervised. The entire cycle runs on zero patient data. This paper applies CSM-1 to data analytics; the architecture is general, and other workflows are the subject of companion papers.

Why the problem has been unsolvable

Three properties of health-system data have defeated every approach so far:

1. Semantics are implicit. The same concept — an encounter, a charge, a provider — is keyed, coded, and timestamped differently across the EHR, revenue cycle, ERP, and warehouse. The correct interpretation lives in existing reports and in institutional memory, not in the schema.
2. There is no ground truth for ad hoc questions. Production data cannot tell you whether an answer is right. Published KPIs cover a small fraction of the question space, and even those are contested across departments.
3. The cost of being wrong is asymmetric. A confident wrong number in a clinical or financial context destroys trust in the entire product. Health systems will not adopt a tool that cannot say which answers are verified.

Every prior category of tool addresses one facet and leaves the center untouched. Data catalogs describe what exists; they do not say what it means. Semantic layers encode meaning, but by hand, and with no way to test it. Text-to-SQL agents generate answers faster, with nothing to check them against. Synthetic data generates records for testing software, not for verifying meaning. Process mining discovers how work flows, and stops there. Scaling model reasoning at answer time makes each answer slower and more expensive without giving the model anything new to check against. The missing ingredient in all of them is the same: verification, and verification requires a place where the right answer is known.

The breakthrough: Sparse Context Training

CSM-1 builds that place. The move is to stop treating the semantic layer as something to be written and start treating it as something to be trained — against a simulation where the right answer is known by construction, until the digital twin covers far more than the input context ever described. Sparse Context Training starts from the condition every data leader actually faces: the data is a mess, little is documented, the few reports that exist are not trusted, and the department asks ten thousand distinct questions a year. It treats the data's own shape as context, treats whatever artifacts exist as bundles of reusable decisions rather than prerequisites, and uses the simulation to explain the mess, verify compositions no report ever displayed, and dream the questions nobody has asked. The result is a digital twin that is dense where the department asks and explicit about the evidence behind every definition. Four mechanisms, each necessary:

Four properties follow that no prior approach has had together. Accuracy is exact: the simulation's ledger makes every answer gradeable, so the digital twin is driven toward zero error rather than toward "good enough." Verification is broad: a primitive verified once is trusted in every composition that uses it, so a few hundred verified primitives cover thousands of questions. Improvement is one-directional: the improvement loop keeps a change only when it strictly improves and reverts everything else, so the digital twin cannot silently get worse — which is what makes an unsupervised agent safe to leave running. And the whole cycle is offline and PHI-free: it runs in training mode, before any real question exists, on a simulation that contains no patient, so the compute is spent where the answers are checkable and the institution's risk is nil.

What CSM-1 creates: five kinds of definitions

The output of training mode is a digital twin, and a digital twin is made of definitions — what a case is, when an admission counts, how contribution margin is computed, which timestamp means what. Most of the definitions CSM-1 produces are ones the institution never had in written form. The distinction that matters is not whether a definition is new but where it came from and how it was tested. CSM-1 creates definitions from evidence. Each of the five kinds below is derived from evidence, verified where the right answer is known, and carries its evidence and its confidence tier with it into the digital twin.

Two properties hold across all five. First, provenance is structural, not documentary: a definition's origin, the evidence that supports it, and every test it has passed are fields on the node, read by the confidence model and shown to the user with the answer. Second, ownership is the institution's: no definition of any kind is promoted into the digital twin without passing the simulation, and no contributed definition is promoted without the data team's approval. The digital twin that results is larger than anything the institution could have documented by hand, and every entry in it can say why it is there.

Architecture overview

Figure 1. The engagement definition is a first-class input alongside the data assets: it sets what the digital twin is for, who will use it, and what success means, before any crawl begins. Every access to customer systems — training or serving — passes through the governor. Heavy evaluation runs in the simulation, which the system owns, never on the warehouse. Serving query logs re-enter discovery, so the digital twin improves on the questions people actually ask.

Focus runs: one machine, pointed at one use case at a time

CSM-1 is not deployed as separate copies per department. There is one machine and one institutional digital twin, and the architecture is toggled on per use case by the goal placed in context. A focus run begins with an engagement definition such as "focus on understanding the ED mechanics of this system: arrivals, acuity, boarding, and the handoff to inpatient" and that statement scopes everything downstream. Discovery weights the ED's tables and dashboards. Archaeology mines the ED's artifacts first. The simulation's generative nodes emphasize ED processes — arrival patterns, triage, bed requests — while keeping the rest of the institution present at low resolution so the handoffs are real. The backtest is the ED's live dashboards. The improvement score is weighted by ED question volume. When the run promotes, its nodes land in the shared digital twin tagged with the focus they were verified under.

Inheritance follows one rule. Substrate nodes — physical and mapping — are group-agnostic and verified once. Semantic nodes are tagged with the group they were verified under and are served only to that group until they pass the new focus's evaluation set; a join path verified under ED questions is not assumed correct for perioperative ones. The next focus run — perioperative, then revenue integrity — starts from that digital twin rather than from nothing. It inherits every substrate primitive already verified, re-verifies the semantic nodes it touches under its own questions, and adds its own. Where two focus areas use the same word for different things, the ontology holds both meanings as distinct concepts with their focus recorded, and the end agent resolves which one applies from the user's role and the question. Coverage grows use case by use case, and the amplification ratio compounds: each run starts with more primitives than the last.

Figure 1b. The goal in context toggles the whole architecture onto one use case. Each focus run inherits what earlier runs verified, scopes discovery, simulation, backtest, and improvement loop to its goal, and promotes focus-tagged nodes into the single institutional digital twin. Substrate — connectors, governor, physical inventory, the institution's own master patient index and terminology services — is built once and shared by every run.

Customized systems: nothing is assumed from a vendor template

No two health systems run the same system, even on the same vendor. Custom tables and extension fields, locally built flowsheets and order sets, department-specific ETL, homegrown code sets layered over standard ones, and relationships that exist only because someone built them a decade ago are the norm, and they are where generic semantic tools break, because those tools start from a model of what the vendor's schema is supposed to look like. CSM-1 starts from what is actually there.

Three properties of the architecture make this hold. First, the physical layer is built from the institution's own catalog, statistics, and profiled shape — not from a reference schema — so a custom table is discovered the same way a standard one is, and a relationship is inferred from key integrity and co-occurrence whether or not any documentation mentions it. Second, novel structure is treated as a question to answer rather than an exception to route around: an unfamiliar table, an unexplained join, a field that behaves differently by department becomes a provenance hypothesis, simulated until a mechanism reproduces what production shows, then written into the digital twin as a discovered definition. Third, the ontology anchors to standards where a local concept has a standard counterpart and creates a first-class local concept where it does not; nothing is forced into a template it does not fit. Every customization the system relies on is also a claim in the assumption register, so what CSM-1 believes about a local structure is confirmed against production, not inferred and forgotten.

The practical consequence is that the digital twin reflects the institution's system as built, including the parts nobody can fully document, and the parts that are unique to it are tested with exactly the same rigor as the parts that are standard.

Training · discovery and artifact archaeology

Training mode takes two kinds of input. The first is the customer's data assets. The second, defined with the customer before anything runs, is the engagement definition: the objectives the digital twin must serve (close the month faster, explain a variance, size a service line), the users and roles who will consume it (a CFO, a perioperative director, a quality analyst, a nurse manager) with the questions each actually asks, the constraints that apply (stakes, freshness, governance, warehouse envelope), and what success means. Users are modeled the way a population simulator models audiences — each role becomes a profile of question types, vocabulary, and tolerance for error — and those profiles do three jobs: they seed the anticipated query set alongside what archaeology mines from artifacts, they set the pre-registered acceptance criteria, and they supply the weights for the build-mode score described below. A digital twin that is perfect on questions nobody asks is not perfect.

Discovery crawls schemas and profiles every column, producing the physical layer and a mess profile: measured rates for the data's defects that the simulation will later reproduce. How the profile is built matters, and is covered below.

Artifact archaeology treats existing dashboards and reports as compiled knowledge. Each one is decomposed into the join paths it traverses, the filters and business rules it applies, the metrics it computes, and the questions it exists to answer. A surgical-case profitability dashboard, for example, reveals how OR log records connect to cases, charges, and cost centers; that cancelled cases are excluded; and how contribution margin is defined at this institution. Those become candidate nodes with provenance and a confidence score.

Figure 2. Artifacts are evidence, not truth. Two dashboards frequently define the same metric differently; the conflict is surfaced and classified. A mistake — stale logic, a broken filter — is adjudicated by freshness, usage, and owner confirmation. A legitimate difference — finance and quality counting census differently — is kept as two variants of one concept, each tagged with its group; access control decides which variant a user is served, and the engagement definition sets the default per role. Both paths are verified in the simulation before promotion.

Anomaly-seeking profiling

Uniform sampling finds the common case. The defects that break definitions — the 0.1% of encounters with merged identifiers, the charges posted before service — are rare, and a sample sized for the governor will not contain them. Profiling therefore runs aggregate-first: counting queries designed to measure defects directly, then samples drawn only from the strata where a count came back non-zero.

Samples are then stratified by partition × time × anomaly class — a few hundred rows from exactly the orphan encounters, the duplicate keys, the out-of-order charges. Context steers the probes: a dashboard filter that excludes a status value marks a column hiding a special case; the data dictionary and steward queue mark known problem areas. Profiling also flags fields that look clean but may not mean what they appear to — near-constant values, defaults that dominate, columns no artifact has ever used, usage that diverges sharply by department — and any definition that reads a flagged field inherits the flag until an owner clears it. Every probe's cost is logged against the governor envelope.

Sparse Context Training in detail: how the seed becomes the digital twin

The floor is the data and a goal. Everything above it — dashboards, reports, logs, a data dictionary — is an accelerant. Whatever exists is decomposed into primitives, attached to canonical concepts, composed into a question space far larger than the input, and verified at scale in the simulation; where artifacts are absent, the data's own shape, provenance hypotheses, and dreaming carry the load.

Figure 2b. Sparse Context Training. The seed is the data and a goal; artifacts are optional accelerants. Whatever exists is decomposed into primitives, attached to canonical concepts, composed into a combinatorial question space, and verified at scale in the simulation. The schema contributes context the artifacts never contained; the engagement definition keeps growth pointed at demand.

Two numbers make this legible to a skeptic. The amplification ratio is verified distinct questions divided by seed artifacts — from eighteen dashboards, how many questions can now be answered with lineage and a confidence tag. And verified coverage is the share of the department's actual question volume, taken from logs and the engagement definition, that falls inside the verified digital twin. Both are reported on the learning curve alongside the digital twin score; neither is optimized directly, because a loop aimed at coverage would learn to answer easy questions. The score stays the objective; amplification is what the objective produces.

Training · reconciliation and mapping

This is where semantic accuracy is won or lost. The same patient, encounter, or provider is keyed differently across systems; codes are local, versioned, or mixed; timestamps mean event time in one table and posting time in another; duplicates and orphans are the norm. Above the mapping table sits the ontology layer, which anchors canonical concepts to OMOP with FHIR resource names as aliases, so concept mapping begins from a standards prior rather than a blank page. Reconciliation starts by reusing what the institution already maintains — the enterprise master patient index, terminology services, and any data dictionary — and resolves only the gaps. It produces an explicit mapping table in which every mapping carries its evidence, a confidence score, and a status. Mappings that remain ambiguous after evidence is exhausted go to a human review queue, but the queue is deliberately slim: questions are ranked by leverage — how many downstream nodes or how much question volume a single answer unblocks — and only asked when the ambiguity is real and the leverage is high. A steward should see a handful of questions a week, each of which settles ten or more nodes, not a backlog.

Figure 3. The mess model is the bridge between reconciliation and the simulation: whatever defects profiling found in production are reproduced synthetically, so a digital twin that passes in the simulation has been tested against realistic mess, not clean data.

Convention resolution: finding the institution's definitions, not guessing them

The simulation verifies that a definition is executed correctly. Whether a definition is the one the institution actually uses — admission per inpatient order, per ADT event, or per midnight census — is a separate question, and CSM-1 answers it with evidence rather than by asking. For each semantic node the convention resolver generates the candidate conventions, scores each, and selects. Four sources of evidence, in descending weight:

1. External anchors. Much of what looks like local convention is standardized: CMS, NHSN, AHRQ, and payer definitions fix census, length of stay, readmission, and observation status. Where an anchor exists, the candidate that matches it starts with the highest prior, and a measured deviation from the anchor is recorded as a finding rather than silently adopted.
2. Cross-metric reconciliation. A convention makes predictions about other numbers. If admission means inpatient order signed, then census × average length of stay must reconcile to patient-days on the finance report, and admissions × average charge to gross revenue. The resolver treats the institution's published numbers as a system of constraints and scores each candidate by how many it satisfies within tolerance. The convention that makes the institution's own numbers agree across departments is the one it uses.
3. Artifact frequency and provenance. How often a candidate appears across dashboards, reports, and query logs, weighted by the freshness and ownership of the artifacts it appears in.
4. Behavioral confirmation. Which candidate the institution acts on: the dashboards signed off, the reports filed with regulators, and, once in service, which definitions users accept versus correct in the Suite.

The selected convention is written into the node with its score and the evidence behind it, and the ledger computes expected answers under that convention. The simulation's 100% therefore means: the digital twin implements the institution's definitions, as resolved from evidence, without execution error. Where the resolver's top two candidates are close and no anchor or reconciliation separates them, the node is one of the few that goes to the steward queue — and it goes with both candidates and their scores, not as an open question. A definition with no external anchor, no reconciliation constraint, and no dashboard is, by construction, an institutional decision rather than a fact the data can settle — what counts as a cancellation for the periop committee, whether an affiliate transfer is an admission — and it is labeled as one. These are a small share of the digital twin and they arrive at the department's owners together, with candidates attached, so they are closed in a sitting rather than discovered one at a time.

Training · the simulation

The simulation plays three roles. It is an instrument: it grades the digital twin against a ledger where every right answer is known. It is a lab: it tests hypotheses about why production data looks the way it does. And it is an explorer: given a goal and the schema, it dreams the questions the department has not asked yet, tries them, and builds and verifies nodes for the ones the digital twin cannot yet answer. The third role is what lets CSM-1 start from a department with three dashboards, or none, and still arrive at a digital twin worth trusting.

The simulation is built from the production DDL verbatim — same tables, columns, types, and constraints. What fills it is the important design choice. The simulation does not copy or perturb production rows; that would carry PHI and would only ever reproduce the past. Instead, the simulation is generated by executing the digital twin itself. The digital twin's generative nodes — the physical structure as SQL, the process rules as text (how an encounter opens, how a charge posts, how a case is scheduled from the floor), the clinical and revenue workflows as flowcharts, the confirmed provenance mechanisms — are run forward with the rates the mess profile measured: which traits move together (encounter class × length of stay × payer × discharge disposition; case type × supply consumption × charge timing), how often, and with what defects. Synthetic patients, providers, encounters, charges, claims, and supply events are produced as complete, internally consistent records. There is no separate generator to build or tune; the model is the digital twin, and the ledger is what falls out of running it.

This gives the digital twin two kinds of nodes with different rules. Generative nodes describe how data comes to exist — substrate, mechanisms, process rules — and change only when a provenance hypothesis is confirmed on production or the change sentinel finds drift. Interpretive nodes describe what data means — definitions, conventions, join paths for answering — and are what the improvement loop refines. The improvement loop runs against a frozen snapshot of the generative nodes, so the thing being graded can never adjust the thing doing the grading. This is the isolation rule stated in terms of the digital twin itself.

This matters because semantic errors hide in the joints. A simulation can match every one-way distribution — the right share of inpatient encounters, the right average charge, the right duplicate rate — and still be wrong in ways that let a broken metric definition pass. A "patients admitted today" rule that mishandles observation-to-inpatient conversions will only fail on a simulation where those conversions occur with realistic timing relative to charges and orders. So the generative nodes are calibrated at two resolutions at once: each sampled record must be a plausible journey through the institution's processes, and the population of records must reproduce the production profile — marginals, the joint distributions that metrics slice by, and the measured defect rates from the mess model.

Figure 3b. The simulation is produced by running the digital twin's generative nodes forward, not copied from production. Calibration checks both that individual records are plausible and that the population matches the production profile, including joint structure and defect rates. Matching one resolution without the other is a known failure mode.

Every sampled fact is also written to a ground-truth ledger. The ledger is what makes the simulation useful: for any evaluation question — how many patients were admitted on a given day, what the contribution margin was for a given service line — the answer is computed from the ledger under the node's resolved convention, and it is known exactly because the simulation produced the data. The evaluation set combines the anticipated queries from archaeology, metric templates derived from the semantic layer, and deliberate edge cases (midnight boundaries, cancelled-then-reinstated cases, charges posted after month close). No patient data is involved at any point.

Time as a third resolution

Health data is rewritten after the fact: charges are reversed, encounters merged, diagnoses recoded after review. "Revenue for March" has one answer on April 2 and another on April 20, and any definition with an as-of clause is untestable on a simulation that was generated once and never edited. The generative nodes therefore emit a timeline, not a snapshot: base events plus correction, reversal, merge, and late-arrival operations, at the rates the temporal probes measured in production. The ledger records the answer to each evaluation question as of each point on that timeline. A definition is verified when the digital twin reproduces the as-of answer, not just the final one. The same discipline governs the backtest: each dashboard tile is reproduced as of its own refresh timestamp, with tolerance bands derived from the measured refresh-lag noise, so timing differences are never attributed to the digital twin as defects — and the improvement loop is never pushed to "repair" a correct definition to chase them.

Provenance hypotheses: mimicking the environment, not just the schema

Matching the production profile is necessary but not the point. The simulation's deeper job is to work out why the institution's data looks the way it does, because the digital twin has to encode those mechanisms to be right in production. Real data carries oddities that no schema explains: an OR in-room timestamp that is identical to the ADT transfer timestamp for a subset of cases, medication strings that arrive in three formats depending on the ordering pathway, charges whose posting date clusters on the second business day of the month. Each oddity is a question about how the record came to exist. The simulation answers it by simulation: propose a handful of candidate mechanisms, generate under each, and keep the one whose synthetic output reproduces the observed pattern. The surviving mechanism is then confirmed against production — a targeted query through the governor, or a tile on a live dashboard — and written into the node's context so the end agent knows, for example, that the OR timestamp is inherited from ADT when the case was scheduled from the floor.

Figure 3c. The simulation as a mechanism-testing instrument. Candidate explanations for a data oddity are simulated, the one that reproduces the observed pattern is confirmed on production with a single cheap query, and the explanation becomes part of the digital twin. This is how the generative nodes are kept honest to the institution's environment rather than to their own assumptions.

Training over a long horizon: thirty days of observation

Everything in the simulation so far can be built from a single reading of the data. A single reading, however, can only infer how the institution's data behaves — how often a charge is reversed, how long an encounter takes to finalize, when the finance close lands — from timestamps left behind in the rows. CSM-1 does not rely on that. Training mode runs over a thirty-day horizon, and during it the agent observes: the anomaly strata drawn during profiling are re-sampled daily, each sample is versioned, and consecutive versions are diffed. What was inferred becomes measured.

Four artifacts come only from observation, and each closes a gap the snapshot left open.

• Mutation rates, observed. Diffing versioned samples shows rows arriving late, changing, reversing, and merging as they happen. The timeline generative nodes are calibrated from these observed rates rather than from timestamp forensics, and the assumption register gains a stronger evidence tier: a process claim that holds across thirty consecutive snapshots is observed, not merely probed.
• Completeness curves. For each table, the fraction of its eventual rows present at one, three, seven, and fourteen days after the event date. Charges are 60% complete the next morning and 98% after five business days; ADT is complete within hours. This is unobservable from a snapshot, and it is exactly what "how many patients came in today" depends on. The curve feeds the confidence tag directly: a question about yesterday's revenue carries a lower predicted accuracy than one about last month's, for a measured reason.
• The operational calendar. Month-end close, batch load windows, dashboard refresh schedules, shift-change ADT peaks, weekend and holiday patterns. Thirty days captures a full close cycle and four weekends. These become generative nodes, so the simulation runs on the institution's actual rhythm, and the backtest reconciles each tile against its observed refresh events with observed lag noise.
• Change cadence and drift baselines. Schema deployments and code-set updates that land during the window teach the agent how this institution changes. The sentinel's drift bands are calibrated from a real baseline before go-live rather than set by hand.

Figure 3d. Observation over the horizon. Daily versioned snapshots of the anomaly strata are diffed to measure how the data behaves; the measurements recalibrate the generative nodes nightly, promote register claims from probed to observed, and give the confidence tag a measured basis for time-sensitive questions. Improvement sessions run on each night's regenerated simulation.

Observation is read-only and stays at the metadata and sampled-strata level; the warehouse's own load logs and audit tables, where they exist, supply mutation history at almost no cost. Spreading probes across thirty days of off-peak windows lowers per-hour load while raising total information. Nor does the horizon delay first value: archaeology and dashboard reconciliation happen in the first days, and the improvement loop typically converges within two weeks; observation continues past that point to harden the generative nodes and to capture the close cycle, and a digital twin promoted at day thirty rests on a simulation that has watched the institution for a month.

From data behavior to business behavior

Observation was introduced as a way to measure how data behaves. Its larger consequence is that data behavior is the trace of business behavior, and thirty days of watching records move is thirty days of watching the institution operate. A cancellation is not a row; it is a transition — a status flip, sometimes a new case linked to the old one by a field nobody documented, sometimes coded as a no-show in one department and a cancel in another. Turnover, first-case on-time starts, block release, documentation lag: each is a business event that exists in the data only as a pattern of changes over time. A single reading cannot see them. An agent monitoring the flow can, and what it finds becomes business context the digital twin did not have.

The mechanism is the same one that discovers provenance. Transitions observed across snapshots are assembled into the actual state machine of each process — the states a surgical case passes through, the time distributions between them, the hazard of cancellation at each stage by lead time, all of it per service and per surgeon where the counts support it. These are recorded as generative nodes, and that closes a loop the paper has been building toward: monitoring discovers business context; business context makes the simulation more faithful; a more faithful simulation verifies more of the digital twin, including the behavioral definitions that were previously out of reach. Each pass through the loop raises the fidelity of the simulation and the coverage of the digital twin together.

Figure 3e. The monitoring loop. Observed transitions become process models and recording artifacts; both become generative nodes; the simulation they produce verifies behavioral definitions that a snapshot-calibrated simulation could not, and the newly answerable questions point monitoring at what to watch next.

Process behavior versus recording behavior

The most common way a behavioral metric goes wrong is that it measures how people document rather than how they work. A surgeon whose turnover times look long may simply have a team that enters in-room times in a batch at the end of the shift. Monitoring catches this directly — the timestamps for that surgeon's cases arrive together, hours after the events — and records it as a provenance mechanism on the relevant nodes. The metric is then either corrected or served with a flag that says why it should not be compared naively. This is the distinction a perioperative director cannot make from a dashboard and the one that makes surgeon-level comparisons contested; the digital twin makes it explicit, with evidence.

What the simulation can then do

With process models as generative nodes, the simulation carries per-entity variance, so dreamed questions at the behavioral grain — cancellation rate by lead-time bucket by service, a surgeon's on-time starts against the service median with case-mix held constant — are verified with the right denominator and the right attribution rules for primary versus assisting surgeon and anesthesia time. Baselines and variance are measured, so "unusual" has a definition: an observed rate outside an observed distribution. Any downstream predictive model — cancellation risk, turnover forecasting — receives inputs whose meaning is verified, which removes the usual reason such models fail.

The simulation also becomes a policy sandbox. Because it runs the institution's own process nodes at calibrated rates, it can answer counterfactuals: move block release from 72 to 48 hours and observe utilization; change the cancellation-fee lead-time threshold and observe the cancellation distribution. Each counterfactual carries the confidence of the process nodes it runs on, and the simulation reports it alongside the result. What this offers is a place to test an operational change on a faithful copy of the institution before testing it on patients and staff.

Dreaming: simulating the questions nobody has asked yet

Archaeology can only recover questions someone already built a tile for. When a department has few dashboards, or a goal points at a part of the system nobody has reported on, the anticipated query set is thin and the digital twin would stay thin with it. Dreaming closes that gap. Given the goal in context, the physical layer, and the roles from the engagement definition, CSM-1 instantiates simulated analysts — one per role, briefed the way a new hire in that role would be — and lets them ask. A simulated perioperative director, looking at the schema and the goal "understand periop flow," produces first-case on-time starts by room, turnover time by service, cancellation reasons by lead time, block utilization against release rules. Most of these have never appeared on a dashboard. All of them are questions that role would ask within a month of arriving.

Dreamed questions are deduplicated, clustered, and ranked by plausibility and estimated value, then tried in the simulation. Where the digital twin answers correctly, the question joins the evaluation set and the nodes it used gain verification. Where the digital twin cannot answer — a missing join path, an undefined grain, a concept with no mapping — that is a node to build, and it enters the improvement loop as a hypothesis like any other. The ledger grades a dreamed question exactly as it grades a mined one; the simulation does not care where a question came from. Verification is real even when demand is speculative.

Figure 3f. Dreaming. Role-conditioned simulated analysts propose questions the department has not asked; the simulation grades them exactly; gaps become nodes to build. A sample of dreamed questions is spot-checked on production, which gives a transfer signal where no dashboard exists to backtest against.

Three rules keep dreaming honest. Dreamed questions are weighted below mined ones in the improvement score, by their plausibility and value estimates, so the score cannot inflate on questions nobody will ask. A budgeted sample of dreamed questions is spot-checked on production through the governor — one targeted query each — which is how a department with few or no dashboards still gets a transfer signal. And evidence source travels with the node: simulation-verified sits below spot-checked, which sits below dashboard- or serving-confirmed, and only real use promotes a dreamed node upward.

Verification loop

Verification is where the digital twin earns promotion. The candidate digital twin is run against the simulation's evaluation set — mined, defined, and dreamed questions, metric templates, and edge cases — and scored by exact match against the ledger. Misses are attributed and repaired; passes go on to the dashboard backtest, which is the only step that touches the warehouse.

Figure 4. The simulation absorbs all iteration; the warehouse is touched only for the backtest, which reproduces the department's live dashboards from raw sources. A department typically maintains fifteen to twenty dashboards it actually trusts — small by count, but every tile, filter, and breakdown on them is a number the organization already believes, so the set is rich. Its role is to prove transfer, not to be the primary test.

The loop terminates at 100% exact match in the simulation because the ledger makes anything less an attributable defect. "Exact" is defined per metric type: integer equality for counts, agreed tolerances for monetary and rate metrics. Each repair records a regression test, so the evaluation set grows monotonically and a fix in one node cannot silently break another.

Measuring improvement in training mode

Training mode needs an answer to a simple question: is the digital twin getting better, and by how much per unit of training compute? The right shape for that answer is a strict improvement loop — the discipline autonomous experiment loops use in ML research: one mutable target, one read-only evaluation harness, one fixed budget per experiment, one scalar metric, one append-only ledger, and a keep-or-revert rule. CSM-1 adopts that shape directly and calls it the improvement loop.

Figure 4a. The improvement loop. The refinement agent proposes one node-level change per run, is scored by a harness it cannot edit, and keeps the change only on strict improvement. The held-out audit set is regenerated from a fresh simulation seed each session so that the agent cannot overfit the evaluation set it sees every run.

Held-in, held-out, and guardrails

The score is reported on two sets. The held-in set drives keep-or-revert every run. A held-out audit set is regenerated from a fresh simulation seed at the end of every session and never seen by the refinement agent; promotion requires the held-out number. Simulation fidelity, governor spend, confidence calibration, and steward-queue depth are guardrails — they must not regress, but they are not optimized, because folding them into the objective invites the gaming a single un-gameable scalar exists to prevent.

The protected set

A weighted scalar can improve while something important gets worse: a change that fixes ten exploratory questions and breaks one finance-close question can pass on aggregate if the weights allow it. The loop therefore carries a protected set alongside the score — every question tied to a backtested dashboard tile, every question in a high-stakes class named by the engagement definition — and a change that causes any protected question to regress is reverted regardless of what it did to the aggregate. Improvement is measured on the score; safety is enforced per question.

Isolation: the simulation must not bleed into the system it grades

Three walls keep the simulation from tuning the digital twin to itself. First, the generative nodes are calibrated only against the production profile and the dashboard backtest and change only through confirmed provenance hypotheses or the sentinel; they never see the digital twin score, so they cannot drift toward whatever makes the interpretive nodes pass. An improvement session runs against a frozen snapshot of them. Second, the refinement agent never sees the ledger or the scoring function; it receives a score and a list of failed questions, nothing more. Third, no artifact may reference a simulation-specific value — a synthetic identifier, a generated distribution, a ledger entry. Promotion scans for this and fails on any hit. The simulation is an instrument for measuring the digital twin, and an instrument that can be adjusted by the thing it measures is not an instrument.

The learning curve is the proof

Plotting digital twin score against cumulative training compute, per engagement and across the internal validation program, is the artifact that demonstrates the central claim. It shows that accuracy rises with offline compute, where it plateaus, what each unit of compute buys, and — read alongside serving tokens per answered request — that compute spent in training mode reduces what is needed in serving. The experiment ledger beneath it is what makes the curve credible: every step up is a named, diffable change to a named node. Plotted against an expert human baseline, the same curve answers the question a data science team actually cares about — when does this beat what our analysts do unaided, and on what.

Figure 4b. Expected trajectory shape, drawn from the mechanisms above rather than from measured results; the horizontal scale is a working estimate and will vary with the size of the seed and the messiness of the source systems. Human baseline is set at 1.00 and defined as an experienced analyst answering the same evaluation set unaided — itself well short of perfect, because expert analysts disagree on definitions, miss edge cases, and cannot hold an institution's full semantic surface in working memory. The early slope comes from decomposition and composition, where a small number of primitives unlock large numbers of questions. The middle is the improvement loop grinding out attributable defects while dreaming extends coverage into questions no artifact described. The approach to and crossing of the baseline comes from edge cases and the held-out audit: the system applies every settled definition the same way on every question, at every hour, without fatigue, and keeps improving as observation and continual learning add to what it knows. Reported alongside the digital twin score, amplification ratio, and verified coverage, never in place of them.

Validation program

The verification loop measures performance. That is evaluation, and it is necessary but not sufficient. Validation is the separate judgment of whether the measured performance, the coverage of the evidence, the assumptions made, and the remaining uncertainty support a specific use — answering this class of question, for this department, at this stakes level. CSM-1 keeps the two apart, because a system that passes its own tests is not the same as a system a health system should rely on.

Validation runs in two places. An internal program exercises the whole pipeline against reference schemas and synthetic institutions that were never used in development — recovering known metric definitions, preserving differences between service lines and payers, carrying learned mappings across schema versions — and re-runs whenever a component changes. An engagement validation happens per customer: acceptance criteria and the outcomes that matter are named before any results are interpreted, the customer's own published KPIs and prior research are compared against the digital twin, and every gap is reported as a gap rather than folded into a general accuracy claim. Sign-off also closes the register of institutional decisions — the definitions only the institution could confirm — so validation ends with the highest-volume definitions reviewed by their owners and none of that category outstanding.

Figure 4c. Validation outcomes from both programs train a confidence model, which is what tags every served answer: each carries a predicted accuracy and the scope of evidence behind it, and the model is retrained on a fixed cadence as real outcomes accumulate.

Accuracy is always reported against a ceiling. Published KPIs disagree across departments, and a metric whose two institutional definitions differ by 3% cannot be validated more tightly than that; the report states the ceiling rather than pretending to beat it.

Query governor

A health system's warehouse is a shared, production-critical resource. CSM-1 must never be the reason a nightly load slips or a finance close runs late. The governor is a single choke point that every request — from the discovery crawl, the archaeology extractor, the backtest, or the end agent — passes through.

Figure 5. Metadata-first by default; row access is sampled, estimated, budgeted, and deferred to off-peak windows when it exceeds limits. The usage ledger is visible to the customer's data team, and breaches trip a kill switch.

Working at petabyte scale

Health systems are right to ask whether a semantic system can cope with the volume they hold. CSM-1's answer is that it never moves the data. Discovery reads catalogs, statistics, and partition metadata, and samples rows only where profiling needs them; the physical layer is built from what the warehouse already knows about itself. The simulation is sized to exercise semantics, not to mirror volume — a few hundred thousand synthetic encounters test a metric definition as thoroughly as a billion real ones — so no copy of production is ever made. Served queries push aggregation down to the source, prune partitions from the digital twin's time semantics, and cache lineage so repeated questions do not repeat scans. Scale is handled by touching as little of it as possible, and the governor is what enforces that.

Serving

Serving is where the Conversational Suite meets a user, and it is designed on the assumption that the digital twin is good, not perfect. When a question is ambiguous — which definition of "case," which fiscal calendar, whether to include observation stays — the product asks rather than guesses, and the clarification is recorded with the answer. What is learned in serving never writes to the digital twin directly. A clarification applies immediately within that user's session; the durable version enters a candidate queue that continual learning mode (below) reads, is tested through the improvement loop like any other change, and is promoted only if it improves the score in the simulation and survives the dashboard backtest. Between the queue and promotion sits the data team. Every candidate — a clarification a user gave, a correction they made, a confirmation they offered — is presented to the department's data owners with its evidence, the nodes it would touch, and what the simulation found when it was tried, and they approve it, edit it, or reject it. Approved and edited candidates continue to promotion; rejected ones are recorded with the reason so the same suggestion is not re-raised. This is the continual learning loop. Routing it through the simulation keeps one confused user from corrupting a digital twin hundreds rely on; routing it through the data team keeps the institution in control of what its own digital twin says.

Figure 6. Clarifications and corrections take a fast path (session-scoped, immediate) and a slow path (candidate queue, tried in the simulation, then reviewed by the data team — approve, edit, or reject — before promotion). The confidence gate is set per question class and stakes — a finance close question needs more than an exploratory one — and a low-confidence question is flagged or declined with a statement of what evidence would raise it — including, when that is the reason, that the answer rests on a definition the institution has not yet confirmed.

Continual learning mode

Training mode creates the digital twin and serving consumes it. Continual learning is the third mode, and it runs alongside the other two once a digital twin is in service: CSM-1 reads what actually happens when people use it, works out which of that is knowledge worth keeping, and folds the durable part back into the digital twin. It is what keeps the digital twin current as the institution's data, vocabulary, and questions drift, and it is where the fifth kind of definition — contributed — comes from.

Continual learning reads at two resolutions at once. At the trace level it reads individual runs: the question a user asked, the nodes retrieved, the plan executed, the answer returned, the clarification given, the correction made, whether the result was accepted or abandoned. A single trace is thin evidence, but it is precise — it says exactly which node was involved and exactly what went wrong. At the population level it reads traces as points in a clustered vector space: questions, clarifications, and failures are embedded and clustered so that patterns invisible in any one trace become legible. Forty analysts phrasing the same underlying question eleven different ways is one cluster, and it says the digital twin is missing a concept, not that forty people are confused. A cluster of abandoned sessions around one metric says that metric is defined wrong or explained badly, even if no user ever filed a complaint.

What the two resolutions produce together is a judgment about knowledge, and this is the part that requires care. Not everything a user says is knowledge; not every recurring pattern is important; not every correction generalizes. Continual learning scores each candidate on three dimensions before anything is surfaced: importance — how much question volume, how many downstream nodes, and what stakes it touches; nuance — whether it is a genuine semantic distinction (observation stays are excluded from this metric but included in that one) or a restatement of something the digital twin already holds; and usefulness — whether encoding it would actually change future answers or merely add weight to the digital twin. Candidates that clear all three are the ones worth a human's attention.

Figure 7. Continual learning reads individual traces and the clustered vector space together, judges which candidates are critical, and surfaces only those. Surfaced candidates arrive at the data team already tried in the simulation, so the decision is a simple approve or reject rather than an investigation.

Surfacing, not asking

Critical nodes are surfaced as they emerge rather than batched into a review project, and they arrive with everything needed to decide in seconds: what the digital twin would now assert, the traces or cluster that prompted it, what the simulation found when it was tried, and which future questions it would change. The data team approves or rejects, editing the proposed definition first if it is nearly right. Nothing else is asked of them — the investigation has already happened, and candidates that do not clear the importance, nuance, and usefulness thresholds are logged but never surfaced. The queue budget that governs steward questions during training mode governs this too: a handful a week, each one consequential.

The judgment itself is monitored, because its failure modes are asymmetric. Surfacing too much is visible and merely costly. Dropping a critical signal is invisible, and the simulation cannot detect it. Two controls: the approval rate of surfaced candidates is tracked as the judgment's precision, and a random sample of dropped candidates is reviewed each cycle as a check on its recall. A user can also force a candidate to surface. If dropped-sample review finds a critical node the judgment missed, that is a defect in the judgment and it is repaired like any other.

Keeping the human in the loop without overwhelming them

A human approves every change to what the digital twin asserts. That rule is fixed. What keeps it from becoming a burden is that most of what happens in the Conversational Suite is not a change — it is evidence — and evidence is recorded without asking anyone. A user accepting an answer, or a clarification that matches a definition already verified, alters nothing the twin claims; it raises the confidence of an existing node, and that happens automatically. Only three things reach a person: a new node, an edit to an existing definition, or a change to a generative rule.

Five further levers keep the reviewing load small and the decisions fast. Candidates are grouped into one decision per theme, so fourteen users clarifying "period" as the fiscal calendar is one card, not fourteen. Every card arrives already tried in the simulation and the backtest, with an impact preview — how many future answers change, and two or three before-and-after examples — so the decision takes a minute because the investigation already happened. Each owner group has a fixed weekly budget, and candidates are ranked by question volume, stakes, and confidence; only the top of the ranking is surfaced, and the rest wait, re-rank as evidence accumulates, and decay if nothing more arrives — nothing is lost by waiting, because an unapproved candidate already applies session-scoped for the user who raised it. Candidates are routed by group tag, so each owner sees only their own department's definitions. And a candidate touching a protected-set question or a high-stakes class jumps the queue regardless of budget, as does one a user chooses to force.

The approval rate of surfaced cards is the check on the ranking: if owners reject most of what they see, the threshold is wrong and is adjusted. A random sample of what was not surfaced is audited each cycle so nothing critical hides below the budget line. A rejection is recorded with its reason and is not re-raised without new evidence. The result is that an owner sees a handful of cards a week, each consequential, each already tested, each a minute to decide — while everything else in the chat stream still makes the twin more confident without asking anyone.

The cache: critical nodes that shorten future work

Approved critical nodes are written into a materialized layer of the digital twin — the cache — where resolved join paths, settled grains, canonical filters, and exemplar plans are held ready rather than reasoned out again. The effect in serving is direct: a question that previously required composing five primitives and validating the composition now resolves against a single cached node, with fewer retrieval hops, a shorter plan, and lower cost per answer. The cache is a performance layer, but it is not only that — it is also the record of what the institution has settled. A cached node represents a definition that emerged from real use, survived the simulation, and was approved by the people who own the data. As the cache grows, the digital twin gets both faster and more decided, and the questions that still need full composition are increasingly the genuinely novel ones.

Cached nodes are not exempt from verification. Each declares the primitives it depends on and carries its regression tests into every subsequent training cycle. A cached node is invalidated and returns to full composition when its own test fails or when any declared dependency changes — a corrected join path invalidates every cached plan built on it, whether or not those plans' tests happened to exercise the correction. Caching settles a definition; it does not retire it from scrutiny.

Checking its own beliefs: the assumption register and the change sentinel

The simulation grades the interpretive nodes against an answer key the generative nodes wrote, and the generative nodes are CSM-1's model of how the institution's data comes to exist. If that model holds a wrong belief — that a discharge is recorded when the disposition field is set, when in this system it is recorded when the discharge order is signed and disposition lands hours later — the ledger's answers carry the belief, the digital twin built from the same belief matches them, and the test passes with both wrong in the same way. No held-out set catches it, because held-out data comes from the same generative nodes with the same belief. Only the real system can, because the real system does not share the belief. CSM-1 makes that check systematic.

The assumption register records every generative node's process rule as a testable claim about production — "discharge_time = disposition_set_time," "OR in-room time inherited from ADT for floor-scheduled cases," "charges post within two business days of service for 95% of encounters." Each claim is paired with the cheapest production probe that would falsify it, usually a single aggregate query through the governor. Confirmed claims raise the confidence of every node that depends on them, and a claim that holds across the full run of daily snapshots is promoted from probed to observed, the highest tier; unconfirmed claims lower it and are surfaced; falsified claims trigger a correction to the generative node, a simulation regeneration for the affected region, and re-verification of dependent nodes. The register is the list of what the simulation's verdicts rest on, and the share of it confirmed against production is reported alongside the digital twin score.

The change sentinel runs the same discipline forward in time. In serving and continual learning mode the agent watches production for what would invalidate what it knows: schema changes, new code values, shifts in the defect rates the mess profile was built on, drift in the distributions the simulation was calibrated to, changes in dashboard refresh lag, and mutation rates outside the timeline's calibrated bands. Each signal maps to a targeted response — re-run the regression tests of nodes that touch the changed object, refresh the affected slice of the mess profile, re-probe the register claims that depend on it — rather than a full rebuild. The sentinel is what keeps a digital twin promoted in March still trustworthy in September.

Figure 8. The generative nodes' beliefs are listed, each is paired with the cheapest production query that would falsify it, and the sentinel re-runs those checks whenever production changes. The share of the register confirmed against production is the number that bounds how much the simulation's verdicts can be trusted.

Scope of this paper

This paper applies CSM-1 to data analytics: ad hoc questions from analysts, finance, operations, and quality teams, answered against source systems with verified lineage. Analytics is the natural first application because its questions are the easiest to mine from existing artifacts and the cheapest to backtest against numbers the institution already publishes. Nothing in the training pipeline or the digital twin is specific to analytics, and the same architecture applied to other health-system workflows — with different confidence thresholds, freshness requirements, and acceptance criteria — is addressed in companion papers.

Digital twin artifact specification

Decision rules along the pipeline

CSM-1 is deterministic where it counts. At every step there is an explicit condition under which a structure is inferred, a node is created, a hypothesis is accepted, a step passes, or a tier upgrades. The rules below are the ones the pipeline runs on, in the order it runs them. Thresholds (θ, δ, τ, ε) are set in the engagement definition and pre-registered; the same inputs always produce the same verdict.

1. Discover: what counts as a key, a relationship, an anomaly

2. Extract: when an artifact yields a primitive

3. Map and resolve: when a mapping is accepted, when a convention is chosen

4. Create: when a node exists

5. Verify and repair: when a node passes, where blame goes, what gets kept

5b. Observe: what a snapshot diff establishes

6. Tier, promote, cache, watch

Acceptance gates