Skip to content
OnticBeta

Simulators, Sensors, and the Discovery of Ontic Governance

How a single constraint—do not allow AI to fabricate nutrition data—forced the discovery of a three-layer governance architecture.

January 10, 2026· 15 min read

Simulators, Sensors, and the Discovery of Ontic Governance

How a Single Constraint Forced an Architecture from Doctrine to Execution

Abstract

This paper documents how an AI application did not adopt a governance philosophy, but discovered one through empirical constraint. Beginning with a narrow requirement—do not allow AI to fabricate nutrition data—the system was forced to converge on a three-layer architecture that cleanly separates problem definition, execution authority, and output admissibility. What emerged was not a whitepaper-driven framework, but an executable constitution: doctrines encoded as machine-readable contracts, enforced at runtime through preflight and postflight gates. The result is an architecture that treats large language models as simulators that propose hypotheses, while reserving veto power for reality.

Contents

  1. The Constraint That Would Not Bend
  2. Simulators Are Not Sensors
  3. The Emergence of Identity Authority
  4. Mondai Ishiki as a Runtime Constraint
  5. Ontic Turbulence and the Cost of Guessing
  6. From Doctrine to Execution
  7. The Workflow Contract
  8. Failure as Signal
  9. Why This Was Discovered, Not Designed
  10. Conclusion
  11. Implications for Other Domains

1. The Constraint That Would Not Bend

Most AI systems begin with an aspiration: be helpful, be fluent, be correct. This system began with a prohibition:

Do not let the AI make up calorie counts.

This seems modest. Almost trivial. Yet it is an unusually hard constraint because calories are not stylistic artifacts. They are conserved quantities tied to physical state. They do not tolerate approximation, narrative smoothing, or plausible interpolation. A system that violates this constraint is not slightly wrong; it is physically incoherent.

Early experiments made this incoherence visible. The same ingredient—chicken breast—produced identical nutrition numbers across multiple models, despite each model asserting a different physical state: raw, cooked, grilled. The numbers were statistically canonical, but ontologically impossible. The models had not miscalculated. They had simulated.

This observation matters because it reframes the problem. The failure was not arithmetic. It was epistemic. The models were behaving exactly as trained: generating plausible continuations under completion pressure in the absence of grounded state.

2. Simulators Are Not Sensors

Large language models do not observe the world. They infer continuations from distributions. When asked for nutrition values, they do not measure. They recall what typically follows similar text. In most domains, this distinction is academic. In nutrition, it is fatal.

The system therefore faced a choice:

  • Relax the constraint and accept plausible-but-wrong outputs, or
  • Redesign the system so that simulation is never mistaken for measurement

The second path required a deeper rethinking of authority.

3. The Emergence of Identity Authority

Once the system rejected LLM-generated nutrition numbers, it needed an alternative source of truth. That source already existed: the USDA FoodData Central (FDC). But integrating it revealed another hidden assumption.

Strings were not enough.

"Chicken breast" is not an identity. It is a label. Nutrition depends on preparation, trimming, cooking method, moisture loss, and yield. To compute calories correctly, the system needed stable ontological entities—canonical ingredients with physical dimensions and identifiers.

At this point, a doctrine emerged implicitly:

Embeddings may propose candidates, but only canonical IDs resolve identity.

This is Identity Authority. The model can suggest, rank, and explain, but it cannot decide what an ingredient is. That decision belongs to the ontology.

4. Mondai Ishiki as a Runtime Constraint

A second realization followed quickly. If nutrition is computed externally, what problem is the AI actually solving?

Not nutrition.

The AI is solving recipe generation, interpretation, and transformation. Nutrition is a downstream computation governed by different rules and authorities. Collapsing these domains into a single prompt was the original error.

This forced a separation of concerns:

  • Define the problem precisely (recipe semantics)
  • Invoke appropriate authority for resolution (USDA for nutrition)

This is Mondai Ishiki—problem consciousness—not as philosophy, but as enforced scope.

5. Ontic Turbulence and the Cost of Guessing

The final constraint was the most uncomfortable:

Missing data must be treated as unknown, not guessed.

Language models are optimized to avoid saying "I don’t know." When information is missing, they interpolate. In creative writing, this is a feature. In physical domains, it is a lie.

Once the system adopted an explicit policy—unknown stays unknown—it needed a way to enforce it mechanically. This gave rise to Ontic Turbulence: the recognition that simulators will always propose plausible completions, and that those proposals must be vetted against reality before acceptance.

6. From Doctrine to Execution: The Three-Layer Architecture

These constraints crystallized into a runtime architecture with three distinct layers:

  1. Workload Architecture (Mondai Ishiki) — What problem is being solved?
  2. Execution Policy (Identity Authority) — How is the model allowed to operate?
  3. Ontic Gates (Ontic Turbulence) — Is the output admissible?

Crucially, authority is enforced both before and after the model call.

  • Preflight gates ask: Do we have enough information to ask this question at all?
  • Postflight gates ask: Does this output satisfy the declared contracts and constraints?

This temporal distinction is what makes the system stable. Preflight gates prevent ill-posed questions from reaching the model; postflight gates detect and reject hallucinated or non-compliant outputs before they reach users.

7. The Workflow Contract as Constitutional Law

To make this executable, every workflow must declare its terms upfront:

  • Input schema
  • Output contract
  • Execution policy
  • Pipeline shape
  • Ontic gate sequence

The runtime does not improvise. It executes declared policy. This turns governance into flow control rather than intent.

8. Failure as Signal, Not Exception

Errors are not collapsed into a single state. They are classified:

  • Invalid schema — structural impossibility
  • Domain violation — physical or logical implausibility
  • Insufficient evidence — epistemic failure

Each classification implies a different response: retry, escalate, clarify, or fail closed. This routing discipline is what allows the system to learn where its assumptions break.

9. Why This Was Discovered, Not Designed

None of this began as an attempt to build AI governance. It began as an attempt to compute calories correctly. Physics forced ontology. Ontology forced authority. Authority forced gates. Gates forced architecture.

The parallel runner infrastructure did not invent Ontic. It revealed it. By providing a single execution boundary, it made previously implicit constraints explicit and enforceable.

10. Conclusion: Governance as a Property of Reality

This system demonstrates a broader lesson: effective AI governance does not begin with ethics or policy. It begins with constraints imposed by the world.

When simulators are used in domains governed by conserved quantities, stable identities, and physical laws, governance is not optional. It is the minimum architecture required for correctness.

In that sense, Ontic is not a philosophy. It is a physics.

11. Implications for Other Domains

The constraints that forced this architecture are not unique to nutrition. They recur anywhere language-based simulators are asked to operate in domains where reality has veto power over fluency.

11.1 Domains with Conserved Quantities

Any domain governed by conserved or tightly bounded quantities will surface the same simulator–sensor confusion. Examples include:

  • Finance: cash balances, double-entry accounting, interest accrual, capital conservation
  • Physics & Engineering: mass, energy, load tolerances, thermal limits
  • Pharmacology: dosage, concentration, bioavailability

In these domains, statistically plausible numbers are often physically impossible. Systems that allow simulators to fabricate values will fail silently until audited against reality.

11.2 Domains with Stable Identity Requirements

Any domain where correct computation depends on stable identity—not strings or labels—will require explicit Identity Authority:

  • Medical records: patients, procedures, diagnoses, longitudinal identity
  • Legal systems: entities, contracts, jurisdictions
  • Supply chains: SKUs, lots, provenance, transformation state

In these cases, embeddings and similarity search can propose candidates, but only canonical identifiers can resolve identity. Authority must be external to the simulator.

11.3 Domains Where Plausible ≠ Correct

In many high-stakes domains, the most dangerous outputs are not obviously wrong—they are plausible. These include:

  • confident explanations with missing evidence
  • internally consistent but externally false narratives
  • averaged or canonical values applied to specific states

Such failures cannot be solved by better prompting. They require preflight gates that prevent ill-posed questions and postflight gates that reject outputs lacking admissibility.

11.4 Generalization Claim

The architecture described in this paper generalizes wherever the following conditions hold:

  1. The model is a simulator, not a sensor
  2. The domain is governed by physical, legal, or logical constraints
  3. Incorrect outputs are costly even when fluent

In these environments, the causal chain is unavoidable:

Physics forces ontology. Ontology forces authority. Authority forces gates. Gates force architecture.

Any system that ignores this chain will rediscover it through failure.

This paper therefore serves not only as a retrospective, but as a warning: whenever reality has veto power over language, governance is not an overlay. It is the substrate.

Related Work and Prior Art

Ontic builds on established patterns from software engineering, distributed systems, and AI safety research:

ConceptOriginOntic Application
Design by ContractMeyer (1988)Preflight/postflight gates as runtime contracts
Circuit BreakersNygard (2007)Fail-fast patterns for oracle unavailability
Guardrails AIRajpal et al.Schema validation with retry semantics
NeMo GuardrailsNVIDIA (2023)Conversational flow control and safety rails
Constitutional AIAnthropic (2022)Training-time alignment via self-critique
RLHFOpenAI/DeepMindPreference learning for alignment

Ontic's contribution is not new primitives but a specific synthesis:

  1. Runtime enforcement (not training-time only)
  2. Epistemic guarantees (not probabilistic safety)
  3. Domain-specific ontologies (not generic content filters)
  4. Explicit authority separation (not implicit trust in model outputs)

The architecture was discovered through empirical constraint, not designed from first principles. This document describes what emerged when a real system was forced to treat LLMs as simulators that propose hypotheses—while reserving veto power for reality.

Related Resources

Reference Implementations

These documents show how the architecture applies to specific domains:

Real-World Failures (SAF)

Epistemic Status

Claim TypeExamples in This DocumentInterpretation
Historical narrative"The system was forced to converge…"Accurate description of development history
Architectural claims"Three-layer architecture"Definitional; refers to documented spec
Causal assertions"Physics forces ontology"Heuristic framing, not a formal proof

This document is informational. It explains why the architecture exists, not how to implement it. For normative requirements, see the Technical Specification and RFC Specification.

See Also

← PreviousNext →
—Technical Specification

Ready to learn more?

Check your AI governance posture with our risk profile wizard.

Check Your RiskView Architecture