Skip to content
Reality Runtime · Engineering Note · Series 2: Engineering Reality State

Reality Needs a Type System

Can real-world claims be compiled into representations with machine-checkable constraints before anyone accepts or acts on them? An engineering note on subjects, scope, time, authority and evidence as types.

By TinorPublished October 2026Evidence: Design Proposal

Thesis. Many failures in agent-handled business claims are not falsehoods but type errors — a missing subject, an unbounded period, a capability phrased as a commitment, a claim made by a party without standing — and these can be caught mechanically before admission if claims are compiled against explicit contracts, leaving evidence and judgment questions to the steps that genuinely need them.

Research question. Can real-world claims be compiled into representations with machine-checkable constraints before they are accepted or acted on?

Natural language underdetermines four things

Business statements routinely leave out exactly what a relying party needs:

  • Subject. "Our factory" — which legal entity, which site?
  • Scope. "Certified" — for which standard, products, processes, sites?
  • Time. "Monthly" — which months? Measured, forecast or promised?
  • Relation. "Can deliver" — a description of capability, or a commitment to a counterparty?

A human reader fills these gaps from context and is often wrong in ways that surface only later. A model fills them from statistical plausibility. A typed representation refuses to fill them silently.

Why not a generic information-extraction schema?

Generic extraction schemas — entity, relation, attribute, often expressed in JSON Schema or validated with shape languages such as SHACL — check that a structure is well-formed. That is necessary and useful. But "well-formed" is not the bar for reliance. A capacity record can be a valid JSON object and still have no period, mix two sites, or be authored by someone with no standing to speak for the company. The types we need are not only shapes of data but roles in a claim: who is responsible (an agent in PROV-O terms), about what, as of when, under what authority, supported by what.

The roles, as Tinor's protocol defines them

Tinor's protocol keeps a small set of concepts distinct. We use them here exactly as the protocol does, without adding new core objects:

Concept Role in a claim Not to be confused with
Principal the persistent party that asserts and bears responsibility — a person, organization, device, AI agent or system a login account or an app session
Authority who may act for whom, over what, within which scope — expressed through explicit delegation and authorization grants, not implied by governing or owning something permission to call an API
Agreement shared state derived from the parties' own confirmations — nobody's single object one party's description of a deal
Evidence supporting material, referenced by content commitment; distinct from declarations and from published resources the truth of what it shows
Atomic Event one attributable expression by a Principal about an Object, using one of six core types: create, transition, handoff, attest, verify, revoke a final verdict about reality

Two protocol rules matter for typing. First, one event, one layer of effect: a compound real-world act ("deliver and certify quality") is recorded as several events, never stretched into one. Second, commitments are not a special core type: a promise is an attest with a future-oriented claim predicate declared by its Profile, and an authorization is modelled as its own object with its own lifecycle.

Contracts: fixed core, extensible Profiles

Where do the types for a specific claim come from? Not from one giant industry ontology of the kind OWL 2 could express. Tinor separates:

  • a fixed protocol core — the concepts above, the six event types, hashing and signing — which does not change per industry;
  • versioned Profiles, which declare what a given kind of claim means: its payload fields, which core type each event binds to, its state machine, its fact identity (which fields make two assertions answer "the same question");
  • versioned Domain Semantic Packages, which carry vocabulary, aliases, units, locale labels and extraction hints that map outside language onto existing targets — and are explicitly forbidden from defining authority or event meaning;
  • a Target Contract per write target (compiled from published assets into a Compiled Target Contract), which pins the exact Profile, candidate schema, mapping and evidence requirements a candidate is checked against.

The reason to avoid a single cross-industry model is change management: every new domain would reopen everyone's semantics. With a fixed core and opt-in, versioned Profiles, a new domain adds contracts without altering existing ones, and old records stay interpretable under the exact contract version that admitted them.

What compilation checks — and what it cannot

Error class Example Caught by
Type / structure value not a number; unknown unit; required field missing schema in the pinned contract
Semantic strength "application received" mapped to "certificate issued" contract acceptance rules
Binding "our factory" matches two sites exact entity resolution
Time / period "monthly" without month bounds contract period rules
Authorization a sales agent's account submits a commitment on behalf of the company authority check at preparation and again at commit
Evidence class self-uploaded scan offered for "issuer attests" contract evidence requirements
Needs external evidence is the certificate actually valid today? register check or issuer confirmation
Needs human judgment does "assembly" fall within "manufacture"? named reviewer with authority

The first six are mechanical given a contract. The last two are not, and a well-typed system should route them rather than pretend.

Case: "Our factory is certified and can deliver 50,000 units monthly."

A supplier's sales email contains this sentence. All parties are fictional.

Split into propositions. It contains two claims of different kinds, which must not share one record:

  1. a certification status claim, and
  2. a capacity / delivery claim — which itself is ambiguous between a measured capacity and a delivery commitment.

Typed candidates.

[
  {
    "target": "credential (certification)",
    "subject": { "value": "our factory", "state": "ambiguous", "candidates": ["Ningbo site", "Suzhou site"] },
    "standard": { "state": "unknown" },
    "scope": { "state": "unknown" },
    "valid_period": { "state": "unknown" },
    "issuer_principal": { "value": "supplier sales account", "state": "asserted" },
    "evidence": { "state": "unknown" }
  },
  {
    "target": "capability (output capacity)",
    "subject": { "value": "our factory", "state": "ambiguous" },
    "value": { "value": 50000, "state": "asserted" },
    "unit": { "value": "count (units)", "state": "derived" },
    "period": { "value": "per calendar month", "state": "asserted", "note": "no month bounds given" },
    "scope": { "state": "unknown", "note": "which product?" },
    "method": { "state": "unknown", "note": "measured, nameplate or planned?" },
    "basis": { "state": "unknown" },
    "source": { "value": "email, sentence 2", "state": "asserted" }
  },
  {
    "target": "commitment (deontic attest)",
    "content": "can deliver 50,000 units monthly",
    "state": "unmapped",
    "note": "reads as capability unless a counterparty, quantity, schedule and accepting party are stated"
  }
]

The capacity fields follow the bounded measurement shape in Tinor's design: value, unit, period, scope, method, source and basis, with exact arithmetic, a closed unit table, and the rule that "monthly" means a declared quantity over an explicitly bounded calendar month — never silently annualized or divided by days.

Assessment outcomes.

Candidate Blocking issue Diagnostic (illustrative) Next step
Certification subject binds to two sites ambiguous entity ask which site
Certification no standard, scope, validity or evidence required field missing; evidence insufficient request certificate
Certification submitted by a sales account authority to be checked for this claim type confirm the submitting Principal may assert for the company
Capacity no product scope, method or month bounds required field missing; period imprecise ask: which product, measured how, for which months
Commitment not expressible as a capability measurement unmapped if a commitment is intended, record it as a separate commitment with counterparty and terms, approved by someone with authority

Nothing is admitted from this sentence alone. What the system can admit, if the supplier wants, is an evidence-only note: the supplier's sales email of this date states X — attributed, quoted, and explicitly not a structured fact.

After clarification. If the supplier answers "Ningbo site; housing model H-200; measured average output, January–March 2026", and uploads an ISO 9001 certificate for the Ningbo site, then:

  • the certification candidate can bind, carry evidence class "supplier-uploaded certificate", and be admitted as the supplier's own assertion, pending any independent register check;
  • the capacity candidate becomes three monthly measurements (or one measurement over a stated interval), each with scope H-200 at Ningbo, method "measured", source the supplier's records, admitted as supplier-asserted;
  • the delivery promise remains unrecorded unless and until it is made as a commitment to a specific buyer.

Counterexamples and open challenges

  • Over-typing. Not every statement needs structure. Forcing everything into contracts produces friction; evidence-only notes are the release valve.
  • Contract coverage. A claim type without a Profile and Target Contract cannot be compiled. The honest result is "unsupported", which limits coverage until contracts exist.
  • Ambiguity that persists. Some suppliers will not clarify. The system must be comfortable leaving claims unadmitted.
  • Judgment boundaries move. Whether "assembly" is within a certificate's scope is a judgment today; a well-maintained domain package might make some such questions mechanical tomorrow — or might encode a wrong rule.
  • Type errors are not the only errors. A perfectly typed, admitted claim can be false. Typing catches the class of errors that come from vagueness, not deception.

Where Tinor stands

The concepts, the six core event types, Profile-declared fact identity, the bounded measurement shape, and compilation of candidates against pinned published contracts are recorded design decisions; bounded versions run in Tinor's reference implementation for a few targets (for example facility, enterprise details, credential and output capacity). General-purpose compilation of arbitrary claims is not built, and the case above is a design illustration, not a log of a production run. Design Proposal.

Related reading

References