Thesis. A well-built ontology lets an organization understand and act on its own model of reality; letting another party rely on a specific claim additionally requires deciding, per claim, whether it is supported, by whose authority it was admitted, and what has happened to it since — work that sits beside the ontology rather than inside its schema.

Research question. What is the difference between understanding business reality and establishing state that other parties can safely rely on?

From knowledge representation to operational ontology

In knowledge engineering, an ontology was classically defined as an explicit specification of a conceptualization (Gruber, 1993): shared vocabulary for classes, relations and constraints, so that different systems could interpret the same terms the same way. Semantic-web standards such as OWL 2 made that specification formal enough for automated reasoning. The goal was shared understanding.

Enterprise platforms moved the idea from description to operation. Palantir's documentation describes its Ontology as representing "the decisions in an enterprise, not simply the data", and models each decision as four components — Data, Logic, Action and Security (Palantir, Why create an Ontology?). Objects, properties and links are the nouns; actions are the verbs; logic binds models and business rules; and security combines marking-, purpose- and role-based policies, lineage and release management, with actions subject to explicit authorization. Ontologies can be private to one organization or shared across several, so that people in different organizations work with the same object, link and action types (Palantir, Ontologies overview).

An operational ontology in this sense is not a static object model and not just a knowledge graph. It is a governed, executable model of an enterprise.

What the ontology layer already solves

It is worth being precise, because the point of this essay is not that ontologies fall short at their job.

Object and relationship layer. Typed objects and links give agents and people a common vocabulary: a Supplier, a Facility, a Certification, and the links between them.
Logic. Business rules, models and functions can be evaluated against that structure.
Action. Changes can be staged, reviewed, permissioned and written back to operational systems, with logging.
Security and permissions. Access to objects, properties and actions can be constrained by role, purpose and markings, for humans and agents alike.
Cross-organization sharing. A shared ontology lets several organizations operate on the same types under their own access controls.

If a question is "how do we model our operations so humans and agents can reason and act inside them safely?", these capabilities are the answer.

Where a further question begins

Cross-party reliance asks something different. Not "is this a valid Certification object?" but "may I, a buyer outside your organization, rely on this claim that this facility holds this certificate, for this purchase?"

A syntactically and semantically valid object answers the first question. It does not by itself answer the second, because the second depends on properties of the claim, not the schema:

Question	Answered by
Is `Certification(holder=Facility A, standard=ISO 9001)` a well-formed object?	schema and type constraints
May user U see or edit it?	permissions and markings
Who asserted that Facility A holds it, and what supports the assertion?	attribution and evidence, per claim
Did that party have standing to assert it, or to withdraw it?	authority over this kind of claim
Has anyone else confirmed, disputed or contradicted it?	independent assertion streams
Was it current at the time the buyer relied on it, and what was known then?	time-aware history and resolution

Ontology platforms can store all of these as properties or linked objects, and they can enforce access to them. What a recipient outside the organization needs in addition is a portable, per-claim account of admission and history that it can evaluate under its own policy, without having to trust the issuer's internal model or permissions.

Three things cross-party reliance adds

We describe the additional work in three parts. In Tinor these are architectural commitments; their runtime coverage is partial and is described as such below.

Fact admission. Interpretations — from a model, a parser or a person — are candidates. They become admitted state only through a deterministic path that checks the claim's grounding in source material, the sufficiency of its evidence class, the binding of subject and object, and the authority of the party making it. Model output never decides admission.
State resolution. What holds "now" is computed on read from an append-only history, for a stated subject, time point, knowledge cut, viewer and purpose. Independent assertions coexist; disagreements are reported, not silently resolved; withdrawals change standing without erasing history.
Verifiable history. Each admitted claim is an attributable event with content commitments, so a recipient can check integrity and attribution independently — attribution in the sense formalized by PROV-O (which agent, which activity, derived from what) — while recognizing that integrity is not truth (see Proof Is Not Truth).

None of this replaces an ontology. A system can, and often should, use an ontology for vocabulary, structure and in-organization action, and use an admission-and-resolution layer for claims that leave the organization.

A worked example: a certification claim crossing an organizational boundary (hypothetical)

Supplier S tells buyer B: "Facility A is ISO 9001 certified." B's procurement agent must use this claim within a limited scope — qualifying S for one purchase of moulded parts.

Object and relationship layer. In S's ontology, Facility A is linked to a Certification object with standard, certificate number, scope and expiry. This is a correct model of S's understanding. It tells B's agent what is being claimed and in what vocabulary.

Permissions and rules. S's platform controls who inside S may edit that object, and may share it with B through a shared space. That governs access. It does not tell B whether the content is right, who stands behind it, or whether S's editor was entitled to assert it.

Raw claim versus admitted record. From B's side, the shared object is a claim by S. An admitted record would also carry: issuer S; evidence class (uploaded certificate file, with a content hash); whether any independent check exists (e.g., a dated lookup on the certification body's register); validity window; scope; and any later confirmation, dispute or withdrawal.

How an independent recipient decides to rely. B's agent applies B's policy, for example: for supplier qualification, accept a certification claim if it is asserted by the supplier, backed by a certificate file, confirmed by a register check within the last 90 days, within validity, and covering the purchased product scope; otherwise escalate to a buyer. The decision is B's, under B's policy, over S's record. If the scope covers "assembled units" but the purchase is for moulded parts, B's agent escalates — even though S's ontology object is perfectly valid.

The ontology made the claim intelligible. Admission and resolution make it reliable for someone who does not share S's model or S's trust boundary.

Counterexamples and limits

Shared ontologies already span organizations. Where all parties operate inside one shared, well-governed ontology and trust its administrators, much of the argument above weakens: the shared environment is the trust boundary. Our argument applies where recipients cannot or will not share that boundary — open supplier networks, regulators, unknown counterparties, other companies' agents.
Admission can be built inside an ontology. Nothing prevents modelling claims, issuers and evidence as ontology objects with admission actions. The architectural point is the separation of concerns, not the product boundary.
Admitted is not true. Admission makes a claim attributable, supported to a stated degree, and correctable. It does not make the claim correct.
Policy plurality. Different recipients will apply different reliance policies. That is a feature, but it means "relyable" is always relative to a policy, never absolute.

An untested hypothesis on engineering cost

We hypothesize that separating a small, fixed protocol core (claims, evidence, authority, events, resolution) from domain-specific vocabularies lowers the cost of supporting a new industry, compared with extending one large cross-industry model. This is untested. We have no comparative measurements, and Can One Reality Protocol Work Across Industries? (forthcoming) is where we intend to define how it could be tested.

Where Tinor stands

Tinor's protocol fixes six core event types and keeps domain meaning in versioned Profiles and domain semantic packages; model output is a candidate only, and admission is a deterministic, owner-held path. Bounded parts of fact admission and standing resolution exist in Tinor's reference implementation for specific claim types; broad coverage does not. This essay is a design perspective, labelled Design Proposal.

References

Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition 5(2). doi:10.1006/knac.1993.1008
W3C (2012). OWL 2 Web Ontology Language Document Overview (Second Edition). w3.org/TR/owl2-overview
Palantir. Why create an Ontology? palantir.com/docs
Palantir. Ontologies — Overview (private and shared ontologies). palantir.com/docs
W3C (2013). PROV-O: The PROV Ontology. w3.org/TR/prov-o

Beyond Ontology: From Understanding Reality to Relying on It