The Proposal: Why Business Workspaces Need a Semantic Kernel

Every business application defines meaning privately. What a "customer" is, what an "approval" does, when a "commitment" is breached - these definitions live inside each system's schema, expressed in that system's vocabulary, enforced by that system's code. When two systems must cooperate, the meaning is reconstructed at the boundary: a connector maps account_id to customer_ref, a consultant decides that Salesforce's "Closed Won" corresponds to NetSuite's "Order Confirmed," and an integration test hopefully catches the cases where it doesn't.

This is the N×M problem, and the industry has spent two decades attacking it with connectors, iPaaS layers, API standards, and lately with "open table" and semantic-interchange initiatives. All of these are edge treatments. None of them address the root cause: there is no shared semantic substrate beneath business software. Meaning is defined N times and reconciled N×M times, heuristically, at the edges - where it is least visible and most fragile.

For twenty years this was an inconvenience with a services industry attached to it. AI agents turn it into a structural failure.

Why agents change the stakes

An agent operating across business systems needs what integration middleware never needed: it must reason over meaning, not just transport payloads. A human integrator resolves semantic ambiguity with context and judgment, once, at design time. An agent resolves it at runtime, continuously, and - critically - it must be governed while doing so.

Here is the difficulty in one sentence: you cannot govern an agent against meaning that was never formally defined. If "approval" is a status string in one system, a workflow step in another, and an email convention in a third, then a policy like "agents may not bypass approvals" is not enforceable - it is not even expressible. The policy has no formal object to refer to. Every guardrail built on top of undefined semantics is a behavioral hope, not a constraint.

The current response - prompt the model harder, add a guardrail classifier, log everything - treats a definitional gap as a behavioral problem. It is the equivalent of an operating system with no memory protection asking each program, politely and in natural language, not to write into its neighbor's address space.

That analogy is the proposal.

The kernel move

Operating systems solved a structurally identical problem long ago. Applications do not negotiate with each other about what a file, a process, or an address space is. A small, closed kernel defines these primitives; everything else is userland, built on the primitives and constrained by them. The kernel is small because every additional primitive is a permanent liability; it is closed because its stability is what makes the userland ecosystem possible.

I propose the same move for business operations: a semantic kernel - a minimal, closed set of irreducible primitives out of which every governed business operation is expressible, and above which everything else (domains, workflows, user interfaces, agent tools) is derived userland.

The method for finding the set matters more than the set itself. Candidate primitives are tested against known classes of business operations across industries, held up against formal ontological categories, and subjected to two filters:

1. Reducibility - if a candidate can be expressed through the others, it is removed from the kernel and relocated to a derived layer.
2. Irreducibility - if a class of business operations cannot be expressed without a candidate, it is admitted, whatever the cost.

Applying these filters yields, in my proposal, exactly seven primitives.

The seven primitives

1. Entity — a thing the business tracks, with identity, typed fields, and lifecycle state as a property, not a separate concept.
2. Event — an immutable, actor-attributed record of something that happened; the append-only substrate of all state.
3. Principal — an actor, human, agent, or system, capable of producing events.
4. Commitment — an obligation with a deadline and a breach semantics: the primitive from which approvals, SLAs, and promises derive.
5. Policy — a rule constraining which events may be produced, by whom, under which conditions.
6. Receipt — the durable record of what an operation meant — outcome, downstream consequences, provenance — not merely which fields changed.
7. Principal Scope — a bounded, expiring grant of authority: the explicit list of actions a principal may take, and the only path by which any event enters the system.

Two remarks on the shape of this list.

First, note what a conventional platform architect would expect to find here and doesn't. Action, workflow, lifecycle state, approval, and ownership were all candidates - and all failed the reducibility test. An approval is a commitment held by an approver, with a deadline and breach semantics; it needs no primitive of its own. A lifecycle state is a property of an entity. Workflows and actions are operational logic - userland - expressible entirely as policies over events. Ownership is a relation involving a principal. An earlier iteration of this kernel carried twelve primitives; the reduction to seven was not simplification for elegance but the removal of everything that turned out to be derivable. A kernel keeps its authority by refusing residents.

Second, note the asymmetry between Policy and Principal Scope. Policy says what is permitted in general; Principal Scope says what this actor may do right now. The separation is deliberate, and it produces the single most consequential property of the architecture: a principal cannot produce an event without a valid scope permitting that action. Not "will be blocked" - cannot construct the event. Duties that other systems enforce by detection and sanction after breach become, here, structural impossibilities. (Part 4 of this series is devoted to what this does to agent security; the preview is: prompt injection stops being a behavioral problem.)

Standing on prior theory

A proposal like this should be suspicious of its own novelty, so the primitive set was validated against four bodies of theory that have each formalized a slice of business reality:

• DEMO (Dietz's Design and Engineering Methodology for Organizations) formalizes the transaction: a coordination pattern of request, promise, execution, declaration, acceptance. The kernel's Commitment and Event primitives must - and do - express the full transaction axiom; DEMO's coordination acts map onto commitment lifecycle events.
• REA (McCarthy, The Accounting Review, 1982) grounds economic exchange in resources, events, and agents. REA's dualities are expressible as typed events linking entities and principals; nothing in REA requires an eighth primitive.
• Deontic logic and the ADICO grammar of institutions (Crawford & Ostrom, APSR, 1995) decompose institutional statements into attributes, deontic operator, aim, conditions, and sanctions. These decompose cleanly into Policy (permission and prohibition) and Commitment (obligation) - with the notable result that most deontic duties convert into structural constraints, and only two genuinely resist conversion: the duty to fulfill a commitment and the duty of an approver to respond. Precisely the two that cannot be made structurally impossible remain duties.
• Hohfeld's jural relations (1913) - right/duty, privilege/no-right, power/liability, immunity/disability - map onto the Policy–Scope–Commitment triad, with Hohfeldian powers (the ability to change others' legal relations) expressed as scoped, receipt-producing actions.

The claim is not that these theories endorse this kernel. The claim is narrower and more useful: every operation class these theories formalize is expressible in the seven primitives, and no theory forced an eighth.

An honest boundary

It would be rhetorically convenient to claim the set is complete. It would also be false in a specific, checkable way: formal completeness for business-operations governance does not exist as a published theorem in any theory. There is no result to appeal to, and I will not manufacture one.

What can be defended is a bounded claim: the seven primitives are ontologically complete for a governed scope - the domain of auditable, policy-constrained business operations - as evidenced by testing against the theories above and against a cross-industry process corpus (APQC's Process Classification Framework). And the claim carries its own falsification conditions: a demonstrated operation class requiring an eighth primitive, or a demonstrated reduction of one of the seven, reopens the kernel. A kernel amendment should be treated the way constitutional amendments are - rare, deliberate, and evidence-driven - but the amendment process must exist, publicly, or the completeness claim degrades into marketing.

One further boundary: the kernel governs ontological facts - what happened, who did it, under what authority, with what consequences. Semantic classification, entity resolution, and enrichment - the interpretive machinery that decides which entity a record refers to - sit above the kernel, in what DEMO would call the infological layer. The kernel governs the consequences of an interpretation (the resolution event, its actor, its scope), never the interpretive computation itself. Keeping inference out of the kernel is what keeps the kernel verifiable.

What follows

If the kernel defines lawful meaning, everything else becomes derivation: a type system with a grammar above the primitives (Part 2); the compilation of one canonical graph into two governed surfaces - one for humans, one for AI agents via MCP (Part 3); agent authority as a capability-security property rather than a prompt (Part 4); and the hardest problem, admitting learning into the system without semantic drift (Part 5).

These ideas are not speculative. They are drawn from the architecture of Coreline OS, an agent-native operational platform I am building, where the seven primitives are load-bearing - and where the kernel is held to a standard the layers above it are not. Its invariants - hash-chain integrity of the event log, scope attenuation monotonicity, DENY dominance in policy evaluation, irreversibility of terminal commitment states - are verified three independent ways, each covering the others' blind spot:

• Bounded exhaustive model checking (TLA+/TLC). TLA+ is Lamport's language for specifying systems as state machines; TLC, its model checker, enumerates every reachable state of a bounded model and checks the invariants in each - exhaustion, not sampling. The bounds are small by design: decades of practice support the small-scope hypothesis that design flaws, if present, manifest in small counterexamples, and AWS has documented finding subtle production bugs in DynamoDB and S3 exactly this way (Newcombe et al., CACM 2015).
• Unbounded proof (Z3). Z3 is the SMT solver of de Moura and Bjørner. Each key algebraic property is encoded and its negation handed to the solver; an UNSAT result means no counterexample exists for any input whatsoever - the bound TLC accepts is removed for the properties that admit algebraic formulation.
• Adversarial property-based testing (Hypothesis). Model checking and proof verify the specification; property tests bind the implementation to the same properties under tens of thousands of adversarially generated inputs, closing the model-to-code gap that formal verification alone leaves open.

No single layer is sufficient; the triangulation is the point. Every surface - human and machine - then compiles from contracts over these verified primitives. The series presents the architecture as a proposal because I believe the pattern generalizes beyond any one product: business software is overdue for its kernel moment.

---

References

• Dietz, J.L.G. Enterprise Ontology - Theory and Methodology. Springer, 2006 (DEMO).
• McCarthy, W.E. "The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment." The Accounting Review, 1982.
• Crawford, S.E.S. & Ostrom, E. "A Grammar of Institutions." American Political Science Review, 1995.
• Hohfeld, W.N. "Some Fundamental Legal Conceptions as Applied in Judicial Reasoning." Yale Law Journal, 1913.
• Lamport, L. Specifying Systems: The TLA+ Language and Tools. Addison-Wesley, 2002.
• Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker, M. & Deardeuff, M. "How Amazon Web Services Uses Formal Methods." Communications of the ACM, 58(4), 2015.
• de Moura, L. & Bjørner, N. "Z3: An Efficient SMT Solver." TACAS, 2008.
• MacIver, D.R., Hatfield-Dodds, Z., et al. "Hypothesis: A new approach to property-based testing." Journal of Open Source Software, 4(43), 2019.
• APQC Process Classification Framework, Cross-Industry, v7.3.