Using Experiment Formalisation

Overview

Formalising an experiment means making its grammar machine-checkable: what was hypothesised, what varied, what it was compared against, what was measured, what was absent, who did what, and what may be concluded — as records a query can interrogate rather than prose a reader must trust.

Two things go wrong, reliably, and this pack exists for both.

The first is unverified vocabulary, and it fails in both directions. Ask for a mapping of a system onto EXPO and you will get a confident table citing Control, Replication, ResultSet, ExperimentRecord, Lineage, DataAnalysis, HypothesisTesting — none of which are EXPO classes. Ask for a correction and you may be told IndependentVariable and ExperimentalProtocol are not either, which is also wrong: both ship. Meanwhile the terms people actually write — Factor, AdminInfoAboutExperiment, QualityControlStrategy — appear in the published paper and never shipped in the ontology, whose real fragments are ExperimentalFactor, AdminInfoExperiment, QualityControl, and (genuinely, in the source) FalsePpositive. A citation to a class that does not exist survives review because nobody checks, and collapses later, taking the correct rows with it.

The second is inverted layering. Formalisation produces something queryable and declarative, and the next suggestion is always that it become authoritative: retire the typed schemas, evaluate the decision gate with SHACL, let the knowledge graph be the single source of truth. This trades fail-closed enforcement for open-world description, in which a missing required property is not an error but an incomplete account.

This pack is governed by two laws that close both, and by a default posture — Tier 1, an annotation layer over records you already emit — that keeps the cost proportionate to the benefit.

The Two Laws

Law 1 — Verified vocabulary only. A term is presented as EXPO, SUMO, or PROV-O vocabulary only if it has been checked in a primary source. Every other term is declared as your own extension. Verified, unverified, and refuted are three different verdicts and must not be collapsed.

Law 2 — The projection law. The ontology describes your typed contracts. It never becomes the runtime source of truth. On disagreement the contract wins and the ontology is corrected — enforced by a CI sync check, not by good intentions.