Three Challenges, Not One

For Both Executive and Technical Readers

Agreeing an ontology, classifying the rung of a live question, and reading intention from an expert’s grammar look like the same problem from a distance. They are not. Each fails independently of the other two.

01 The Problem

Teams conflate these three challenges constantly, because from a distance they all look like the same thing: “making sure everyone means the same thing.” A data governance team that spends a year negotiating a shared ontology across departments believes, reasonably, that it has solved the hard part. It has solved one part. That agreement says nothing about whether an incoming question gets correctly classified as asking for an intervention or a counterfactual, and it says nothing about whether an expert’s description of their own reasoning has been read correctly for the causal claim buried in their choice of verb.

These are three separate problems because they occur at three different times, involve three different populations, and fail in three different ways. Confusing them means an organization declares victory after solving one and is blindsided by the other two, later, when it is more expensive to fix.

02 The Organizational Challenge

Define and agree an ontology, before any model runs.

This is a cross-team, pre-runtime problem. Two departments each build a model of their own corner of the business; each model is individually correct. The challenge is getting both teams to agree, in advance, that “High Risk” means the same population, the same threshold, and the same referent in both models. Nobody is asking a question yet, this negotiation happens before any query exists, and it happens between people, not between a person and a system.

This is exactly Requirement 1 on Composability: an accurate, precise ontology at the seam between models. It is a knowledge and governance problem, not a technical one, the Scope Card only records an agreement that humans had to reach first.

03 The Operational Challenge

Classify the rung of the question being asked, live, every time.

This is a per-query, runtime problem, and it recurs fresh with every question a stakeholder asks. “If we raised prices last year, would revenue have grown?” reads as past tense but is often a Rung 2 policy question in disguise. The ontology could be perfect and this classification could still fail, because the ambiguity is in the specific sentence, not in whether the two sides agree what “revenue” means.

This is the subject of Grammar §02 and, especially, the traps catalogued in §03, backtracking ambiguity, future counterfactuals, and past tense that is actually Rung 2. Mood is a real signal for this classification, but only a partial one.

04 The Elicitation Challenge

Read the intended causal claim from how an expert describes their own model.

This is a per-expert, pre-model problem, it happens during the interview that builds the model, before there is anything to query at all. An expert saying the sprinkler “kept the lawn wet” and one saying it “let the lawn stay wet” are describing different causal mechanisms, not stylistic variants of the same sentence. Getting the ontology right and correctly classifying rungs does nothing to solve this, this challenge is about whether the elicitor heard the mechanism the expert actually meant.

This is Talmy’s force-dynamics argument, covered in Grammar §04: verbs like “let,” “make,” “keep,” and “prevent” encode a causal micro-structure that a bare edge in a Bayesian network collapses into one arrow unless someone is listening for it.

The tooling to act on this already exists, even though the connection is rarely made explicit. Bayes nets support typed combination rules for how parent nodes produce an effect, not just typed edges, and those rules map onto force-dynamics verbs more closely than most elicitors realize:

Verb	Force-dynamic relation	Gate type
Make / cause	Forcing, one active cause is roughly sufficient on its own	Noisy-OR
Let / enable	Enabling, necessary but not sufficient alone; something else still has to act	Noisy-AND
Prevent	Overriding, suppresses the effect regardless of other active causes	Inhibitory gate
Keep / maintain	Sustaining a state rather than producing a transition	Not a static gate, needs a temporal loop (dynamic Bayesian network)

“Make / cause” heard in a session. “Late claims made the reserve estimate unreliable.” Elicit as noisy-OR: the lateness alone is close to sufficient.
“Let / enable” heard in a session. “Weak segmentation let outlier accounts through underwriting.” Elicit as noisy-AND: weak segmentation alone does not cause the outcome, something else still has to go wrong.
“Prevent” heard in a session. “The pre-authorization step prevents most denials.” Elicit as an inhibitory gate: this parent suppresses the effect regardless of what else is active.
“Keep / maintain” heard in a session. “Manual review keeps the false-positive rate low.” Elicit as a temporal loop, not a static edge: the state is being sustained, not produced once.

Right now this mapping is informal: an elicitor has to notice the verb, understand what it implies, and manually choose the right CPT structure. Nothing enforces the connection between what the expert said and which gate got built. Making it a fixed rule, hear the verb, pick the gate, is what turns the Talmy point from an observation into something an elicitor can act on, rather than a fact about language that sits next to the model without touching it.

A Tool Already Exists for This, Informally BayesFusion’s QGeNIe, a qualitative modeling environment built on DeMorgan nodes, which generalize the noisy-OR/noisy-AND distinction into a single signed-influence framework, is designed for this kind of rapid, group-elicitation prototyping: sketch the qualitative structure with the experts in the room, then quantify later. It isn’t built around force-dynamics vocabulary specifically, so the verb-to-gate mapping above still has to happen in the elicitor’s head. But the substrate for doing this properly, live, in a session, already exists, it just isn’t wired to the linguistic cue that should be driving it.

05 Why This Requires Humans

The Common Thread All three challenges are solved the same way: because they have an innate understanding of cause and effect, and the tacit judgment, not communication skill, to negotiate meaning, resolve ambiguity, and infer intention from it. A system doing this on its own has none of the four.

This is not a claim about eloquence. A brilliantly articulate speaker who does not understand the domain cannot negotiate an ontology, correctly classify an ambiguous question, or read a colleague’s intended mechanism, fluency is not the skill in play. What is in play, in all three cases, is a person’s grasp of the actual cause-and-effect structure of the domain, which is what lets them recognize when two teams mean different things by the same word, when a sentence's tense is misleading about which rung is meant, and when “let” and “make” are marking two different mechanisms rather than two ways of saying the same thing.

A system without an independent grasp of cause and effect cannot do any of the three, no matter how fluent its output is, it can only pattern-match against surface features of language, which is precisely what fails on the ambiguous cases each of these challenges exists to catch.

06 Where They Fail Independently

Solved	Not solved	What still goes wrong
Ontology	Rung classification	Two teams agree perfectly on what “High Risk” means and still misroute a live question that reads as past tense but means a general policy.
Rung classification	Elicitation	Every incoming question gets routed to the correct rung, but the model itself was built on a misheard mechanism, an expert's “prevents” recorded as a bare correlational edge.
Elicitation	Ontology	Every expert's intended mechanism was captured precisely, in a model that cannot compose with any other team's model because nobody agreed on shared terms.

Each row is a real organization that solved one problem thoroughly and was still surprised by the other two. None of the three is a special case of another; solving two does not entail the third.

07 Where It Sits

This page names a taxonomy that already runs across three other pages rather than introducing a new component. The Organizational Challenge is Requirement 1 on Composability. The Operational and Elicitation Challenges are both covered on Grammar, Mood, and the Shape of Cognition, the first in its discussion of rung-detection and its failure modes, the second in its treatment of force dynamics.

The practical use of the taxonomy is diagnostic: when something goes wrong with a model or a query, asking which of the three challenges failed, rather than assuming the whole system is unreliable, usually narrows the fix to a single team, a single stage of the pipeline, or a single elicitation session to revisit.

Lanes, Gates, and Loops names the same underlying gap from a different angle: the Organizational and Elicitation Challenges here are both places where a human’s judgment does real work the architecture takes on faith rather than certifies, which is exactly what that page’s Human Lane is missing a formal specification for.