Ontic Turbulence: Keeping AI Systems in Laminar Flow

Abstract

Ontic Turbulence is the chaotic, hard-to-predict regime AI systems enter when simulators are allowed to guess under missing or ambiguous reality constraints. Laminar flow is governed operation within a well-specified envelope where questions, authorities, and gates are aligned.

The thesis: you don't eliminate turbulence by making "better models." You design architectures that keep most traffic laminar and treat turbulence as a signal to redesign.

1. Why Turbulence Is the Right Metaphor

In fluid dynamics, flow comes in two regimes.

Laminar flow is smooth, predictable, and efficient. Particles move in parallel layers. You can model it, measure it, and design for it.

Turbulent flow is chaotic. Small perturbations cascade into eddies, vortices, and regime switches. Prediction becomes statistical at best. Energy dissipates in unexpected ways.

The boundary between them isn't gradual—it's a phase transition. Once you cross it, the system behaves fundamentally differently.

AI systems exhibit the same dynamics.

Regime	Laminar	Turbulent
Questions	Well-posed, single-domain	Ambiguous, cross-domain
Identity	Canonical IDs, resolved variants	Strings, unresolved references
Oracles	Known, fresh, queryable	Missing, stale, degraded
Gates	Explicit preflight/postflight	Ad-hoc, bypassed, silent fallbacks
Behavior	Predictable, auditable	Cascading retries, overrides, surprises

Turbulence is what you get when you run a high-gain simulator into an under-specified environment. The model is powerful. The context is weak. The result is chaos.

This ties directly to Link Margin: turbulence is the dynamic view of insufficient margin. And to Simulators and Sensors: turbulence is what simulators produce when they lack sensor grounding.

2. Sources of Ontic Turbulence

Turbulence doesn't emerge randomly. It has structural causes.

Ill-Posed Questions (No Mondai Ishiki)

Requests that mix domains without clear problem targeting.

"Draft this contract and tell me if it's enforceable."

This conflates two distinct questions—generation and legal analysis—that require different authorities, different evidence standards, and different error handling. A system that attempts both in one pass is operating in turbulence.

Mondai Ishiki (problem consciousness) requires locating the generating condition before acting. Without it, the system optimizes at the wrong layer and produces plausible but unverifiable output.

Unresolved Identity (No Identity Authority)

Strings instead of canonical IDs.

"Chicken breast" → Which of 100+ USDA FDC variants? "The California law" → Which statute, which version, which interpretation? "Our New York office" → Which legal entity, which address, which jurisdiction?

When identity is unresolved, the model pattern-matches to something. It returns a chicken breast. Not the right chicken breast. The output looks correct. It may be wrong.

Identity Authority requires that claims bind to canonical identifiers before computation. Without it, every downstream calculation inherits the ambiguity.

Missing Oracles / Degraded Sensors

External systems down, stale data, unknown jurisdiction, unmodeled edge cases.

The USDA API returns a 503. The case law database hasn't indexed this week's rulings. The patient's allergy profile hasn't synced from the EHR.

When oracles are missing or degraded, the model has two choices: refuse to answer, or guess. Guessing is turbulence. The output may be plausible, but it's ungrounded.

Sensor architecture treats oracle availability as a prerequisite. If the sensor is down, the claim cannot be made—not "the claim is probably fine."

Governance Gaps and Overrides

"Just answer anyway" modes, manual bypasses, silent fallbacks when gates fail.

The preflight gate rejected the request for missing jurisdiction. The operator clicked "override." The postflight gate flagged insufficient evidence. The system emitted anyway with a disclaimer.

Every override is a turbulence injection. Sometimes necessary. Always a signal. When overrides become routine, the system is operating outside its designed envelope.

Load and Complexity

Too many interacting agents/tools, unclear ownership, conflicting rules.

Three agents each modify the same state. Two policies contradict on the same input. The retry logic triggers a cascade that amplifies instead of dampens.

Complexity doesn't just increase failure probability—it changes failure character. Simple failures are predictable. Complex failures are turbulent: they cascade, interact, and produce emergent behavior that no single component intended.

3. Laminar Flow: The Controlled Operating Envelope

Laminar flow isn't the absence of power. It's power within bounds.

Clear Workload Envelope

Each workflow declares:

Domain: what kind of questions it handles
Purpose: what outcome it's designed to produce
Allowed question types: what it can answer authoritatively

A nutrition calculator doesn't answer legal questions. A contract summarizer doesn't provide medical advice. The envelope is explicit.

Explicit Authorities and Oracles

For each claim type, the system knows:

Which database, policy set, or human role is authoritative
What freshness and integrity requirements apply
What to do when the authority is unavailable

"Chicken breast" resolves to FDC ID 171077. "California employment law" resolves to a specific statute and case law set. The authority is named, not assumed.

Preflight Gates

Checks that run before calling a model:

Is the required context present?
Is identity resolved?
Are the necessary oracles available?
Does the question fall within the workload envelope?

If any check fails, the request doesn't proceed. The system returns a structured status—REQUIRES_SPECIFICATION, AUTHORITY_UNAVAILABLE, OUT_OF_ENVELOPE—not a guess.

Postflight Gates

Checks that run after the model produces output:

Does the output satisfy schema contracts?
Does it match oracle evidence?
Does it meet consequence thresholds?
Is provenance complete?

If any check fails, the output doesn't emit. The system rejects, re-routes, or escalates—not silently passes through.

Stable Error Taxonomy

Errors are classified by type:

Schema failure: structurally invalid input or output
Domain violation: physically impossible or logically contradictory claims
Evidence failure: claims that don't match oracle data

Each type has predictable routing. Schema failures get rejected. Domain violations trigger review. Evidence failures escalate to human verification. The error path is as designed as the success path.

This is the three-layer architecture in operation: Doctrine defines what's allowed, RFCs specify how gates behave, and the runtime enforces both.

4. Gates as Flow Control Surfaces

In aerodynamics, control surfaces keep the aircraft within its flight envelope. Ailerons, elevators, and rudders don't eliminate turbulence—they prevent the aircraft from entering regimes where turbulence becomes dangerous.

Gates serve the same function in AI systems.

Preflight Gates = Angle-of-Attack Limits

Preflight gates prevent the system from entering regimes it cannot safely operate in.

Without jurisdiction → refuse to answer legal questions Without variant specification → refuse to compute nutrition Without patient context → refuse to suggest dosing

The gate doesn't make the model smarter. It prevents the model from operating in regimes where it can't be trusted.

Postflight Gates = Turbulence Dampers

Postflight gates absorb and dissipate bad proposals before they affect users or state.

Output doesn't match oracle → reject Confidence below threshold → escalate Provenance incomplete → block emission

The model proposed something. The gate vetoed it. The turbulence was contained.

Control Laws

RFCs and Doctrine define how the system responds to turbulence:

Fail-closed: if uncertain, emit nothing
Degrade gracefully: if partial, emit partial with disclosure
Escalate: if ambiguous, route to human review
Learn: if recurring, flag for redesign

Changing gate thresholds is like changing the flight envelope for different domains. Consumer Q&A can tolerate more edge cases. Oncology dosing cannot.

5. Measuring Turbulence

Turbulence isn't just a metaphor. It's observable.

Turbulence Metrics

Metric	What It Measures
Preflight rejection rate	How often requests lack required context
Postflight rejection rate	How often model outputs fail verification
Escalation rate	How often outputs require human review
`UNKNOWN` / `INSUFFICIENT_EVIDENCE` rate	How often the system correctly declines to answer
Override rate	How often humans bypass gates
SAF incident rate	How often turbulence reaches end users

Where Metrics Live

Logs: every gate decision, every rejection, every override
Dashboards: real-time visibility into turbulence hot spots
Incident reviews: post-hoc analysis of SAF events
Architecture reviews: periodic assessment of envelope design

Turbulence as Design Signal

High turbulence in a specific workflow isn't a bug—it's a signal.

High preflight rejections → ontology is under-specified, need more state axes
High postflight rejections → model is poorly calibrated for this domain, need better training or tighter constraints
High overrides → gates are too strict, or operators are under pressure, or the envelope is wrong

Turbulence should route into redesign, not overrides. If operators routinely bypass gates, the gates are wrong—or the workload envelope is.

6. When Turbulence Is Necessary

Some domains require operating near the edge of what's knowable.

Novel therapies with limited evidence
Emerging regulations not yet codified
New market conditions outside historical patterns
Research questions where the answer is genuinely unknown

In these regimes, you can't avoid turbulence. But you can:

Contain It

Sandboxed environments where turbulent outputs don't reach production
Human-perimeter review before anything escapes the sandbox
Explicit "research mode" with different gates and disclosure

Make It Visible

Strong logging of every turbulent decision
Explicit uncertainty markers in outputs
Audit trails that show exactly what was unknown and what was assumed

Keep It Out of Production

Turbulent outputs stay in draft/review until adjudicated
Only laminar outputs reach end users
The boundary between turbulent and laminar is a gate, not a hope

SAF incidents are cases where turbulence hit end users instead of being contained. The Alaska chatbot, the hallucinated case citations, the fabricated dosing recommendations—all turbulence that escaped.

7. Design Pattern: Keeping Most Traffic Laminar

Turn this into a checklist:

Constrain the domain (Mondai Ishiki) Define what the workflow is for. Refuse questions outside the envelope.
Externalize identity and oracles (Identity Authority) Resolve strings to canonical IDs. Bind claims to authoritative sources.
Treat "unknown" as a valid outcome (Ontic Turbulence) When evidence is missing, say so. Don't interpolate.
Insert preflight and postflight gates around every model call Check before. Verify after. No model output bypasses gates.
Instrument turbulence and route it into redesign High rejection rates are signals, not failures. Overrides are debt.

This pattern doesn't make models weaker. It makes the system stronger. The model can be as powerful as you like—behind well-designed gates, the power is directed rather than chaotic.

8. Implications for Teams and Products

For Architects

Design workflows with explicit envelopes and gates, not just prompts and tools.

Define the workload envelope before writing the first prompt
Specify authorities and oracles before integrating the first API
Design error paths with the same rigor as success paths

For Ops and SRE

Treat turbulence metrics like error budgets and SLOs.

If preflight rejection rate exceeds threshold → investigate ontology gaps
If override rate exceeds threshold → investigate gate calibration
If SAF incident rate exceeds threshold → stop and redesign

For Product and Compliance

Decide where laminar is mandatory and where controlled turbulence is acceptable.

Laminar mandatory: healthcare dosing, financial calculations, legal citations—domains where errors have consequences
Turbulence acceptable: ideation, drafting, brainstorming—domains where human review is assumed

The distinction isn't about capability. It's about consequence.

Closing

Laminar vs turbulent is the dynamic view of the same reliability problem.

Link Margin is how much governance distance you maintain from chaos—the static measure.

Ontic Turbulence is what happens when you cross that boundary—the dynamic behavior.

Engineers don't hope for smooth flow. They design control surfaces that keep the system laminar under normal conditions and contain turbulence when it occurs.

The question isn't whether your AI system will encounter turbulence. It will. The question is whether that turbulence is contained by architecture or escaped to users.

That choice is yours.