Introduction
Before deciding what an AI governance framework should even be, organizations should first ask what requirements such a framework would have to satisfy, and on what theoretical basis it could rest. For this essay I will use Jan Dietz's Enterprise Ontology and Ronald Stamper's Semiotic Ladder. I have chosen these because they were developed for organizations and because they share a lineage that traces back to Charles Sanders Peirce.
At some levels of organizational meaning, human authority and accountability are not optional controls added later. They are part of the act. A request, promise, or declaration is not just content plus a later assignment of responsibility. Being answerable for it is fundamental to the structure of the organization.
So this is not primarily a recommendation. It is a structural claim. If accountability is part of the act, removing it changes the kind of act, and therefore the kind of system.
This essay is narrower than a governance framework. It is an attempt to state the conditions any adequate framework would have to satisfy in the operations of a business, regardless of implementation style or model capability.
Expandable summary: Stamper's semiotic ladder in the narrow sense used here
The full ladder runs from the physical handling of signals up through syntax, semantics, pragmatics, and the social level. For this essay, the lower levels are not the issue. Signal transmission, encoding, parsing, and structural transformation can all be automated and already are.
The relevant boundary is in the upper part of the ladder. Semantics concerns what a sign refers to. Pragmatics concerns the purpose or attitude attached to that content, such as whether it is a request, warning, or recommendation. The social level concerns commitments, norms, roles, and answerability. Dietz's terms line up with this structure: forma for signs and data, informa for meaning, and performa for social action that creates or settles obligations.
The rest of this essay focuses on the upper three levels because that is where organizational force appears.
Working definitions used throughout
Forma is the sign or data level, independent of meaning.
Informa is the meaning level, including both what a sign refers to and the attitude taken toward it.
Performa is the level where communication creates or settles an obligation.
The scope here is the operation of a business, meaning the commitments it makes and the purposes it pursues. This is not primarily about coding assistants or personal productivity tools. Those usually sit lower in the same structure unless software itself is the product.
The argument proceeds in four steps:
- Distinguish the upper levels at which meaning has organizational force.
- Show that execution can be automated at each level but authority cannot.
- Show why that distinction is durable because it does not depend on current model capability.
- Use that result to place language models in a governed architecture.
On the Theoretical Choice
The lineage I am using runs from Peirce through Charles Morris to Stamper and Dietz. Morris systematized Peirce's triadic account of signs in Foundations of the Theory of Signs and established the syntactics, semantics, and pragmatics distinction. Stamper extended that structure for organizational information systems, and Dietz used the same inheritance in DEMO. These are therefore not unrelated frameworks that happen to agree.
I use this lineage because it has resources for dealing with meaning and commitment in organizations, not just formal representation. Formal approaches are strong on syntax and formal semantics; they are weaker on the pragmatic and social levels where organizational purpose, authority, and accountability live.
Wittgenstein supports much the same conclusion from outside this lineage. In the later work, especially Philosophical Investigations, meaning is constituted through use inside shared practices of application and correction, which supports the claim that referential meaning is not enough by itself.
Semantics: Referential Meaning
What the Level Is
At the semantic level, the question is what a sign refers to. In Dietz's informa theory this is the proposition component of a communicative act. A statement such as "agreement is active" is not yet a request, approval, or warning. At this level it is a claim about a state of affairs.
Example. Suppose one system uses Agreement to mean a legal agreement that has been accepted by all parties. Another uses Agreement to mean an operational record created before signature and later activated. The strings may match and the databases may interoperate, but the meanings do not. That is a semantic issue, not a workflow issue.
What LLMs Actually Do Here
Large language models work mainly through distributional semantics. They learn patterns of use across large bodies of text. They are good at relational meaning: which terms cluster together, contrast, or imply one another. What they do not have on their own is a stable organization-specific tie between a term and its referentThe thing in the domain that the term refers to, such as a signed agreement rather than a draft record..
Context does much of the work here, but the context has to be supplied. A human domain expert may carry that context from one meeting to the next. A model does not unless that continuity has been externalized and supplied again. More scale does not remove that requirement.
For example, a model can often infer what status probably means from surrounding text. It cannot, by itself, settle whether a billing status of active means billable, contractually active, operationally provisioned, or merely not yet closed. In many enterprises those are different things.
Where Context Lives
At this level, the working context should live in the conceptual schema. The schema defines the terms, distinctions, and constraints relevant to the domain and the organization, and the agent uses that context rather than establishing it.
That is why semantic authority has to stay human-held. If the schema is wrong or incomplete, the model will often process the wrong meaning consistently rather than expose the mistake.
Note also the equal and opposite mistake: trying to model everything. The schema should cover what is important for the purposes in scope, especially where misinterpretation would have real organizational consequences. A schema that attempts to model the whole domain is usually harder to own, validate, and correct.
What Can Be Automated vs. What Requires Human Authority
| Level | Can be automated | Requires human authority |
|---|---|---|
| Semantics | Processing within a defined schema, term mapping, consistency checking, applying established constraints | Deciding what terms mean here, deciding which distinctions matter, judging adequacy in a novel situation, answering for a bad schema |
Anticipated Rebuttal
One likely rebuttal is that models already show sophisticated semantic understanding without a human-defined schema. Fair enough, if the claim is about competence. My point is different. Competence is not authority. A system can process meaning well and still not be the right place to decide what a term means in a particular organizational setting.
Pragmatics: Purpose in Use
What the Level Is
At the pragmatic level, the issue is no longer just what a proposition refers to, but what is being done with it. In Dietz's terms this is the intention component of a communicative act. The proposition might be "invoice 418 is unpaid." The pragmatic difference is whether that is being used to inform, request collection, trigger a hold, or support an exception review.
Example. "Agreement 12345 is active" may support several purposes. It may justify order submission, renew benefits eligibility, permit invoice generation, or support an audit check, although the underlying fact may be the same.
The Four Components and Their Automation Profile
The four-part intent model I use here, namely Intent, Goal, Applicability, and Outcome, is my operationalization of this level. It is not taken directly from Dietz or Stamper. The point is to make pragmatic structure explicit and inspectable instead of leaving it implicit in system behavior.
| Component | What it specifies | Example | Automation profile |
|---|---|---|---|
| Intent | A named purpose | Determine whether an Agreement may proceed to order submission | Not automatable in origin |
| Goal | What the purpose aims to achieve | Decide whether processing may continue | Automatable once specified |
| Applicability | The class of cases to which the purpose applies | Cases where an initial order depends on Agreement state | Automatable in recognition once defined |
| Outcome | What success looks like | Proceed, reject, or route for exception review | Automatable in assessment once specified |
Goal, Applicability, and Outcome can all be executed or assessed by a system once they are specified. The piece that cannot be system-originated is Intent itself, because originating a purpose requires standing in the organization. Someone has to be able to answer the question, "Why is the system pursuing this purpose in this domain?"
That requirement is traceable in Dietz. Authority is acquired through authorization or delegation, and the unit of authorization is the actor role in an organizational structure. A purpose with no traceable authorization path is not a governed purpose. It is just behavior.
Where Context Lives
At runtime, this specification often reaches the model through the prompt or system context. That does not make prompt text the same thing as governed intent. The prompt is only the carrier. Ownership, versioning, applicability, revocability, and accountability have to exist outside the prompt if they are to exist at all.
So when someone says the intent layer is just prompt engineering, the short answer is no. Prompt engineering is the delivery mechanism. It is not the governance structure.
What Can Be Automated vs. What Requires Human Authority
| Level | Can be automated | Requires human authority |
|---|---|---|
| Pragmatics | Goal-directed execution within a specified intent, applicability recognition, outcome assessment, reporting | Naming and owning the purpose, defining the goal and success condition, judging fit for unanticipated cases, answering for bad outcomes |
Anticipated Rebuttal
One likely rebuttal is that models can infer purpose from context and act accordingly, but that is a capability claim. The issue here is not whether the system can infer a purpose. The issue is whether anyone authorized that purpose and can answer for it when it was the wrong one. Making intent explicit is how accountability attaches to behavior.
Social / Performa: Commitment
What the Level Is
The social level is where commitments live. In Dietz's transaction structure, this is the level of coordination acts such as request, promise, declare, and accept. It is also the level at which a production act brings about the promised result.
Example. A system may collect an agreement, validate fields, route it for review, and produce a status of approved. The commitment is made at the point at which the organization says, in effect, "this agreement is approved" or "this order is accepted." That is not just information processing. It creates an obligation.
Much of the operational work around that commitment can be automated. What cannot be removed is answerability for the commitment itself. If a declaration is issued and no identifiable human remains accountable for it, the workflow may complete, but the commitment is left without a clear bearer.
Delegation in Dietz's Terms
Dietz is precise here. Authority over coordination acts can be delegated, but the production act cannot simply be delegated in the same loose sense; it changes hands only if the role changes hands. Liability does not transfer; it traces back to the delegator however many levels of delegation intervene.
For AI, the implication is that an agent can carry delegated authority over routine coordination acts, such as issuing a standard request for missing data, routing an agreement to the next queue, or sending a confirmation under defined conditions. It cannot be the final bearer of liability. In a business setting, that liability remains human.
This is also where the pragmatic and social layers join. A named actor role is authorized to pursue a named intent under defined conditions. The intent says what purpose is being pursued. The social layer says who may pursue it.
What Can Be Automated vs. What Requires Human Authority
| Level | Can be automated | Requires human authority |
|---|---|---|
| Social | Routine coordination acts, production work, status reporting, anomaly flagging, escalation routing | Liability for the delegation, accountability for whether commitments were kept, judgment in discussion states, authorization of the delegation itself |
Anticipated Rebuttal
The strongest rebuttal here is that there are already systems that appear to manage commitments end to end. My answer is that operational management and accountability are different. A system can execute every step in a transaction and still leave unanswered who is responsible when the result is wrong. In organizational terms, that missing answer is the real defect.
Capability Is Not Authority
The point can be reduced to one table.
| Semiotic level | Architectural layer | What can be automated | What requires human authority | The answerability test |
|---|---|---|---|---|
| Semantics | Conceptual schema | Processing within defined meanings, consistency checking, constraint application | Establishing what terms mean, deciding distinctions, judging adequacy in novel situations | Who answers when the schema is wrong for the case? |
| Pragmatics | Intent layer | Goal-directed execution, applicability recognition, outcome assessment | Naming and owning the purpose, defining applicability and success, judging fit in unanticipated cases | Who answers when the purpose produces the wrong result? |
| Social | Accountability structure | Routine coordination acts, production work, escalation detection | Liability for delegation, accountability for commitments kept or not kept, authorization changes | Who answers when the commitment was not kept? |
The point at issue here is authority, not capability. Better model performance may shift what can be executed automatically; it does not remove the requirement that someone remain answerable for meanings, purposes, and commitments.
A system can be authorized by people. It cannot authorize itself in the relevant organizational sense. Someone must remain answerable for meanings, purposes, and commitments. That is why this boundary is durable.
Hybrid AI: Where Language Models Actually Fit
None of this means language models have no place in business operations. It means their use should be shaped by the same structure.
Input and Output as Distinct Governance Problems
The input problem is interpretation. Natural-language requests, emails, chat messages, and external signals often arrive in forms that symbolic systems do not handle well on their own. Models are useful here because they are good at ambiguity resolution and candidate mapping.
The output problem is correctness. Once the system produces a decision, status, or transaction result, that output has to be validated before it is treated as organizationally binding. This is where governance becomes operational. If output validation is bypassed, the system has discarded its most reliable checkpoint.
The Orchestration Inversion
For business operations, what I would call the orchestration inversion does not follow the natural flow of the work. The usual pattern is natural-language input, model interprets the purpose, model chooses a tool, and model decides what happens next. That may be acceptable for personal productivity; for business operations it is usually the wrong default.
Business operations are usually triggered by deterministic events: an API call arrives, a state condition is met, a scheduled review fires, a rules engine is invoked, or a transaction enters an exception state. The orchestration layer should own that control flow and call the model only where interpretation or bounded judgment is needed. The deterministic process should call the model, not the reverse.
First-Order Logic, Production Acts, and Where LLMs Help
Dietz holds that the essential organizational model is expressible in first-order logic. This is relevant because symbolic execution engines already handle that terrain well. Where a rule is precise, routine, and auditable, replacing it with a language model usually gives up verifiability without gaining anything necessary.
This is close to the point one sees in rule engines and validation components. If the rule is well-specified, set-based and symbolic execution are usually the better fit. Language models are more useful in the parts the formal system cannot pre-state cleanly, such as interpretation of messy input, retrieval of relevant context, confidence-based triage, and support for judgment where the case is under-specified.
There is also a middle ground worth noting. Logic can be brittle in the sense that if a condition is encountered that has not been explicitly handled, the result may be an error, a dead end, or a generic fallback. In some of those cases there may be an opportunity for AI to provide assistance; however, that assistance should be introduced only where it can be made reliable, transparent, and reviewable.
The Scope of These Requirements
These requirements concern the operations of a business, meaning the transaction kindsTypes of business acts, such as approve invoice or accept order., product kindsTypes of business results, such as insurance policy or shipped order., actor roles, and commitments that define what the organization essentially does. They are not automatically requirements for software development or personal productivity tools.
If the organization's product is software, then software development is part of the essential operation and the points made here apply directly. Otherwise, development usually sits at a lower implementation layer. This distinction is important because many readers will otherwise map the argument onto AI coding assistants, task bots, or workflow helpers and assume it is making a general argument against automation. It is not.
The relevant question is always: what is the organization essentially committed to producing, and for whom?
What This Leaves Us With
The three conditions established here are governed meaning, authorized purpose, and human answerability for commitments. They follow from the structure of organizational meaning and from the conditions under which a commitment is binding at all.
An AI governance architecture for business operations either preserves those conditions or creates accountability gaps. Better capabilities alone are unlikely to close those gaps because the defect is structural, not just technical.
The next question is practical: what would a framework look like that keeps these boundaries intact while still making effective use of AI? The companion document Intent-Driven AI Delegates takes up that question more directly by outlining how these constraints can be reflected in the design of a governed hybrid architecture.