Within-world Capability — can
What can be computed or derived inside the jurisdiction?
Historical record · the state of 21 August 2026
This page is not current.
It preserves the Analytical Governance doorway exactly as it stood on 21 August 2026, compressing Version 1.1 of the paper (21 August 2026). That edition has been superseded: the current record is Version 2.0 (26 August 2026), and the current doorway is Analytical Governance.
It is kept, unedited, because v2.0 did not reword this argument — it reorganised the category. The sections below include material the current framework does not carry, and one worked example whose numbers the current edition states differently. Read as a record of what datumwise argued on that date, not as a statement of the current position.
Analytical Governance
What can be computed is not yet what may be served.
Analytical Governance governs the relationship between can and may across a multi-world analytical process.
Conformance test
A governed analytical system must be capable of withholding analytical permission. If it cannot refuse, it is not governed.
Analytical Governance: From User Intent to Governed Analytical Execution The edition this page compresses. Preserved as it was; the deposit governs.
A number the database can compute but governance cannot yet serve
What was average revenue per open store yesterday?
What the system knows
- 50 open store-days
- the governed store calendar
- 47 ordinary revenue observations
- the sales table
- 2 governed zero-revenue store-days
- the applicable support rule
- 1 open store with an unavailable feed
- no evidence presently
Three plausible executable procedures
-
47 as the denominator
Divide total revenue by the stores with ordinary sales observations.
Makes observed sales rows define the population.
-
49 as the denominator
Exclude the one store whose feed is unavailable.
Silently changes the requested population to the currently supported population — unless that alternative is separately governed.
-
50 as the denominator
Divide by the declared open-store population.
Uses the requested population, but the requested result is presently support-insufficient: one required point lacks evidence.
All three can be written in valid SQL. All three return a plausible number. Execution alone cannot establish which result is entitled to answer the question — and the honest answer here is not a fourth number. Population, support, identity, and serving authority have to become explicit before a computation may stand as the answer.
At this point, no number is entitled to answer the question. The 50-store population is the governed population — and the requested result is still withheld, because one store-day in that population lacks the revenue evidence it requires.
Establishing the population and establishing a presently servable answer are two different things, and only the first has happened here.
Two gaps before execution
Governance must settle analytical meaning and servability before physical execution receives authority.
- User intent
- Intent translation and analytical framing
- The intent gap from the user's language to an explicit analytical request
- Explicit analytical request
- Servability
- support sufficiency
- analytical establishment
- The servability gap from a faithful request to one that is supported and established
- Bounded risk evaluation
- cost
- security
- result / application
- Authorization
- Trusted planning and execution
The semantic invariant
Servable = Support Sufficient ∧ Analytically Established
The two halves fail for different reasons and are repaired differently. Support sufficiency is contingent: does the evidence and state this request needs exist right now? Analytical establishment is structural: does the requested object exist under the governed model, and is the proposed derivation lawful?
The rule that keeps risk honest
Analytical violations are unestablished, not risks.
Risk may constrain an established request — cost may deny it, security may withhold it, application conditions may qualify how it is presented. Risk may never legalize an unestablished one. There is no signature that makes an unlawful derivation lawful.
What may travel backwards
Clarification may return to the requester.
Planning may report physical constraints.
Neither may silently change analytical meaning. A returned clarification and a reported constraint are both legitimate; a quietly substituted request is not.
Two axes: capability and legitimacy, interior and crossing
Capability answers can. Governance must still answer may.
Axis 1 — source of law
within-world vs crossing
A world's interior is where its own law has jurisdiction. A crossing is an operation that leaves one jurisdiction for another, and the boundary is where that happens. The two are governed differently because different law applies.
Axis 2 — governance question
capability — can vs legitimacy — may
Can is what the machinery is able to do. May is not merely runtime permission: it includes analytical law, warrant, and authority. A system that has collapsed the second into the first has not simplified governance; it has removed it.
Within-world Legitimacy — may
What is lawful under that world's own law?
Crossing Capability — can
What can be transported, invoked, or executed across the boundary?
Crossing Legitimacy — may
What is licensed to pass, with the required warrant and authority?
The consequence
Lawfulness first, execution second.
The matrix is an explanatory instrument, not four independent product boxes. Read across it and the same fact appears twice: being able to compute a quantity inside a world does not make it lawful there, and being able to transport a result across a boundary does not license its passage.
The claim here is about organization, not discovery. datumwise elevates within-world versus crossing into an organizing axis for analytical governance and crosses it explicitly with capability versus legitimacy. Neither distinction is claimed as new, and no historical priority is claimed for the pairing.
The analytics industry has been selling tickets and calling them visas.
Three powers, separated
interpretation ≠ analytical adjudication ≠ physical execution
The separation is not organizational tidiness. Each power has a different epistemic character, and collapsing any two of them is how a plausible interpretation acquires execution authority without ever being adjudicated.
-
Interpretation
human language → candidate governed analytical request
AI is genuinely well suited here, because interpretation is probabilistic and contextual: it can search definitions, connect a user’s vocabulary to local terms, retrieve candidate governed objects, and propose requests.
Probabilistic plausibility must not become analytical authority.
-
Analytical adjudication
candidate request + governed model + current support → determination
Identity, support, lawfulness, and servability are established here, independently and testably. This is where analytical authority lives. The adjudicator may canonicalize a uniquely determined request; it does not choose among unresolved analytical meanings on the user’s behalf.
The agent may respond to adjudication. It does not overrule adjudication.
-
Physical execution
adjudicated request → plan → result
Trusted planners and engines realize what has already been established. Execution may report that a binding is absent, that exact state is not materialized, or that a plan is unexpectedly expensive — and those findings flow back into support determination and risk.
Planning may report constraints; it may not silently substitute a different analytical request.
The serving boundary — and its edge
Clarify stays inside the constitution. Escalate reaches the constitution’s edge.
The serving vocabulary — what a governed system returns at the machine boundary
-
Serve
The request is determinate, servable, authorized, and may be returned under its governing conditions.
-
Disclose
The request may be served, but material support, approximation, or application conditions must travel with the result.
-
Clarify
A user-resolvable choice remains among meanings that are already governed.
-
Refuse
The requested answer may not be served under current analytical, support, risk, or authorization conditions.
The governance-process outcome — across the system boundary
Escalate
Resolution requires new governance authority, evidence, definition, or qualified review. It is not a fifth analytical serving verdict.
Clarify choose among governed meanings.
Escalate new meaning, evidence, authority, or qualified governance action is required.
The full governance process therefore produces five externally meaningful outcomes. The machine serving vocabulary has four. Those are two different counts of two different things, and collapsing them is how a governance boundary quietly becomes a response enum.
Conformance
A governed analytical system must be capable of withholding analytical permission. If it cannot refuse, it is not governed.
The important idea is not refusal as a product behaviour. It is withholding analytical permission as a category requirement. A system that can always produce something has no mechanism for the case where nothing is entitled to be produced, and it will therefore produce something anyway.
This is why Refuse appears on this page as governance functioning correctly, never as an error state — and why the site's vocabulary carries no failure-red for it. Refusing is the capability being tested.
The soundness condition on the serving boundary
Every served answer must be entitled under the declared analytical meaning and current support; unestablished answers must be withheld.
Where this sits
Wider scope, not higher sovereignty.
Analytics is not governed by one body of law. Governed data, inferential claims, and authorized action answer to distinct correctness conditions, and a real analytical act may traverse several jurisdictions. Analytical governance is the meta-framework that tracks which law has jurisdiction and what survives each passage.
- Data governance composes with analytical governance
- Analytical governance decides which analytical results may be served. It is distinct from data governance, which governs the stewardship, access, quality, and control of data assets. The two compose; neither substitutes for the other.
- Theory of Data supplies interior law to analytical governance
- ToD supplies the interior law for governed analytical data — identity, derivability, contracts, sufficient state. It is narrowly that. It is not a general ontology of analytical objects, and it is not the law of every world analytical governance coordinates.
- The Statistical Bridge governs a crossing inside analytical governance
- The Bridge governs the passage from governed data and evidence to inferential claims. Analytical governance may compose that crossing into a larger analytical path. It does not replace the Bridge’s law, and it does not adjudicate inference itself.
- Columna is an executable consequence of analytical governance
- Columna is evidence that these distinctions can be embodied in a working system. It is not the definition of analytical governance, and the category does not depend on it.
- Frame-QL is one request language for analytical governance
- Frame-QL speaks natively in governed analytical objects, which makes it a convenient request boundary. No one language or protocol is required by the category — only that every identity-bearing distinction be explicit in the request or uniquely derivable from the governed model.
The research corpus The authority boundary, argued Exhibit B — four requests, four earned verdicts
Theory of Data law Manifold declared governed world Frame-QL language Columna machine / system Analytical Governance composition and authority architecture
Product consequence
The typing is not only argued. It ships.
Analytical Governance is a category, not a product. But a category that no system has ever embodied is a proposal, and the distinction this page turns on is testable in one place: what a governed engine is actually willing to return.
Escalate does not appear at this boundary. It is a governance action, not a serving mood.
Columna exposes exactly the four serving moods at its machine boundary. Escalate is not among them — not because it was left out, but because it is not a serving verdict. It is what happens when the governed world cannot resolve the request at all.
The block beside this is read from a transcript generated by running the shipped package,
on the deploy path. Nothing in it is transcribed by hand, and the absence of
escalate is verified at build time rather than claimed in copy.
- "outcome": "serve"
- "outcome": "disclose"
- "outcome": "clarify"
- "outcome": "refuse"