Proposal for a Semantic Kernel for Business Workspaces - Part 2

A Grammar of Meaning: Types, Canonical Units, Gauge Invariance

On September 23, 1999, NASA lost the Mars Climate Orbiter. The ground software computed thruster impulse in pound-force seconds; the navigation software consumed the same numbers as newton-seconds. Neither team was wrong within its own convention. The interface between them declared no unit - so one of them was wrong by default, and a $327 million spacecraft disintegrated in the Martian atmosphere.

Business software commits this exact error every day. The stakes per incident are lower; the aggregate cost is not. A margin stored as 0.15 in one system and 15 in another. A duration that is minutes here and business days there. A "revenue" field that one report reads gross and another reads net. Each pair of consumers is internally consistent and mutually wrong, and nothing in the storage layer says which one is right - because the storage layer was never asked to say.

Part 1 of this series proposed a semantic kernel: seven irreducible primitives - entity, event, principal, commitment, policy, receipt, principal scope - out of which every governed business operation is expressible. The kernel is necessary but not sufficient. It says what kinds of things exist; it does not say what a given field means, in what unit its value is stored, or how one concept relates to another. That requires the layer this article proposes: a type system with a grammar - not a schema registry, and not a data dictionary.

Why a dictionary is not enough

The industry's reflex for "shared meaning" is documentation: a business glossary, a data dictionary, a catalog with definitions attached. These fail for the same reason style guides fail without linters - they describe meaning without making violations mechanically detectable. A definition that nothing can enforce is a suggestion, and suggestions do not survive contact with deadlines.

The alternative is the move programming languages made decades ago: put meaning into a type system, where an ill-formed declaration is not a documentation gap but a compile-time error. The test of a semantic layer is not whether meaning is written down; it is whether a violation of meaning can fail a build.

Three tiers: closed, closed, open

The type system I propose has three tiers, and the pattern of which tiers are closed carries most of the design:

Tier 1 - the seven kernel primitives. These are the types of types: every concept in the system is, categorically, an entity, an event, a principal, a commitment, a policy, a receipt, or a scope. This tier is closed by constitutional rule (Part 1's argument).

Tier 2 - a small closed set of foundation types. Roughly a dozen: party, product, account, work item, document, asset, case, calendar object, location, risk, contract, watch, signal. These are the concepts that recur in every industry under different names, and the claim that justifies closing this tier is strong: a party means the same thing in Sales, Procurement, HR, and Legal - and to the workspace agent, and to every connected external system. Cross-domain understanding is only possible if the middle vocabulary is shared, and it is only shared if it is closed.

Tier 3 - an open set of domain concept types. A sales opportunity, a job candidate, a maintenance ticket, an aircraft. Every domain concept must declare a parent that is a foundation type, and must be exactly one hop away from it: a candidate is a party; a maintenance ticket is a work item; an aircraft is an asset. The one-hop rule is not pedantry - it is a diameter bound on the meaning graph. Any two domain concepts, from any two domains that have never heard of each other, are at most two hops apart through their shared foundation types. That bound is what lets a newly added domain be understood by every existing one at generation time, with no integration project.

Closed, closed, open: the openness lives entirely at the edge, and the shared meaning lives entirely in the core. Extension is welcome; redefinition is structurally impossible.

The grammar

Membership in the type system is not free. Every type - foundation or domain - is admitted only through a complete declaration with six elements:

• a type code - the stable, machine-readable identifier;
• a semantic category - which kernel primitive this type instantiates;
• a parent type - the single foundation type it derives from (null only for foundation types themselves);
• canonical fields - each carrying its own semantic type, its canonical unit, and its PII classification;
• relationship types - the typed edges this concept may participate in;
• an expression profile - where the concept may lawfully appear.

A declaration missing any element does not produce a warning, a default, or a TODO. It fails at declaration time. Adding a concept without stating its semantic category is a compile-time error - in exactly the sense that an ill-typed program is.

Two of the six elements deserve emphasis. The PII classification means personal data is identified at the type level, when a concept is declared - not discovered later by an audit crawling production data. And the relationship types mean the meaning graph is typed end to end: every edge between concepts has a declared kind, which is what makes the graph traversable by a machine rather than merely drawable by a human.

The stored value is the unit

Now back to the Orbiter. The rule that prevents its failure class is blunt: the stored value IS the canonical unit. No implicit conversion exists anywhere in the system. Concretely:

• a percentage is stored as a decimal fraction between 0 and 1;
• a monetary amount is stored in the smallest indivisible unit of its currency;
• a duration is stored as an integer number of seconds;
• dates and timestamps are stored as ISO 8601 strings, timestamps in UTC.

Conversion - to 15 %, to CHF 1'250.00, to 3 days, to a local timezone - is exclusively a display-layer concern. Values are validated against their declared unit at the system boundary, before they are ever persisted.

I hold this rule with the conviction of someone who paid for it. In the reference implementation's history there is an incident in which a UI rendered a field as 0.5% while an agent computed with 0.5 as a fraction - a 100× disagreement about the same stored number. Both consumers were right about their own convention; the storage had declared no canonical unit, making one of them wrong by default. The Orbiter sentence, verbatim, at business scale. What makes the incident instructive is how it surfaced: not in code review, not in tests - both consumers were internally consistent - but only when someone asked why two surfaces disagreed.

The rule matters more, not less, as agents join the workforce. A human glancing at a absurd rendering gets suspicious; an agent computes confidently on a misread magnitude and acts on the result. Declared units are not data hygiene. They are a precondition for delegating arithmetic to something that will not squint at the answer.

Gauge invariance

The last element of the grammar borrows its name from physics deliberately. In gauge theory - the term is Weyl's - physical law is invariant under local changes of measurement convention: the physics does not change when you relabel your instruments. The semantic analogue: the meaning of a contract must be invariant under changes of language, locale, branding, and synonym preference.

The rule that implements it: contract identifiers are gauge-invariant codes; display strings live only in surface configuration. A human-readable label appearing inside a contract identifier is a compile-time error, not a style nit - because a label in a contract is a coupling between meaning and one particular way of presenting it, and that coupling is exactly what makes systems unrenamable, untranslatable, and brittle to rebranding.

The payoff is concrete. The same typed contract renders as a German-labelled form for an operator in Zürich and as a stable tool identifier for an AI client - simultaneously, from one source. A tenant that renames "Customer" to "Client" across its entire workspace touches zero contracts, breaks zero agents, invalidates zero integrations. The test is simple and worth applying to any system: if renaming a concept in the UI would break a machine consumer, meaning and presentation were coupled all along. Gauge invariance is the discipline that keeps them apart.

What the grammar buys

Assemble the three mechanisms and the guarantee compounds: every value has one declared interpretation (canonical units), every concept has one declared position in a bounded meaning graph (three tiers, one hop), and no meaning is entangled with any presentation (gauge invariance). Every consumer - human surface, workspace agent, external AI client, connected system - reads the same value the same way, and none of them had to negotiate about it.

What none of this yet answers is who is allowed to see and do what, through which surface. Defining lawful meaning and defining lawful exposure are different problems, and conflating them is the original sin of most platform architectures. That split - one canonical graph compiling into a human surface and a machine surface via MCP, neither allowed to drift from the other - is Part 3.

These proposals are drawn from the architecture of Coreline OS, the agent-native operational platform I am building, where this type system is implemented as a governed artifact set: thirteen foundation types, a growing tier of domain concepts, and a conformance suite that enforces the grammar in CI - semantic category present, parent exactly one hop, canonical-unit compliance for monetary and temporal fields, every relationship type resolvable. A type declaration that violates the grammar does not degrade the system; it fails the build. The canonical-units law exists in that codebase for the least theoretical reason imaginable: the 0.5% incident is in its git history.

---

References

• Mars Climate Orbiter Mishap Investigation Board. Phase I Report. NASA, 1999.
• Pierce, B.C. Types and Programming Languages. MIT Press, 2002.
• Guarino, N. & Welty, C. "Evaluating Ontological Decisions with OntoClean." Communications of the ACM, 45(2), 2002.
• Weyl, H. "Elektron und Gravitation I." Zeitschrift für Physik, 56, 1929 (origin of gauge invariance).
• ISO 8601: Date and time - Representations for information interchange. ISO.