First Principles · v1.1

Working document · Updated 2026-05-20

First Principles

The tie-breaker. When "industry-standard X" conflicts with operator reality, this document wins.

Most systems are built to satisfy databases; TOP is built to satisfy the human experience. We ground our entities in how humans actually work, then project that reality outward into the standards the world requires.

Want each principle shown against a real operator problem — the challenge in plain English, why the status quo hurts, and how TOP differs? See the companion: First Principles, Illustrated.

The Inversion: Human-Down, not Standards-Up

Most ontologies are built Standards-Up: they let regulatory schemas dictate how data is shaped, forcing operators to act as translators between their work and the database.

TOP inverts this. We build Human-Down.

This isn't just about naming; it's about where the complexity lives. In TOP, standards alignment is a projection. We treat standards as ephemeral targets. Systems shouldn't transform data, it should project it. We can emit (insert standard name) on demand, but the foundation remains anchored to the human.

The Move: We stop trying to make humans think like databases, and we start making databases reflect how humans actually work.

What this means concretely

1. Operator vocabulary names the operational entity. At the operational graph layer (the NGSI-LD surface that operators and applications interact with), entities carry the names operators use during their workday: Participant in clinical, Part in manufacturing, Client in fintech, Shipment in logistics. These are operational entity types, not the only valid formal expression of what they represent. The conceptual ontology layer underneath the pipeline (layer 5 of the six layers below) formalizes Person as a class, with Participant, Client, Driver as role projections, and SKOS-XL labels with provenance carry the cross-context vocabulary so Participant, Subject, Patient, and Claimant all map to the same underlying concept. The operator sees their vocabulary. The reasoner sees the formal model. Both are legitimate. Both are required.
2. Attribute names match what operators say or type. If an operator enters a "Batch ID" or a "Tracking Number," that is the attribute name.
   Yes: firstName, batchNumber, accountStatus, deliveryDate.
   No: USUBJID, LOT_QTY_HEX, KYC_STAT_01 (projection-time derivations).
3. Sub-objects represent workflow milestones, not data structures. We model "Informed Consent" or "Quality Check" because those are moments in a human's day, not because a database needs a join table.
   Yes: ConsentRecord, MaintenanceLog, TradeConfirmation, SafetyInspection.
   No: EntryProgressLink, DSRecord, RelationalAuditMapping.
4. Standards-alignment is a Projection, not a Constraint. Every entity definition carries its own cross-walks as documentation of what the projection adapter will emit, but the standard never dictates the shape of the truth.
   The Principle: A "Patient" has a birthDate. A FHIR adapter maps this to Patient.birthDate; an SDTM adapter maps it to BRTHDTC. The foundation remains human-readable.

   We are not deviating from SNOMED, FHIR, ICD, LOINC, MedDRA, RxNorm, gene ontology, or any other domain standard. These are projection targets, not competitors. T.O.P. treats SSSOM crosswalks as first-class artifacts, versioned alongside each reference graph and traceable across releases. An operator-facing "Participant" will map to FHIR's Patient resource through one adapter, to CDISC's USUBJID through another, and to SNOMED CT concept codes through the SKOS-XL thesaurus. The projections multiply. The core stays small.

The Universal Rule: If an operator doesn't say the word out loud during their workday, it shouldn't be the primary name of an entity in TOP.

Decision Rule: The Human-Down Filter

When "industry-standard X" enters the room, use this sequence to settle the debate. We prioritize the operator's reality over the database's convenience.

1. The Verbal Test: Does an operator say this term out loud during their workday?
   Yes: Shipment, Batch, Trade, Visit.
   No: ASN_204_Message, MRO_Item_v2, ISO_20022_Transaction (these are projection targets).
2. The Boundary Test: Does this entity match a real-world workflow boundary?
   Yes: SafetyInspection, InformedConsent, LoadingManifest. These are moments in a human's day.
   No: EntryProgressLink, ResearchSubjectProgressEntry. These are serialization details.
3. The Origin Test: Am I shaping the Foundation to match a standard, or shaping a Projection to match a standard?
   The Principle: If you are tempted to use a technical code (like a CDISC C-code or an HL7 resource) as a primary entity name, stop. Move that logic to the Projection Adapter.

Universal Application

The operator-vocabulary surface only works when the full ontology pipeline sits underneath it. We do not skip layers. Every concept in T.O.P. eventually carries all six.

Build the Pipeline in Order

Every concept in TOP, Core, workflow, customer, eventually carries all six layers of the ontology pipeline. Each layer is the precondition for the next. Skip one, the next inherits the weakness.

1. Controlled Vocabulary: synonyms, anti-synonyms, definitions, per-property enums. With provenance.
2. Taxonomy: hierarchical organization of the vocabulary.
3. Metadata Schema: SHACL property shapes, NGSI-LD contexts, SSSOM crosswalks.
4. Thesaurus: SKOS-XL labels with provenance, cross-concept relations.
5. Ontology: OWL classes with PROV-O and BFO alignment.
6. Knowledge Graph: instances at scale.

Three CV-layer obligations. Context routing for homonyms (Subject in human research vs animal research). Anti-synonyms for false friends (agent in pharmacology ≠ TOP Agent). SSSOM crosswalks as first-class artifacts, not buried in @context files.

The Win: By keeping the foundation human-readable, we ensure the AI and the Operator are looking at the same truth. Standards change; the way humans work rarely does.

What this rules in

The "First Principles" approach isn't just about what we exclude; it is a commitment to a specific type of architectural health. We prioritize the following:

• Operator vocabulary as the authoritative naming. If the person doing the work calls it a Batch, Trade, or Participant, that is the entity type in the foundation.
• Workflow-bound entity boundaries. We model entities that represent real-world events or "moments in time," ensuring the digital twin mirrors the physical process.
• Aggressive simplification of the foundation. We follow the rule that "Less is the win." A smaller, more general foundation is easier for humans to navigate and easier for AI to ground.
• Standards alignment as a Projection. We treat regulatory standards (CDISC, FHIR, ISO, GS1) as "outputs" or "views" rather than constraints on the data's internal shape.
• Bitemporal, provenance-native by construction. We bake two clocks — valid time (validFrom/validUntil) and transaction time (observedAt) — and origin (W3C PROV) into the property itself, making history a first-class, non-repudiable citizen.
• Specialization as Content, not Shape. We use universal patterns (e.g., Activity + Task) to handle industry-specific data, rather than creating hundreds of custom entity types.

The Goal: To create a foundation that is "human-anchored" enough to be intuitive, yet "standards-ready" enough to be universally interoperable.

Discipline scales through tooling, not credentials

Ontology construction is logical programming. It requires real expertise in description logic, constraint modeling, SHACL, OWL, and the reasoner. We do not pretend otherwise. We also do not pretend the field has succeeded by insisting only credentialed ontologists can touch a model. Thirty years of that posture produced over seventy public HCLS ontologies that almost no one at the point of care knows exist.

Every other knowledge-intensive technical field has scaled the same way: the discipline moves into the tooling. Software engineering scaled through frameworks, linters, type systems, code review, and now AI-assisted development. Data analysis scaled through BI tools and notebooks. UI design scaled through design systems and component libraries. The expert practitioners did not disappear. They became more valuable because they now spend their time on the twenty percent that matters, not the eighty percent that was always boilerplate.

T.O.P.'s position is that ontology follows the same arc. Tooling and pipeline discipline absorb the patterns that produce broken models: validators catch what previously required senior eyeballs, templates enforce the shapes, SHACL rules block illogical relations at contribution time, projection adapters handle the standards alignment. Trained ontologists remain essential. They architect the tools. They lead the domains as BDFLs (a governance term from open source meaning Benevolent Dictators For Life: per-domain architectural leads with final authority on the model, accountable to their contributor communities). They handle the novel modeling work at the joints between standards. Their expertise compounds across many deployments instead of resetting at each one.

Four working roles operate together within this model. The domain expert is the source of authority on meaning. They contribute the vocabulary, the workflow descriptions, the competency questions, and the corrections when the meaning of a concept shifts in their domain. The ontologist designs and maintains the conceptual model: the class hierarchy, properties, alignment with external ontologies, and the versioning strategy. The knowledge engineer turns domain meaning into machine-readable constraints: SHACL shapes, OTTR templates, SPARQL queries, and projection adapters. The data engineer builds and operates the pipelines that move data through the layers. Each role compounds the others. None substitutes for the others. The pipeline only works when all four are present, and the tooling makes contribution possible without requiring any one role to also hold the others.

Contribution is open. Operators contribute vocabulary. Subject matter experts contribute competency questions. Process owners contribute workflow descriptions. All of it enters the pipeline at the controlled vocabulary layer with provenance. The pipeline holds the line on rigor. The BDFL holds the line on architectural coherence. Neither role is a gate against contribution. Both are stewardship of the commons.

This is the answer to the question "if anyone can contribute, how does it not become bloat?" The answer is that contribution flows through a pipeline that enforces discipline by construction, not through a credential check at the door.

The architectural role of OOUX

OOUX is not an ontology methodology. The methodology of T.O.P. is the ontology pipeline above. OOUX output cannot be deployed as ontology without violating description logic and producing the kind of bloat that has discredited the term "ontology" in too many enterprises.

OOUX does have a specific architectural role that becomes more important, not less, as the industry shifts toward agent-composed user interfaces.

In the SaaS world, user interfaces were hand-crafted over years by UX teams, refined against user feedback, and shipped as fixed surfaces operators learned to navigate. In the agent-composed world, interfaces are produced just in time by agents that compose them from object primitives, layout primitives, and action primitives in response to operator context. For that composition to feel native to the operator's work rather than alien, the agent needs an explicit mapping between operator-domain objects and the primitives that render them. That mapping has to be in operator language, organized by mode of consumption, and grounded in workflow rather than in the underlying technical schema.

OOUX is the methodology that captures exactly that mapping. Object maps surface objects, attributes, calls to action, and relationships in operator vocabulary. In T.O.P.'s architecture, OOUX output feeds two consumers, not one. The ontology pipeline formalizes it as candidate vocabulary at the CV layer, with all the downstream rigor that layer requires. The agent-composed UI layer consumes it as the object-primitive substrate that anchors UI composition to the operator's mental model.

This matters for regulated industries specifically. In agent-composed UI, the screen itself becomes part of the audit trail. "Show me what the operator saw when they made this decision" requires the UI representation to be deterministic and traceable, grounded in a defined object-primitive mapping with provenance. Without that substrate, the UI is non-reproducible, which is structurally disqualifying for any regulated workflow.

The position is therefore not "OOUX or ontology" but "OOUX and ontology, serving different consumers from the same operator-anchored object model." The handoff between OOUX and the CV layer is where the discipline gets enforced. Both surfaces are required. Neither substitutes for the other.

The Human Stakes: Complexity as a Tax

In clinical research alone, an operator is expected to navigate a labyrinth of 11+ competing standards (SDTM, CDASH, USDM, FHIR, etc.) alongside evolving regulatory guidelines. No human can hold all of this in working memory.

Today, companies pay a "Complexity Tax" in three ways:

• Headcount: Millions spent on specialized standards-compliance roles.
• Cognitive Load: Operators drown in technical taxonomies instead of focusing on the science or the patient.
• Downstream Pain: When standards are ignored at the front end, it creates massive reconciliation costs at the back end.

TOP's bet: The foundation absorbs the complexity so the human doesn't have to.

By anchoring the foundation on the human workflow, the complexity moves to the projection layer. A coordinator sees a "Participant." Full stop. The translation to SDTM or FHIR happens at the edges, handled by ephemeral adapters that evolve as the standards shift.

Temporal & Provenance: Native, not Sidecars

Most systems treat history as a "log" and ownership as a "flag." In TOP, time and origin are baked into the property itself. We don't "audit" the data; the data is the audit.

1. Bitemporal by construction. TOP carries two independent clocks, not one — valid time (when a fact was true in the world) and transaction time (when the system recorded it) — and both are independently queryable. TOP answers "as we knew it at T₁" and "as it was true at T₂" as separate questions. That is the line between an audit system of record and a value-over-time catalog: single-clock temporal streams and JSON-Schema model catalogs record how values changed, but cannot separate the two clocks or guarantee non-repudiation. Specified in ADR-0021.
2. NGSI-LD Temporal Properties. Every attribute that an operator sees change (Status, Phase, Location) is a temporal stream, not a flat value.
   • validFrom / validUntil: The "Real World" clock. When was this participant actually on treatment?
   • observedAt: The "Sensor/System" clock. When did we record the blood pressure?
   Result: "Trajectory queries" work out of the box. You can ask for the state of any entity at any point in history without searching an external log file.
3. W3C PROV-O as the Skeleton. Every entity and relationship in TOP is a native PROV-O object. We don't "map" to provenance standards; we are built from them.

   Operator Term	Structural PROV Type
   Person / Coordinator / System	prov:Agent
   Visit / Consent / Procedure	prov:Activity
   Document / Sample / Record	prov:Entity

4. Audit is entailed, not optional. A value carrying a cryptographic anchor (integrityHash, signedBy) must be an immutable version, and SHACL enforces it: you cannot sign or hash a value and then mutate it. Corrections are PROV revisions (prov:wasRevisionOf / prov:specializationOf) — append-only, never edited in place.

Structural Integrity: Compliance vendors reconstruct history by stitching together fragmented audit logs. TOP renders history by traversing the graph. One is a best-guess post-mortem; the other is the living truth.

Universal Foundation: Specialization is Content

Traditional ontologies grow linearly with every new industry or modality, creating a unique entity for every variation. TOP carries one universal pattern that absorbs all specialization as content, never as shape.

Standards-up vendors model N entity types per specialty. TOP carries a single pattern that handles them all, staying small enough for an operator to hold in their head.

Every activity, from a DICOM MRI scan to a Currency Trade or a Warehouse Audit, shares the same foundation shape:

• The Activity + Task: The structural container for the work.
• Biomedical / Domain Concept Codes: The "What" (via NCIt, LOINC, ISO, or SNOMED).
• Polymorphic Task Values: The "Result" (Numeric, Text, Coded, or URI references to external files like images or binary logs).
• PROV-O Links: The "Context" (The Equipment used, the Agent associated, the Location).

The Discipline

An entity only earns a place in the TOP Core if it is Universal across domains. If a concept (like a Sample or Document) appears in every industry, it lifts to the Core. If it is specific to one clinical specialty or one type of manufacturing, it is Content.

Promote Facts to Entities: No Bespoke Flags

Every "is_active" or "has_authorized" flag is an evidentiary claim in disguise. A boolean strips away the authority, the time, and the reason. In TOP, we model the fact, not the flag.

A boolean is evidence in disguise. Model the evidence. If you can't say which TOP primitive a property inherits from, you haven't named the thing yet.

The TOP Core categories are designed to absorb these claims natively:

• Claims of Authority: Instead of isSponsor or isOwner, use an Attestation. It carries the Agent who granted it, the jurisdiction, and the expiry.
• State Transitions: Instead of isClosed or isFinalized, use a StatusChange. This captures the "when" and the "activity" that triggered the shift.
• Rule Enforcement: Instead of isRestricted, use a Constraint. This defines the boundary, the severity, and who enforces it.

The Audit-Free Audit

Because these are first-class entities, a query for "Who authorized this trade on Tuesday?" isn't a search through a text log. It is a simple graph traversal to the Attestation that was validFrom that date. The boolean approach makes history opaque; the entity approach makes history a map.

Open Core, Constrained Extension

The Core is open to extension but closed to redefinition. The discipline that prevents FHIR-style drift: per-property flavors, machine-checked at PR time.

• Invariant: semantics fixed; consumers cannot loosen or redefine. (5 properties: identifier, observedAt, integrityHash, startTime, endTime)
• Tightenable: shape stays; consumers may require what Core makes optional, narrow enums, tighten cardinality. (23 properties, including status)
• Additive: surfaces designed for downstream addition (enum values, subclasses).

Consumer extensions live in the consumer's namespace and chain to Core via subClassOf / subPropertyOf / skos:*Match. Full per-layer rules: governance/extension-contract.md.

Why it matters: Extensibility without a discipline produces drift over time: the same logical concept gets modeled multiple ways across consumers, extensions proliferate without discoverability, profiles diverge. The flavor discipline keeps Core extensions safe by construction. T.O.P. is designed to meet peer ontologies (FHIR, USDM, SDTM, MedDRA) at the projection edge via the Broker and equivalent adapters once they ship; the Core stays small and stable so that standards alignment lives where it belongs.

How meaning evolves

Open Core handles structural extension. It does not handle the harder problem: the concepts themselves change. A "Customer" in 2022 was a billing entity. By 2024 the same record was a legal account holder. By 2026 it was an identity cluster spanning subsidiaries. The IRI never moved. The data engineers never got a ticket. The reasoner kept returning answers. The answers were no longer about the same thing.

A reference graph that has no position on concept evolution becomes the last place the pipeline agreed with itself. T.O.P.'s position is that concept evolution is a first-class event in the commons, expressed in the artifacts, not in adjacent meeting notes. Four primitives carry this discipline. None of them is novel. The discipline is in naming them as the answer rather than discovering them at the moment of failure.

• SHACL shapes as contract layer. Already present in the pipeline at layer 3. When a contributing system silently changes the meaning of a field, the shape fails. Validation is loud, machine-readable, and traceable to the specific contributor.
• Named graphs with PROV-O as temporal anchor. Already present in "Temporal and Provenance: Native, not Sidecars." Validity intervals (prov:startedAtTime and prov:endedAtTime) let consumers query what the commons asserted on any specific date, not just what it asserts now.
• Versioned ontologies as drift signal. owl:versionIRI lets consumers pin to a specific version. owl:priorVersion and owl:incompatibleWith express compatibility. owl:deprecated marks terms that should not be used in new work, with rdfs:seeAlso pointing to the replacement. Migration becomes a traceable action rather than a diff.
• SKOS as meaning layer. When the meaning of a category shifts, we do not redefine the category in place. We introduce the new concept and mark the old one with skos:changeNote, and let the change carry forward through the graph. The vocabulary is curated by people who know what the concepts mean, in a form machines can also read.

Together these primitives convert the durability question from "did the pipeline agree with itself" to "which version of meaning did the consumer pin to, and what changed since." That is a different question, and it has answers.

The frame: A reference graph is not a deliverable. It is a commons whose curation is the work. The artifacts are versioned, the changes are signed, and the consumers choose what to depend on.

The Competitive Advantage: Why Human-Centered Wins

The "Always" in our success is structural, not motivational. In any industry, from Pharma to Fintech, three vectors compete for the operator's desktop:

• The Standards-Up Vendors: These are consultancies and SaaS tools built around regulatory schemas (e.g., CDISC, ISO, HL7). They compete on "compliance coverage." They never win operator love because they are tools for the regulator, not tools for the work.
• The Workflow-Up Vendors: These are the legacy silos (EDC, ERP, CRM). They compete on UI but lack ontological grounding. Each is a black box that doesn't federate, creating "Data Islands" that require constant manual bridges.
• The TOP-Shape: A human-anchored foundation + grounded AI + ephemeral projection adapters. By carrying all three sides of the triangle, we eliminate the trade-off between "Ease of Use" and "Compliance".

The Architectural Moat: Compliance is the protection, but the human anchor is the value. We build the absorber so the human doesn't have to be the bridge.

By letting humans work in their own vocabulary while the foundation handles the temporal, provenance, and standards logic, TOP becomes the "Force Multiplier" for regulated industries.