The Connected Domains Model for the Pharmaceutical and Life Sciences Industry

Abstract

This document proposes an extended Connected Domains model for the pharmaceutical and life sciences industry - 15 semantic domains organized in three composition tiers (Atomic, Compositional, Systemic), with parallel Evidence Outputs and Implementation Surfaces views and a cross-cutting Master and Reference Data foundation. It builds on the Allotrope Foundation's Connected Domains initiative (Q2 2026 Candidate Release) and the ICAD Principles (Colsman, 2026) to define a complete structural vocabulary for scientific data contextualization.

Each domain model is grounded in BFO-aligned ontologies (ISO/IEC 21838-2), adopts ASM's structural building blocks and the cross-domain patterns defined by the Connected Domains Candidate Release (CR 2026/06), and is assessed for current ASM coverage. The Allotrope Connected Domains model (CR 2026/06) spans Tiers 1 through 3 - from Programs and Studies through Experiments to analytical results, specifications, and reporting. This proposal additionally describes Implementation Surfaces (ELN, LIMS, MES, ERP, Operational Technology) and Evidence Outputs (Scientific Interpretations, Scientific Reports, Regulatory Submissions, Decision Records) as parallel views that consume and reference the semantic domain tiers.

This proposal serves as a technical companion to the From FAIR Data to Scientific Decision Intelligence white paper and as a roadmap for schema development within the Allotrope and Pistoia Alliance ecosystems.

Domain Models

ASM's eight structural patterns (aggregate, indexed, value, quantity, class, category, binary, datacube datum) are domain-agnostic building blocks. They compose into document models for specific domains. This section catalogs three composition tiers of semantic domain, from atomic data primitives through systemic aggregation, followed by parallel views for Evidence Outputs and Implementation Surfaces. Each subsection identifies relevant BFO-aligned ontologies (ISO/IEC 21838-2) and assesses current ASM coverage.

BFO foundation: BFO divides reality into continuants (entities persisting through time: objects, qualities, roles) and occurrents (entities unfolding in time: processes, temporal regions). All domains below map onto this framework.

Architecture: The model comprises 24 modeled structures: 15 semantic domains in three composition tiers, four governed Evidence Outputs, and five Implementation Surfaces. A cross-cutting Master and Reference Data foundation supports every model without forming another composition tier. Together, these form 25 architecture elements:

The architecture diagram below shows how the three semantic tiers relate to the parallel structures that carry domain data into governed outputs and enterprise systems. Master and Reference Data provides the shared identity and vocabulary foundation across the complete model.

Allotrope Connected Domains alignment: The Allotrope Foundation's Connected Domains initiative initially proposed seven core domains: Materials, Methods, Instruments, Results, Equipment, Processes, and Specifications (Schafer, 2026). The Q2 2026 Candidate Release (CR 2026/06) expanded scope beyond these seven domains to include Program, Project, Study, Experiment, Submission, and Reporting - spanning Tiers 1 through 3. The Connected Domains model enables cross-domain ASM documents (e.g., a stability study ASM linking material identity → method specification → instrument configuration → analytical results → specification comparison) and is shaped to support key use cases such as reaction analysis and stability study data.

Design consistency principles: All proposed models below adopt ASM's structural building blocks (aggregate, indexed, value, quantity, class, category, binary, datacube datum) and the cross-domain patterns defined by the Connected Domains Candidate Release (CR 2026/06) - including category datum, reference aggregate document, objective specification, and lifecycle management. Coverage of Studies within the Connected Domains CR is limited or emerging, representing relationship-level associations rather than a complete study document model:

Tier 1 - Atomic (identity and data primitives)

1. Materials

Definition: A material entity - characterized by identity, composition, grade, specification, and supplier. Exists independently of any analysis. Persists across the enterprise.

BFO category: material entity (continuant, no role dependency)

BFO-aligned ontologies:

Distinction from Samples: A material is what something is (drug substance, excipient, buffer). A sample (§2) is a specific portion of material in context - it becomes a "sample" only when entering an analytical or investigational workflow. ISA-88 parallel: material = material definition (a type/class), sample = material lot (an instance).

Proposed ASM document model:

material aggregate document (root, aggregate datum)
└── material document[] (indexed datum)
    ├── written name (value datum, REQUIRED)
    ├── material identifier (value datum)
    ├── material grade (value datum)
    ├── material role type (class datum → rdfs:subClassOf BFO:0000023)
    │   enum: buffer solution role, reagent role, solvent role, standard material role, ...
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: draft, approved, effective, obsolete
    ├── composition aggregate document (aggregate datum)
    │   └── component document[] (indexed datum)
    │       ├── written name (value datum, REQUIRED)
    │       ├── component identifier (value datum)
    │       ├── fraction (quantity datum)
    │       └── material role type (class datum → rdfs:subClassOf BFO:0000023)
    ├── objective specification aggregate document (aggregate datum, reusable structure)
    │   └── objective specification document[] (indexed datum)
    │       ├── written name (value datum, REQUIRED)
    │       ├── description (value datum)
    │       ├── reference identifier (value datum)
    │       ├── lower limit (quantity datum)       ← anyOf: lower limit, upper limit,
    │       ├── upper limit (quantity datum)          or specification assessment
    │       └── specification assessment (boolean value datum)
    ├── supplier document (aggregate datum)
    │   ├── supplier (value datum)
    │   ├── supplier lot number (value datum)
    │   ├── catalog number (value datum)
    │   └── certification aggregate document (aggregate datum)
    │       └── certification document[] (indexed datum)
    │           └── certifier (value datum)
    ├── storage conditions document (aggregate datum)
    │   ├── temperature range (quantity datum)
    │   ├── humidity range (quantity datum)
    │   └── light sensitivity (category datum → $asm.value-instance-of)
    │       enum: protect from light, no restriction
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Field naming and structural patterns are aligned with the Digital Analytical Method schema's material document (written name not material name, supplier lot number not lot number, certification aggregate document not certificate of analysis reference).

ASM coverage: Low - ASM models materials indirectly via sampleDocument properties (sample identifier, role type) but has no dedicated material master model. The method schema's material aggregate document → material document[] provides a foundation (written name, batch identifier, catalog number, material grade, material role type, supplier, supplier lot number, certification), which this Proposed extends with composition, storage conditions, and acceptance criteria. Material identity comes from external systems (ERP, LIMS).

2. Samples

Definition: A specific portion of material collected, prepared, or derived for analysis - bearing a specimen role, with identity, provenance, preparation history, and physical/chemical properties.

BFO category: material entity + obi:specimen role (continuant bearing a role)

BFO-aligned ontologies:

Current ASM model: sampleDocument is an aggregate datum at L4 (measurement level) with sample identifier, sample role type (class datum), and custom information. Well-supported within the technique schema model.

sample document (aggregate datum - embedded at measurement level)
├── sample identifier (value datum, REQUIRED)
├── sample role type (class datum → af-rl: role vocabulary)
│   enum: control sample role, standard sample role, validation sample role,
│         experiment sample role, sample role, spiked sample role, blank role,
│         unknown sample role, calibration sample role, unspiked sample role,
│         specimen role, quality control sample role, reference sample role
├── batch identifier (value datum)
├── written name (value datum)
├── location identifier (value datum)
├── description (any datum)
└── custom information aggregate document
    └── custom information document[] (ordered)
        ├── datum label (value datum, REQUIRED - key)
        └── datum value (polymorphic: double/string/timestamp/boolean)

Note: Some technique schemas extend the sample document with additional fields (e.g. well location identifier in plate-reader, vial location identifier in electronic-spectrometry/NMR, sample preparation description in DVS/FTIR). These are technique-specific extensions, not part of the shared hierarchy model.

Extended hierarchy (preparation history and chain-of-custody via ELN or standalone sample management):

sample aggregate document (root, aggregate datum - standalone sample record)
└── sample document[] (indexed datum)
    ├── sample identifier (value datum, REQUIRED)
    ├── batch identifier (value datum)
    ├── written name (value datum)
    ├── sample role type (class datum → af-rl: role vocabulary)
    ├── material reference (value datum → material aggregate document)
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: registered, in preparation, available, consumed, disposed
    ├── collection document (aggregate datum)
    │   ├── collection date (value datum)
    │   ├── collector (value datum)
    │   └── collection method (class datum → af-p: process vocabulary)
    ├── preparation aggregate document (aggregate datum)
    │   └── preparation step document[] (indexed datum, $asm.array-ordered: true)
    │       ├── step description (value datum)
    │       ├── duration (quantity datum)
    │       ├── temperature (quantity datum)
    │       ├── reagent reference (value datum)
    │       └── resulting aliquot identifier (value datum)
    ├── chain of custody aggregate document (aggregate datum)
    │   └── custody event document[] (indexed datum, $asm.array-ordered: true)
    │       ├── event type (category datum → $asm.value-instance-of)
    │       │   enum: received, transferred, stored, disposed
    │       ├── timestamp (value datum)
    │       ├── custodian (value datum)
    │       └── storage location, storage conditions (value datums)
    ├── physical properties document (aggregate datum)
    │   ├── mass, volume, concentration (quantity datums)
    │   └── physical form (category datum → $asm.value-instance-of)
    │       enum: solid, liquid, gas, suspension
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

ASM coverage: Good - sampleDocument and role vocabulary cover analytical workflow sampling. The embedded L4 hierarchy is mature and used across all 50+ technique schemas. Preparation history and chain-of-custody tracking are supported via custom information or ELN patterns; a standalone sample aggregate document would formalize these as first-class structure.

3. Analytical

Definition: The realized data-acquisition event: what actually happened when a sample was measured or observed. It records the selected method version, actual parameters, instrument configuration, timestamps, raw observations, and deviations from the prescribed plan. It covers analytical techniques including spectroscopy, chromatography, mass spectrometry, thermal analysis, and electrochemistry.

BFO category: planned process (occurrent) via OBI

BFO-aligned ontologies:

Distinction from Methods: A Method (§5) is the prescriptive plan for how an analysis should be performed. Analytical is the occurrent execution and its realized settings. Comparing the two makes deviations observable instead of overwriting the plan with actual values.

Current ASM model: All technique schemas follow a standardized hierarchy:

technique aggregate document (L1 - root)
├── data system document (REQUIRED - file provenance, converter info)
├── device system document (instrument metadata)
├── analysis sequence document (method reference)
├── electronic project record (project linkage)
├── electronic signature aggregate document (GxP compliance)
├── processed data aggregate document (file-level processing)
├── statistics aggregate document (cross-measurement statistics)
├── calculated data aggregate document (file-level calculations)
├── custom information aggregate document (file-level extension)
└── technique document[] (L2 - 1..n runs/sequences)
    ├── analyst, submitter
    └── measurement aggregate document (L3)
        ├── measurement document[] (L4 - 1..n, REQUIRED)
        │   ├── measurement identifier (value datum)
        │   ├── measurement time (value datum)
        │   ├── detection type (value datum)
        │   ├── sample document (REQUIRED)
        │   ├── device control aggregate document (REQUIRED)
        │   ├── [technique-specific results: quantity/value/class datums]
        │   ├── [data cube - multidimensional spectral/chromatographic data]
        │   ├── calculated data aggregate document
        │   ├── processed data aggregate document
        │   └── custom information aggregate document
        ├── calculated data aggregate document (cross-measurement)
        ├── processed data aggregate document
        └── statistics aggregate document

This hierarchy is a reusable structural template - every new technique schema instantiates it with domain-specific measurement/result content. 50+ technique schemas follow this pattern across the ADM schema portfolio.

ASM coverage: Strong - this is ASM's core use case and most mature domain.

4. Results

Definition: The output of analytical measurement - structured scientific data produced by instruments, comprising raw signals, processed spectra/chromatograms, calculated values, statistical summaries, and derived conclusions. Results are the primary data products of the Analytical hierarchy (§3) and the inputs consumed by Tests (§9), Studies (§13), and Specifications (§6).

BFO category: generically dependent continuant (IAO data item, measurement datum) - information content entities produced by a measurement process

BFO-aligned ontologies:

Distinction from Analytical: The Analytical hierarchy (§3) describes the process that produces results - the instrument run with its device control, sample context, and measurement sequence. Results is the data produced - the values, spectra, and calculated metrics that exist independently of how they were generated. In the Connected Domains model, Results is a first-class domain because the same result values flow to multiple consumers (specifications, studies, reports, LIMS) without carrying the full measurement context.

Current ASM model - result structures within the technique schema model:

measurement document (L4)
├── [technique-specific raw results]
│   ├── quantity datums (e.g., peak area, peak height, retention time, absorbance)
│   ├── value datums (e.g., peak name, compound identifier)
│   ├── class datums (e.g., peak type: baseline/shoulder/unresolved)
│   └── datacubes (e.g., absorbance spectrum, chromatogram)
├── calculated data aggregate document
│   └── calculated data document[] (ordered)
│       ├── calculated data name (value datum, REQUIRED)
│       ├── calculated result (quantity datum, REQUIRED)
│       ├── calculation description (value datum)
│       └── data source aggregate document (provenance references)
├── processed data aggregate document
│   └── processed data document[] (ordered)
│       ├── processed data identifier (value datum)
│       ├── data processing document (aggregate datum)
│       │   ├── data processing type (value datum - e.g. smoothing, integration)
│       │   ├── data processing time (dateTimeStamp)
│       │   └── method identifier, method name, method version (value datums)
│       ├── data source aggregate document (provenance references)
│       └── description (value datum)
└── statistics aggregate document (at L1 - cross-measurement)
    └── statistics document[] (unordered)
        ├── statistical feature (class datum, REQUIRED)
        │   enum: concentration, mass, purity, pH, temperature, viscosity, ... (200+ measurement properties)
        ├── mean (quantity datum)
        ├── standard deviation (quantity datum)
        ├── relative standard deviation (quantity datum, %)
        ├── count (value datum)
        └── [technique-specific statistical values added via allOf]

This is ASM's most mature domain - result types and their ontology classes (f-r: namespace) form the largest portion of the AFO vocabulary. The three-level structure (raw → calculated → processed, plus statistics) provides a complete data provenance chain.

Connected Domains perspective: In the Connected Domains model, Results becomes a referenceable entity - a result set can be linked from a Specification comparison ("measured purity: 99.2%"), a Method validation study, or an Instrument qualification record without embedding the full technique aggregate document. This requires:

• A result identifier (for cross-document reference)
• A result summary format (key results without full measurement context)
• Provenance metadata (which analytical run produced this result)

ASM coverage: Strong - this is ASM's core output domain. The f-r: vocabulary contains hundreds of result-type classes, and the calculated/processed/statistics structure is well-established across all technique schemas. The Connected Domains extension adds cross-domain referencing, not new result structures.

5. Methods

Definition: A prescriptive specification of how to perform a measurement, assay, or process - including parameters, equipment requirements, acceptance criteria, and procedural steps.

BFO category: generically dependent continuant (IAO plan specification) - a method is an information content entity that prescribes a process

BFO-aligned ontologies:

Two levels of ASM method support:

1. Method references in technique schemas - every technique schema records which method was executed and what instrument parameters were applied during a run. These are descriptive (what happened), not prescriptive (what should happen).
2. Digital Analytical Method schema (CR 2026/06) - a dedicated schema that models full method definitions: the prescriptive specification of how to perform an analysis, including procedures, calculations, acceptance criteria, equipment capabilities, materials, and lifecycle management.

Level 1 - Method references in technique schemas (existing across all 50+ technique schemas):

technique aggregate document (L1)
├── analysis sequence document (aggregate datum)
│   ├── method identifier (value datum - method name/number)
│   ├── method name (value datum)
│   ├── written name (value datum - sequence/worklist name)
│   └── description (value datum)
│
├── technique document (L2)
│   └── measurement aggregate document (L3)
│       └── measurement document (L4)
│           ├── analytical method identifier (value datum - per-measurement override)
│           └── device control aggregate document (REQUIRED)
│               ├── device control document[] (ordered)
│               │   ├── device type (value datum, REQUIRED - detector, pump, column, etc.)
│               │   └── [technique-specific parameters as quantity/value datums]
│               │       ├── e.g. wavelength setting (quantity datum)
│               │       ├── e.g. flow rate (quantity datum)
│               │       ├── e.g. column temperature (quantity datum)
│               │       └── e.g. injection volume (quantity datum)
│               └── firmware version (value datum)
│
└── device system document (aggregate datum)
    ├── device identifier (value datum)
    ├── model number (value datum)
    ├── equipment serial number (value datum)
    ├── asset management identifier (value datum)
    ├── calibration certificate identifier (value datum)
    ├── firmware version (value datum)
    └── device document[] (per-module instrument description)

This captures method identity (analytical method identifier), realized parameters (device control aggregate document), and equipment identity (device system document) - but not the method definition itself.

Level 2 - Digital Analytical Method schema (CR 2026/06):

The Digital Analytical Method is a standalone ASM document type - it does NOT follow the technique schema model template. Instead, it uses IAO-aligned ontology classes (iao:plan specification, iao:action specification, iao:objective specification) as its structural backbone:

plan specification aggregate document (root, aggregate datum)
└── plan specification document[] (indexed datum, ORDERED)
    ├── written name (value datum)
    ├── objective specification aggregate document (reusable structure - see below)
    └── analytical method document (aggregate datum, REQUIRED)
        ├── analytical method identifier (value datum)
        ├── author (value datum)
        ├── primary analyte (value datum)
        ├── business purpose (value datum)
        ├── safety information (value datum)
        ├── training requirements (value datum)
        ├── permitted phase description (value datum)
        ├── qualified location description (value datum)
        │
        ├── analysis type (category datum → tNamed, $asm.value-instance-of)
        │   enum: identity analysis, absolute purity analysis, relative purity analysis,
        │         synthesis impurity analysis, contamination impurity analysis,
        │         residual impurity analysis, degradation impurity analysis,
        │         sterility analysis, biological potency analysis,
        │         physical characterization analysis, pharmaceutical strength analysis
        │
        ├── life cycle status (category datum → tNamed, $asm.value-instance-of)
        │   enum: draft life cycle status, approved life cycle status,
        │         rejected life cycle status, effective life cycle status,
        │         obsolete life cycle status
        │
        ├── procedure specification aggregate document (REQUIRED)
        │   └── procedure specification document[] (indexed datum)
        │       ├── written name, description (value datums)
        │       ├── action specification aggregate document (aggregate datum, REQUIRED)
        │       │   └── action specification document[] (indexed datum)
        │       │       ├── action specification identifier (value datum, REQUIRED)
        │       │       ├── description (value datum, REQUIRED)
        │       │       └── prerequisite identifier (value datum - step dependencies)
        │       └── condition aggregate document
        │           └── condition document[] (indexed datum)
        │               ├── condition feature (value datum, REQUIRED)
        │               ├── description (value datum)
        │               ├── lower limit (quantity datum)
        │               └── upper limit (quantity datum)
        │
        ├── calculation aggregate document
        │   └── calculation document[] (indexed datum)
        │       ├── calculation identifier (value datum, REQUIRED)
        │       ├── calculation name (value datum)
        │       ├── calculation equation (value datum)    ← anyOf equation or reference
        │       ├── calculation reference (value datum)
        │       └── description (value datum)
        │
        ├── capability aggregate document
        │   └── capability document[] (indexed datum)
        │       ├── device type (value datum, REQUIRED)
        │       ├── capability feature (value datum, REQUIRED)
        │       └── equivalence permitted (boolean value datum)
        │
        ├── material aggregate document
        │   └── material document[] (indexed datum)
        │       ├── written name (value datum, REQUIRED)
        │       ├── batch identifier, catalog number (value datums)
        │       ├── material grade (value datum)
        │       ├── material role type (class datum → BFO role)
        │       │   enum: buffer solution role, reagent role, solvent role, standard material role
        │       ├── supplier, supplier lot number (value datums)
        │       └── certification aggregate document
        │           └── certification document[] → certifier (value datum)
        │
        ├── system suitability aggregate document
        │   └── system suitability document[] (indexed datum)
        │       └── objective specification aggregate document (REQUIRED, reusable structure)
        │
        ├── reference aggregate document
        │   └── reference document[] (indexed datum)
        │       ├── reference identifier (value datum, REQUIRED)
        │       ├── written name (value datum)
        │       └── data system identifier (value datum)
        │
        └── version log
            └── version log entry[] (indexed datum, minItems: 0)
                ├── version number (value datum, REQUIRED)
                ├── effective date (datetime, REQUIRED)
                ├── author, change description, change reason, change type (value datums)

Shared definition - objective specification aggregate document:

Used at two levels (plan-level acceptance criteria and system suitability criteria):

objective specification aggregate document (aggregate datum)
└── objective specification document[] (indexed datum)
    ├── written name (value datum, REQUIRED)
    ├── description (value datum)
    ├── reference identifier (value datum)
    ├── lower limit (quantity datum)       ← anyOf: lower limit, upper limit,
    ├── upper limit (quantity datum)          or specification assessment
    └── specification assessment (boolean value datum)

Schema design observations:

What the Digital Analytical Method covers vs. what remains outside scope:

ASM coverage: Strong - the Digital Analytical Method schema (CR 2026/06) is a comprehensive method definition model. It covers the prescriptive dimension (procedures, conditions, acceptance criteria, calculations) that the technique schema model's descriptive method references lack. Together, Level 1 (realized parameters in technique data) and Level 2 (prescriptive method definition) form a complete method lifecycle: define → execute → record.

6. Specifications

Definition: An approved set of test definitions, referenced analytical procedures/methods, and acceptance criteria that together define the required quality attributes for a material, product, or process. Acceptance criteria are components of a specification, not synonyms - a specification is the complete document; acceptance criteria are the individual limit declarations within it. Specifications are the bridge between Results (§4) and the conformance assessment in Tests (§9).

BFO category: generically dependent continuant (IAO objective specification) - an information content entity that specifies requirements

BFO-aligned ontologies:

Distinction from Methods: A method (§5) prescribes how to perform an analysis. A test definition (§9) identifies the material attribute to assess and may reference more than one approved method. Acceptance criteria define acceptable outcomes. A specification brings those test definitions, method references, and acceptance criteria together for a material, product, or process.

Distinction from Tests: A specification is the persistent approved document. A test definition is one component of that specification, such as identity, assay, purity, or water content. A test execution applies one approved method version to a specific sample and produces a result. If acceptance criteria apply, a separate conformance assessment compares that result with the criteria.

Proposed ASM document model:

specification aggregate document (root, aggregate datum)
└── specification document[] (indexed datum)
    ├── specification identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── specification type (category datum → $asm.value-instance-of)
    │   enum: drug substance, drug product, excipient, in-process control, stability
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: draft, approved, rejected, effective, obsolete
    ├── material reference (value datum → material aggregate document)
    ├── test definition aggregate document (aggregate datum)
    │   └── test definition document[] (indexed datum - one per quality attribute)
    │       ├── test definition identifier (value datum, REQUIRED)
    │       ├── written name (value datum, REQUIRED - e.g. "Identity", "Purity")
    │       ├── material applicability (value datum)
    │       ├── method reference document[] (indexed datum - one or more approved methods)
    │       │   ├── reference identifier (value datum, REQUIRED)
    │       │   └── data system identifier (value datum)
    │       └── acceptance criteria aggregate document (aggregate datum)
    │           └── objective specification document[] (indexed datum)
    │               ├── written name (value datum, REQUIRED - e.g. "Assay", "Total Impurities")
    │               ├── description (value datum)
    │               ├── reference identifier (value datum - pharmacopoeia chapter, ICH guideline)
    │               ├── lower limit (quantity datum)       ← anyOf: lower limit, upper limit,
    │               ├── upper limit (quantity datum)          or qualitative criterion
    │               └── qualitative criterion (value datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

ICH Q6A mapping to the acceptance criteria aggregate document within each test definition:

Each required quality attribute maps to a test definition. Its acceptance criteria contain one or more objective specification document entries with a lower limit, upper limit, range, qualitative criterion, or no criterion when the value is report-only. Approved analytical procedures are references on the test definition, allowing alternatives such as orthogonal identity methods without treating a method as the test itself. Specification history uses the version log pattern.

ASM coverage: Specifications are currently implicit in the system. When an ASM analytical result is produced, the specification against which it is judged lives in LIMS or a quality management system, not in the ASM document itself. The method schema's objective specification aggregate document (reusable structure) provides the acceptance criteria primitive that this hierarchy composes into a full specification document. The Connected Domains model makes specifications a first-class ASM document type, enabling specification-aware result comparison within the ASM ecosystem.

7. Instruments

Definition: A physical device or integrated assembly capable of performing measurements, observations, or transformations - characterized by manufacturer, model, serial number, firmware/software version, calibration status, and operational qualification state.

BFO category: material entity (continuant) - specifically obi:device / IOF ManufacturedProduct

BFO-aligned ontologies:

Distinction from Equipment: An instrument is equipment designed primarily to make measurements or observations - it produces scientific data. Other equipment (§8) performs preparation, process control, or environmental functions without measurement as its primary purpose (reactors, autoclaves, centrifuges, incubators, clean benches). Both instruments and equipment have a class/model axis (what a type can do) and a physical-asset-instance axis (a specific serial-numbered unit in a specific lab). The Instruments domain (§7) focuses on measurement-producing assets; the Equipment domain (§8) covers non-measurement assets.

Current ASM model - instrument-related structures distributed across the technique schema model:

technique aggregate document (L1)
├── device system document (aggregate datum)
│   ├── asset management identifier (value datum - enterprise asset tag)
│   ├── device identifier (value datum)
│   ├── model number (value datum)
│   ├── equipment serial number (value datum)
│   ├── firmware version (value datum)
│   ├── description (value datum)
│   └── device document[] (per-module breakdown)
│       ├── device type (value datum - detector, pump, column, etc.)
│       ├── device identifier (value datum)
│       ├── model number (value datum)
│       ├── firmware version (value datum)
│       └── [module-specific properties]

This captures instrument identity and module composition at the time of a measurement run. It does NOT capture:

• Calibration history (series of calibration events over time)
• Qualification status (IQ/OQ/PQ records)
• Maintenance schedule and service history
• Instrument lifecycle (commission → qualify → operate → decommission)
• Site/lab location and movement history

Proposed ASM document model (standalone instrument record):

instrument aggregate document (root, aggregate datum)
└── instrument document[] (indexed datum)
    ├── asset management identifier (value datum)
    ├── device identifier (value datum)
    ├── model number (value datum)
    ├── equipment serial number (value datum)
    ├── manufacturer (value datum)
    ├── firmware version, software version (value datums)
    ├── instrument class (class datum → af-e: equipment vocabulary)
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: commissioned, operational, under maintenance, decommissioned
    ├── location document (aggregate datum)
    │   ├── site, building, lab, bench position (value datums)
    │   └── location change history document[] (indexed datum, $asm.array-ordered: true)
    │       ├── timestamp (value datum)
    │       └── previous location, new location (value datums)
    ├── module aggregate document (aggregate datum)
    │   └── module document[] (indexed datum)
    │       ├── device type (class datum → af-e: equipment vocabulary)
    │       ├── device identifier (value datum)
    │       ├── equipment serial number (value datum)
    │       ├── model number (value datum)
    │       ├── installation date (value datum)
    │       └── expected lifetime (quantity datum)
    ├── calibration aggregate document (aggregate datum)
    │   └── calibration event document[] (indexed datum, $asm.array-ordered: true)
    │       ├── calibration date (value datum)
    │       ├── next due date (value datum)
    │       ├── calibration type (category datum → $asm.value-instance-of)
    │       │   enum: factory, field, verification
    │       ├── objective specification aggregate document (reusable structure - pass criteria)
    │       ├── result (category datum → $asm.value-instance-of)
    │       │   enum: pass, fail, adjusted
    │       └── certificate reference (binary datum)
    ├── qualification aggregate document (aggregate datum)
    │   └── qualification event document[] (indexed datum, $asm.array-ordered: true)
    │       ├── qualification type (category datum → $asm.value-instance-of)
    │       │   enum: installation qualification, operational qualification, performance qualification
    │       ├── date performed (value datum)
    │       ├── performed by (value datum)
    │       ├── objective specification aggregate document (reusable structure - acceptance criteria)
    │       ├── result (category datum → $asm.value-instance-of)
    │       │   enum: pass, fail
    │       └── certificate reference (binary datum)
    ├── maintenance aggregate document (aggregate datum)
    │   └── service event document[] (indexed datum, $asm.array-ordered: true)
    │       ├── event type (category datum → $asm.value-instance-of)
    │       │   enum: preventive, corrective, upgrade
    │       ├── date (value datum)
    │       ├── technician (value datum)
    │       ├── description (value datum)
    │       └── parts replaced (value datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Calibration and qualification events embed the objective specification aggregate document (reusable structure) for their acceptance criteria - the same pattern used in the method schema for system suitability. All closed enumerations (calibration type, qualification type, event type, result, lifecycle status) use category datum with $asm.value-instance-of. Electronic signatures are omitted (cross-cutting concern at manifest/workflow level).

ASM coverage: Partial - device system document and device document[] capture instrument identity and module composition at run-time. A standalone instrument aggregate document would add lifecycle, calibration, qualification, and maintenance tracking as first-class structure.

8. Equipment

Definition: A physical asset or class of assets that performs preparation, process control, environmental conditioning, or containment functions - without measurement as its primary purpose. Examples include reactors, autoclaves, centrifuges, lyophilizers, incubators, laminar-flow hoods, and fume cupboards. Both class-level specifications (what a type can do) and instance-level records (a specific serial-numbered unit) are modeled.

BFO category: A physical equipment instance is a material entity (continuant). Its class, capability, and qualification requirements are generically dependent continuants represented by equipment and capability specifications. The domain links the physical asset to those information entities rather than conflating them.

BFO-aligned ontologies:

Distinction from Instruments: An instrument (§7) is equipment whose primary purpose is measurement or observation. Equipment in this section performs non-measurement functions. Both share a class/instance axis - an "IKA RCT digital" is an equipment class; serial number ABC12345 in Lab 204 is a physical instance. The distinction is functional purpose (measurement vs. preparation/process/control), not class vs. instance.

Proposed ASM document model: The class specification and physical asset are separate linked records:

equipment specification aggregate document (root, aggregate datum - IAO specification)
└── equipment specification document[] (indexed datum)
    ├── equipment class identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── equipment class type (class datum → af-e: equipment hierarchy)
    ├── manufacturer, model family (value datums)
    ├── capability aggregate document (aggregate datum - from method schema)
    │   └── capability document[] (indexed datum)
    │       ├── device type (value datum, REQUIRED)
    │       ├── capability feature (value datum, REQUIRED)
    │       └── equivalence permitted (boolean value datum)
    ├── operating conditions document (aggregate datum)
    │   ├── temperature range (quantity datum)
    │   ├── humidity range (quantity datum)
    │   ├── power requirements (quantity datum)
    │   └── environmental classification (category datum → $asm.value-instance-of)
    │       enum: laboratory, cleanroom, hazardous area
    ├── qualification requirements document (aggregate datum)
    │   └── objective specification aggregate document (aggregate datum, reusable structure)
    │       └── objective specification document[] (indexed datum)
    │           ├── written name (value datum, REQUIRED - e.g. "IQ checklist", "OQ accuracy")
    │           ├── description (value datum)
    │           ├── reference identifier (value datum)
    │           ├── lower limit (quantity datum)       ← anyOf
    │           ├── upper limit (quantity datum)
    │           └── specification assessment (boolean value datum)
    ├── module compatibility document (aggregate datum)
    │   └── compatible module document[] (indexed datum)
    │       ├── module class (class datum → af-e: equipment vocabulary)
    │       └── interface type (category datum → $asm.value-instance-of)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

equipment asset aggregate document (root, aggregate datum - physical instances)
└── equipment asset document[] (indexed datum)
    ├── asset management identifier (value datum, REQUIRED)
    ├── equipment specification reference (value datum, REQUIRED)
    ├── equipment serial number (value datum, REQUIRED)
    ├── manufacturer and model number (value datums)
    ├── location document (aggregate datum - site, building, room)
    ├── life cycle status (category datum → $asm.value-instance-of)
    ├── qualification event document[] (indexed datum, $asm.array-ordered: true)
    ├── maintenance event document[] (indexed datum, $asm.array-ordered: true)
    └── reference aggregate document (aggregate datum)

The capability aggregate document uses the method schema's capability document pattern (device type + capability feature + equivalence permitted). Qualification requirements use the objective specification aggregate document (reusable structure) for acceptance criteria. Regulatory classification uses reference aggregate document entries.

ASM coverage: Low - AFO equipment vocabulary (af-e:) provides the class hierarchy (detector types, instrument types), and the method schema's capability document provides the equipment capability primitive. There is no dedicated equipment specification or physical-asset schema. The two linked records above are proposed to preserve class-level capabilities independently from serial-numbered asset lifecycle, qualification, location, and maintenance data.

Tier 2 - Compositional (orchestrate atomic elements)

9. Tests

Definition: The Test domain distinguishes two layers: a test definition (the quality attribute to assess, material applicability, approved method options, and acceptance criteria) and a test execution (the event of applying a selected method version to a specific sample, producing an actual result). A separate conformance assessment compares the result against criteria and yields a verdict - which may be pass, fail, indeterminate, or investigation-required. Tests are not inherently binary; OOS/OOT investigations, retest provisions, and tiered acceptance all produce non-binary outcomes.

BFO category: The test definition is a generically dependent continuant (IAO plan or objective specification). The test execution is a planned process (occurrent; OBI assay). Its result and any conformance assessment are information content entities. Keeping these categories separate distinguishes what was required, what was performed, what was observed, and how the result was assessed.

BFO-aligned ontologies:

Distinction from Experiments: A test characterizes a defined attribute of a material or sample using an approved or selected method. It produces a result; when acceptance criteria apply, a conformance assessment may also produce a verdict. An experiment (§10) is a broader planned investigation that can combine procedures, interventions, preparations, controls, observations, and multiple analytical determinations to answer a scientific question.

Proposed ASM document model:

test aggregate document (root, aggregate datum)
├── test definition document (aggregate datum - reusable requirement)
│   ├── test definition identifier (value datum, REQUIRED)
│   ├── written name (value datum, REQUIRED - e.g. "Identity", "Purity")
│   ├── target attribute (class datum, REQUIRED)
│   ├── material applicability (value datum)
│   ├── approved method reference document[] (indexed datum, minItems: 1)
│   │   ├── reference identifier (value datum, REQUIRED)
│   │   └── data system identifier (value datum)
│   └── acceptance criteria aggregate document (aggregate datum, optional)
│       └── objective specification document[] (indexed datum)
│           ├── written name (value datum, REQUIRED)
│           ├── lower limit (quantity datum)
│           ├── upper limit (quantity datum)
│           └── qualitative criterion (value datum)
└── test execution document[] (indexed datum - one per sample determination)
    ├── test execution identifier (value datum, REQUIRED)
    ├── test definition reference (value datum, REQUIRED)
    ├── selected method version reference (value datum, REQUIRED)
    ├── sample document (aggregate datum)
    │   ├── sample identifier (value datum, REQUIRED)
    │   ├── batch identifier (value datum)
    │   └── sample role type (class datum → af-rl: role vocabulary)
    ├── analytical run document[] (indexed datum - realized technique documents)
    ├── result document[] (indexed datum - measured or observed outcomes)
    │   ├── written name (value datum, REQUIRED - parameter name)
    │   └── measured or observed value (value or quantity datum)
    ├── conformance assessment document (aggregate datum, optional)
    │   ├── acceptance criteria reference (value datum, REQUIRED)
    │   ├── assessment status (category datum → $asm.value-instance-of)
    │   │   enum: pass, fail, indeterminate, investigation-required
    │   ├── rationale (value datum)
    │   └── deviation or investigation reference (value datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

The reusable test definition records the target attribute independently of any one method. Each execution references the method version actually selected and the realized analytical run. The conformance assessment is optional because characterization tests can produce valid results without a release verdict. Assessment status uses category datum with $asm.value-instance-of. Electronic signatures are omitted as a cross-cutting concern.

ASM coverage: Limited - ASM models realized analytical runs and reusable acceptance-criteria structures, but not the complete test-definition/test-execution orchestration or the conformance-assessment lifecycle.

10. Experiments

Definition: A planned investigation combining procedures, interventions, preparations, controls, observations, analytical determinations, and interpretation - designed to answer a scientific question. Experiments are broader than tests: they may include non-analytical activities (sample preparation, environmental conditioning, biological incubation), controlled variables and factors, and multiple analytical techniques. The outcome is an interpretation or conclusion, not a conformance verdict.

BFO category: planned process (occurrent) - obi:investigation

BFO-aligned ontologies:

Proposed ASM document model:

experiment aggregate document (root, aggregate datum)
└── experiment document[] (indexed datum)
    ├── experiment identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── description (value datum)
    ├── assay list (aggregate datum - technique ASM references)
    │   └── [has member → Analytical technique ASMs]
    ├── objective (value datum)
    ├── hypothesis (value datum)
    ├── experimental design document (aggregate datum)
    │   ├── factor document[] (indexed datum)
    │   │   ├── factor name (value datum)
    │   │   └── level document[] (indexed datum)
    │   │       └── level value (value datum)
    │   ├── control document[] (indexed datum)
    │   │   ├── control type (category datum → $asm.value-instance-of)
    │   │   │   enum: positive, negative, blank
    │   │   └── description (value datum)
    │   └── statistical design type (category datum → $asm.value-instance-of)
    │       enum: factorial, crossover, parallel, randomized
    ├── condition aggregate document (aggregate datum - from method schema)
    │   └── condition document[] (indexed datum)
    │       ├── condition feature (value datum, REQUIRED)
    │       ├── description (value datum)
    │       ├── lower limit (quantity datum)
    │       └── upper limit (quantity datum)
    ├── preparation aggregate document (aggregate datum)
    │   └── preparation step document[] (indexed datum, $asm.array-ordered: true)
    │       ├── description (value datum)
    │       ├── duration (quantity datum)
    │       └── material aggregate document (aggregate datum)
    │           └── material document[] (indexed datum)
    │               ├── written name (value datum, REQUIRED)
    │               └── material role type (class datum → rdfs:subClassOf BFO:0000023)
    ├── analytical run document[] (indexed datum - technique aggregate documents)
    ├── observations document (aggregate datum - custom information aggregate document)
    ├── conclusion document (aggregate datum)
    │   ├── interpretation (value datum)
    │   └── next steps (value datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Controlled variables use the method schema's condition document pattern (condition feature + lower/upper limit). Material/reagent references use the method schema's material document pattern (written name, material role type). Closed enumerations (control type, statistical design type) use category datum. Electronic signatures are omitted (cross-cutting concern).

ASM coverage: The Connected Domains CR (2026/06) defines Experiment as the hub entity connecting to Analytical, Specification, Submission, and Reporting via aggregate document relationships:

experiment aggregate document
├── plan specification aggregate document → has member → Specification ASM
├── measurement aggregate document → has member → Analytical (technique ASMs)
├── submission aggregate document → has member → Submission ASM
│   └── submission document[] (indexed datum)
│       ├── submitter (value datum)
│       ├── submission identifier (value datum)
│       ├── material identifier (value datum)
│       ├── description (value datum)
│       └── designated recipient (value datum)
└── reporting aggregate document → has member → Reporting ASM
    └── reporting document[] (indexed datum)
        ├── author (value datum)
        ├── report identifier (value datum)
        ├── conformance value (value datum)
        ├── completion status (value datum)
        └── designated recipient (value datum)

Submission and Reporting are Experiment-level entities - distinct from the enterprise-level Regulatory Submissions (§18) which aggregate across programs.

11. Procedures (ISA-88)

Definition: A prescriptive sequence of steps for controlling a process - aligned with the ISA-88 (S88) procedural model for batch process control.

BFO category: planned process (occurrent) - IOF PlannedProcess

BFO-aligned ontologies:

ISA-88 procedural hierarchy:

Procedure
└── Unit Procedure[] (ordered - scoped to a single unit of equipment)
    └── Operation[] (ordered - independent processing activity)
        └── Phase[] (ordered - smallest controllable element)

Mapping to ASM patterns:

Proposed ASM document model:

procedure specification aggregate document (root, aggregate datum - IAO plan specification)
└── procedure specification document[] (indexed datum)
    ├── procedure identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: draft, approved, rejected, effective, obsolete
    ├── capability aggregate document (aggregate datum - from method schema)
    │   └── capability document[] (indexed datum)
    │       ├── device type (value datum, REQUIRED)
    │       ├── capability feature (value datum, REQUIRED)
    │       └── equivalence permitted (boolean value datum)
    ├── formula document (aggregate datum)
    │   ├── process input document[] (indexed datum)
    │   │   ├── written name (value datum, REQUIRED)
    │   │   ├── material role type (class datum → rdfs:subClassOf BFO:0000023)
    │   │   └── quantity (quantity datum)
    │   ├── process parameter document[] (indexed datum)
    │   │   ├── written name (value datum, REQUIRED)
    │   │   ├── setpoint (quantity datum)
    │   │   ├── lower limit (quantity datum)
    │   │   └── upper limit (quantity datum)
    │   └── process output document[] (indexed datum)
    │       ├── written name (value datum, REQUIRED)
    │       └── expected yield (quantity datum)
    ├── procedure specification aggregate document (aggregate datum - S88 procedural hierarchy)
    │   └── procedure specification document[] (indexed datum, $asm.array-ordered: true)
    │       ├── written name (value datum, REQUIRED - unit procedure name)
    │       ├── action specification aggregate document (aggregate datum, REQUIRED)
    │       │   └── action specification document[] (indexed datum)
    │       │       ├── action specification identifier (value datum, REQUIRED)
    │       │       ├── description (value datum, REQUIRED)
    │       │       └── prerequisite identifier (value datum - step dependencies)
    │       └── condition aggregate document (aggregate datum)
    │           └── condition document[] (indexed datum)
    │               ├── condition feature (value datum, REQUIRED)
    │               ├── description (value datum)
    │               ├── lower limit (quantity datum)
    │               └── upper limit (quantity datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

The S88 procedural hierarchy maps directly onto the method schema's procedure specification aggregate document → action specification document pattern, with prerequisite identifier enabling DAG-structured step dependencies instead of pure sequential ordering. Equipment requirements use capability document from the method schema. Process parameter limits use the same lower/upper limit pattern as condition document. The root name follows IAO alignment (plan specification).

ASM coverage: None - ASM models measurement data, not process control. However, the method schema's procedure specification aggregate document and action specification document patterns provide a structural bridge between ASM's document model and ISA-88's procedural hierarchy.

12. Recipes (ISA-88)

Definition: A combination of procedure, formula, materials, and equipment/capability requirements that defines how to produce a specific product - aligned with the ISA-88 recipe model. ISA-88 defines four recipe levels that bind progressively to physical resources: general (site-independent, product-focused, maximum portability), site (adapted to site capabilities, includes materials availability), master (bound to a specific process cell, includes equipment and batch resources), and control (execution instance for a single batch, fully parameterized). Each level adds bindings: general specifies materials and capabilities abstractly; master binds to specific equipment entities; control adds batch-specific resource allocations.

BFO category: generically dependent continuant (IAO plan specification) + planned process (procedure)

BFO-aligned ontologies:

ISA-88 recipe types:

Recipe contents (S88): header + formula + equipment requirements + procedure + other information.

Proposed ASM document model:

recipe specification aggregate document (root, aggregate datum - IAO plan specification)
└── recipe specification document[] (indexed datum)
    ├── recipe identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── recipe type (category datum → $asm.value-instance-of)
    │   enum: general, site, master, control
    ├── product identifier (value datum)
    ├── product name (value datum)
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: draft, approved, rejected, effective, obsolete
    ├── formula document (aggregate datum)
    │   ├── formula input document[] (indexed datum)
    │   │   ├── written name (value datum, REQUIRED)
    │   │   ├── material role type (class datum → rdfs:subClassOf BFO:0000023)
    │   │   └── quantity (quantity datum)
    │   ├── formula output document[] (indexed datum)
    │   │   ├── written name (value datum, REQUIRED)
    │   │   ├── expected yield (quantity datum)
    │   │   └── objective specification aggregate document (reusable structure - quality criteria)
    │   └── process parameter document[] (indexed datum)
    │       ├── written name (value datum, REQUIRED)
    │       ├── target value (quantity datum)
    │       ├── lower limit (quantity datum)
    │       ├── upper limit (quantity datum)
    │       └── criticality (category datum → $asm.value-instance-of)
    │           enum: critical process parameter, non-critical
    ├── capability aggregate document (aggregate datum - from method schema)
    │   └── capability document[] (indexed datum)
    │       ├── device type (value datum, REQUIRED)
    │       ├── capability feature (value datum, REQUIRED)
    │       └── equivalence permitted (boolean value datum)
    ├── procedure specification aggregate document (aggregate datum)
    │   └── [S88 procedural hierarchy as §11]
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Recipe type and criticality use category datum (closed enumerations). Formula output quality criteria use the objective specification aggregate document (reusable structure). Equipment requirements use capability document from the method schema. Material inputs use material role type from the method schema. Header fields are root-level properties. Electronic signatures are omitted (cross-cutting concern). Lifecycle uses the standard life cycle status + version log pattern.

ASM coverage: None - recipes combine process control, material management, and quality specifications in a single document. Outside ASM's current scope. However, the method schema provides most of the building blocks: procedure specification aggregate document for procedural hierarchy, capability document for equipment, material document for inputs, and objective specification aggregate document for quality criteria.

Tier 3 - Systemic (aggregate compositional elements)

13. Studies

Definition: A coordinated collection of experiments and/or tests designed to answer a research question - with a study design, defined endpoints, statistical analysis plan, and results aggregation.

BFO category: planned process (occurrent) - obi:investigation

BFO-aligned ontologies:

Proposed ASM document model:

study aggregate document (root, aggregate datum)
└── study document[] (indexed datum)
    ├── study identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── intended purpose (value datum)
    ├── description (value datum)
    ├── owner (value datum)
    ├── approver (value datum)
    ├── requestor (value datum)
    ├── protocol identifier (value datum)
    ├── study type (category datum → $asm.value-instance-of)
    │   enum: stability, bioequivalence, method validation, forced degradation
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: draft, approved, rejected, effective, obsolete
    ├── study design document (aggregate datum)
    │   ├── objective (value datum)
    │   ├── endpoints (value datum)
    │   ├── study design type (category datum → $asm.value-instance-of)
    │   │   enum: longitudinal, crossover, factorial, parallel
    │   ├── duration (quantity datum)
    │   └── timepoints (quantity datum)
    ├── study protocol document (aggregate datum)
    │   ├── reference aggregate document (aggregate datum - method references)
    │   │   └── reference document[] (indexed datum)
    │   │       ├── reference identifier (value datum, REQUIRED)
    │   │       ├── written name (value datum)
    │   │       └── data system identifier (value datum)
    │   └── objective specification aggregate document (reusable structure - acceptance criteria)
    │       └── objective specification document[] (indexed datum)
    │           ├── written name (value datum, REQUIRED)
    │           ├── description (value datum)
    │           ├── reference identifier (value datum)
    │           ├── lower limit (quantity datum)       ← anyOf
    │           ├── upper limit (quantity datum)
    │           └── specification assessment (boolean value datum)
    ├── test document[] and/or experiment document[] (indexed datum)
    │   └── [as §9 / §10]
    ├── results summary document (aggregate datum)
    │   └── statistics aggregate document (aggregate datum)
    │       └── statistic document[] (indexed datum)
    │           ├── statistic type (class datum - reuses technique schema vocabulary)
    │           ├── value (quantity datum)
    │           └── n (value datum - sample count)
    ├── conclusion document (aggregate datum)
    │   ├── study outcome (category datum → $asm.value-instance-of)
    │   │   enum: successful, inconclusive, failed
    │   └── interpretation (value datum)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Study type, design type, and outcome use category datum (closed enumerations). Acceptance criteria use the objective specification aggregate document (reusable structure). Method references and protocol references use reference aggregate document. Electronic signatures are omitted (cross-cutting concern). Statistic type remains class datum (open taxonomy - reuses the technique schema's statistics vocabulary).

ASM coverage: Limited or emerging. The Connected Domains Candidate Release provides Study as a higher-order entity and relationship-level associations, while ASM technique schemas model the individual runs. It does not yet provide the complete study document model proposed here for design, endpoints, timepoints, aggregation, and conclusions.

14. Projects

Definition: An organizational unit grouping related studies under a common modality or therapeutic objective - typically a drug development project or a technology platform evaluation spanning multiple studies.

BFO category: planned process (occurrent) - iao:project

BFO-aligned ontologies:

Proposed ASM document model:

project aggregate document (root, aggregate datum)
└── project document[] (indexed datum)
    ├── project identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── project modality (value datum)
    ├── description (value datum)
    ├── study aggregate document (aggregate datum)
    │   └── study document[] (indexed datum)
    │       └── [as §13]
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

A project groups studies by modality or therapeutic area. Programs (§15) aggregate projects. The Connected Domains CR defines the hierarchy: Program → Project → Study → Experiment.

ASM coverage: The Connected Domains CR (2026/06) introduces Project as a first-class entity linking Programs to Studies.

15. Programs

Definition: The highest-level organizational container in the systemic tier. A Program may contain Projects and direct Studies; Projects in turn contain Studies; Studies contain Experiments. Programs span objectives including discovery and its Research Operating Plan (ROP), preclinical development, clinical development, CMC and process development, lifecycle management, and quality improvement. For example, a discovery program may seek an oral agonist for a biological target to treat a disease, while several projects pursue different compounds or approaches. Regulatory context and clinical phase are optional - not all programs are submission-oriented.

BFO category: generically dependent continuant (IAO objective specification) - a program is a collection of studies with a common goal

BFO-aligned ontologies:

Proposed ASM document model:

program aggregate document (root, aggregate datum)
└── program document[] (indexed datum)
    ├── program identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── sponsor (value datum)
    ├── objective (value datum, REQUIRED)
    ├── program type (class datum - discovery, preclinical, clinical, CMC, lifecycle, quality)
    ├── life cycle status (category datum → $asm.value-instance-of)
    │   enum: planning, active, completed, terminated
    ├── regulatory context document (aggregate datum, optional)
    │   ├── jurisdiction (category datum → $asm.value-instance-of)
    │   │   enum: FDA, EMA, PMDA
    │   ├── submission type (category datum → $asm.value-instance-of)
    │   │   enum: IND, NDA, BLA, MAA
    │   └── regulatory pathway (value datum)
    ├── phase document (aggregate datum, optional)
    │   ├── current phase (category datum → $asm.value-instance-of)
    │   │   enum: Phase I, Phase II, Phase III, Phase IV
    │   └── milestones aggregate document (aggregate datum)
    │       └── milestone document[] (indexed datum, $asm.array-ordered: true)
    │           ├── written name (value datum, REQUIRED)
    │           ├── target date (value datum)
    │           └── actual date (value datum)
    ├── project reference document[] (indexed datum)
    │   └── [→ project aggregate document, §14]
    ├── direct study reference document[] (indexed datum)
    │   └── [→ study aggregate document, §13]
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

All regulatory enumerations (jurisdiction, submission type, phase) use category datum with $asm.value-instance-of (closed, finite sets). Milestones use $asm.array-ordered: true for temporal sequence.

ASM coverage: None - programs are meta-level containers above ASM's data scope. Program management data (timelines, milestones, budgets, regulatory interactions) belongs in enterprise systems, not analytical data models.

Evidence Outputs (parallel view - references domain data)

Evidence Outputs are not semantic domains in the composition hierarchy - they are structured artifacts that reference and assemble data from the three tiers. They are described here because their distinct purposes, structures, provenance requirements, and lifecycles determine how scientific evidence is interpreted, communicated, submitted, and used in decisions.

16. Scientific Interpretations

Definition: An independently addressable scientific claim or conclusion derived from one or more evidence inputs. A Scientific Interpretation records what the evidence means within a defined scope; it does not imply that a decision or action has been taken. Examples include a stability trend interpretation, a structure confirmation, a process-deviation assessment, or a model-supported hypothesis.

BFO category: generically dependent continuant (IAO data item) - an information content entity that is about evidence and expresses a scientific claim

Proposed structure:

scientific interpretation aggregate document (root, aggregate datum)
└── scientific interpretation document[] (indexed datum)
    ├── interpretation identifier (value datum, REQUIRED)
    ├── interpretation type (class datum - trend, comparison, classification, hypothesis, conclusion)
    ├── subject and scope (value datums, REQUIRED)
    ├── claim or conclusion (value datum, REQUIRED)
    ├── evidence input aggregate document (aggregate datum)
    │   └── evidence input document[] (indexed datum, minItems: 1)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── evidence type (class datum - result, test, experiment, study, report)
    │       └── data system identifier (value datum)
    ├── analysis method or model reference (value datum)
    ├── assumptions and alternatives (value datums)
    ├── uncertainty or confidence (value datum)
    ├── author or generating agent (value datum, REQUIRED)
    ├── review status (category datum - draft, reviewed, accepted, superseded)
    ├── timestamp (value datum, REQUIRED)
    ├── provenance aggregate document (aggregate datum - sources, transformations, generating activity)
    └── supersession reference (value datum, optional)

Distinction from Results and Decisions: Results (§4) contain observations, processed values, calculations, and statistics. A Scientific Interpretation states what selected evidence means. A Decision Record (§19) records a committed choice or action that may rely on one or more interpretations. "Insight" is treated as a presentation label for an interpretation, not as a separate schema type.

ASM coverage: Partial - ASM can carry calculated data, custom information, references, authorship, and provenance, but no dedicated interpretation document currently binds a claim to its evidence, assumptions, uncertainty, review state, and supersession history.

17. Scientific Reports

Definition: A governed communication artifact that organizes scientific evidence and interpretations for a defined audience and purpose. Report subtypes include analytical reports, study reports, method-validation reports, investigation reports, Certificates of Analysis, and technical reports.

BFO category: generically dependent continuant (IAO report) - a document with controlled authorship, review, approval, issuance, and amendment

Proposed structure:

scientific report aggregate document (root, aggregate datum)
└── scientific report document[] (indexed datum)
    ├── report identifier (value datum, REQUIRED)
    ├── report type (class datum, REQUIRED)
    ├── title, purpose, audience, and scope (value datums)
    ├── section aggregate document (aggregate datum)
    │   └── report section document[] (indexed datum, $asm.array-ordered: true)
    │       ├── section identifier and title (value datums, REQUIRED)
    │       ├── narrative content reference (value datum, optional)
    │       ├── table or figure reference document[] (indexed datum)
    │       ├── evidence reference document[] (indexed datum)
    │       └── interpretation reference document[] (indexed datum)
    ├── author, reviewer, and approver (value datums)
    ├── life cycle status (category datum - draft, in review, approved, issued, amended, withdrawn, superseded)
    ├── issued date and effective date (value datums)
    ├── amendment reason and supersession reference (value datums, optional)
    └── version log (aggregate datum)

Distinction from Regulatory Submissions: A Scientific Report communicates a bounded body of evidence for a scientific, quality, or operational purpose. A Regulatory Submission (§18) is an authority-specific dossier that assembles reports, interpretations, results, studies, and other evidence within a prescribed submission structure and lifecycle.

ASM coverage: Partial - reporting appears in Connected Domains and existing ASM structures can represent sections, tables, figures, references, and lifecycle metadata. A dedicated report model is proposed to make report purpose, subtype, evidence lineage, review, issuance, and amendment consistent across domains.

18. Regulatory Submissions

Definition: A formal dossier submitted to a regulatory authority (FDA, EMA, PMDA) - structured according to ICH CTD (Common Technical Document) format, containing quality, nonclinical, and clinical data with supporting evidence.

BFO category: generically dependent continuant (IAO document) - an information content entity

BFO-aligned ontologies:

ASM scope: Regulatory submissions aggregate data from programs, studies, and experiments. The eCTD Module 3 section and subsection hierarchy should provide the dossier backbone. Each section can then reference Specifications, Methods, Studies, Tests, Results, and other atomic ASMs rather than duplicating their content. Narrative remains document content, while structured tables, evidence references, and section-level provenance expand the portion that can be represented consistently.

Proposed ASM document model (Module 3 / CMC data only):

submission quality data aggregate document (root, aggregate datum - Module 3 slice)
└── submission quality data document[] (indexed datum)
    ├── submission identifier (value datum)
    ├── written name (value datum, REQUIRED)
    ├── eCTD Module 3 section aggregate document (aggregate datum)
    │   └── eCTD section document[] (indexed datum, $asm.array-ordered: true)
    │       ├── section identifier (value datum, REQUIRED - e.g. "3.2.S.4")
    │       ├── section title (value datum, REQUIRED)
    │       ├── parent section identifier (value datum)
    │       ├── narrative content reference (value datum, optional)
    │       ├── structured table aggregate document (aggregate datum, optional)
    │       │   └── table document[] (indexed datum - section tables and listings)
    │       ├── evidence reference aggregate document (aggregate datum)
    │       │   └── reference document[] (indexed datum)
    │       │       ├── reference identifier (value datum, REQUIRED)
    │       │       ├── referenced domain type (class datum - specification, method, study, test, result)
    │       │       └── data system identifier (value datum)
    │       └── section provenance document (aggregate datum)
    │           ├── source system identifier (value datum)
    │           ├── author or responsible role (value datum)
    │           ├── effective date (datetime)
    │           └── version identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

The ordered section hierarchy mirrors eCTD Module 3. Evidence references plug reusable domain ASMs into the appropriate sections; structured tables and section provenance remain explicit instead of being flattened into narrative. This separates dossier organization from the scientific records it cites.

ASM coverage: Analytical evidence structures are covered, while the eCTD dossier hierarchy, narrative, section tables, and cross-section provenance are proposed extensions.

19. Decision Records

Definition: A structured record of a decision made during the scientific or operational lifecycle - capturing the question posed, evidence inputs considered, rule or rationale applied, actor (human or model), timestamp, outcome, confidence or status, and full lineage back to source data. Decision Records make ICAD's D2 sub-principle (decision traceability) concrete and auditable.

BFO category: generically dependent continuant (IAO data item) - an information content entity recording the provenance of a conclusion

Proposed structure:

decision record aggregate document (root, aggregate datum)
└── decision record document[] (indexed datum)
    ├── decision identifier (value datum, REQUIRED)
    ├── question (value datum, REQUIRED - what was being decided)
    ├── decision type (category datum → $asm.value-instance-of)
    │   enum: release, rejection, escalation, investigation, design-change, approval
    ├── evidence input aggregate document (aggregate datum)
    │   └── evidence input document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED - links to result/test/study)
    │       ├── evidence type (category datum → $asm.value-instance-of)
    │       │   enum: analytical-result, conformance-assessment, trend-analysis, model-prediction
    │       └── data system identifier (value datum)
    ├── rule or rationale (value datum - specification, SOP, or reasoning applied)
    ├── actor (value datum - person, role, or AI model identifier)
    ├── actor type (category datum → $asm.value-instance-of)
    │   enum: human, supervised-model, autonomous-model
    ├── timestamp (value datum, REQUIRED)
    ├── outcome (value datum, REQUIRED - the decision taken)
    ├── confidence (value datum - e.g. high/medium/low or numeric score)
    ├── status (category datum → $asm.value-instance-of)
    │   enum: proposed, approved, superseded, withdrawn
    ├── lineage aggregate document (aggregate datum)
    │   └── lineage step document[] (indexed datum, $asm.array-ordered: true)
    │       ├── step type (category datum)
    │       ├── reference identifier (value datum)
    │       └── timestamp (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

ASM coverage: None - Decision Records are proposed. They complement the existing ICAD D1–D4 sub-principles by providing the structural vocabulary for recording that a decision was made, on what evidence, by what logic, and with what outcome.

Implementation Surfaces (system-level consumers of all tiers)

Implementation Surfaces are not semantic domains in the composition hierarchy - they are the enterprise information systems that consume, orchestrate, and present data from all three tiers. They are described here because their data models constrain how domain data is surfaced and because integration factories must map between ASM domain structures and system-specific representations.

20. ELN (Electronic Laboratory Notebook)

Definition: A system for recording what the scientist did, thought, observed, and decided - combining free-text narrative with structured sections, typed fields, tabular data, properties, file attachments, and explicit decisions/reasoning. Legally functions as an inventor's notebook with IP evidence and witness/countersign capability. ELN entries may reference experiments, tests, methods, and materials from the semantic tiers, but the ELN itself is an implementation surface, not a semantic domain.

BFO category: generically dependent continuant (IAO document, narrative) - an information content entity with temporal ordering

BFO-aligned ontologies:

Distinction from LIMS: ELN supports scientist-authored planning and contemporaneous documentation of experimental work, observations, rationale, and interpretation. LIMS (§21) controls sample-centric laboratory execution from registration and custody through test assignment, result review, approval, and disposition. Product capabilities may overlap; the authoritative record owner for each workflow must be defined per implementation.

Current ASM model: ASM provides a dedicated ELN model in the schema portfolio (REC/2026/06). Unlike analytical technique schemas which use the measurement document / processed data document / custom information aggregate document hierarchy, the ELN model introduces its own domain-specific containers - sections, fields, and tables - that function as a recursive page description language.

electronic lab notebook entry aggregate document (root, aggregate datum)
├── electronic lab notebook entry document[] (indexed datum, $asm.array-ordered: true)
│   ├── electronic lab notebook entry identifier (value datum)
│   ├── electronic lab notebook entry name (value datum)
│   ├── electronic lab notebook entry type (value datum)
│   ├── electronic lab notebook entry state type (value datum)
│   ├── author (value datum)
│   ├── editor (value datum)
│   ├── owner (value datum)
│   ├── creation time (dateTimeStamp)
│   ├── last modified time (dateTimeStamp)
│   ├── parent identifier (value datum - hierarchy/folder linkage)
│   ├── parent name (value datum)
│   ├── section aggregate document (→ section.schema, recursive page content)
│   ├── material transformation aggregate document (chemistry/synthesis steps)
│   └── molecular structure aggregate document (SMILES, structure files)
└── audit trail aggregate document (aggregate datum - versioned change history)
    └── audit trail document[] (indexed datum)
        ├── version number (value datum, REQUIRED)
        ├── action time (dateTimeStamp)
        ├── action type (value datum - e.g. create, edit, sign)
        ├── agent (value datum - who performed the action)
        ├── comment (value datum)
        ├── comment author (value datum)
        ├── comment time (dateTimeStamp)
        ├── section aggregate document (snapshot of changed content)
        ├── material transformation aggregate document
        └── molecular structure aggregate document

The section aggregate document (section.schema) is the recursive page-content model - the core of the ELN structure:

section aggregate document (aggregate datum)
└── section document[] (indexed datum, unordered)
    ├── section identifier (value datum, REQUIRED)
    ├── section name (value datum)
    └── field aggregate document (aggregate datum)
        └── field document[] (indexed datum, unordered)
            ├── field identifier (value datum, REQUIRED)
            ├── field name (value datum, REQUIRED)
            ├── field type (value datum, REQUIRED)
            └── field content (exactly one of:)
                ├── table aggregate document (structured tabular data)
                │   └── table document[] (indexed datum)
                │       ├── table identifier (value datum)
                │       ├── table name (value datum)
                │       └── table cell aggregate document
                │           └── table cell document[] (indexed datum)
                │               ├── table cell identifier (value datum)
                │               ├── table cell name (value datum)
                │               ├── row index (integer)
                │               ├── column index (integer)
                │               ├── property name (value datum)
                │               ├── property type (value datum)
                │               ├── hidden flag (boolean)
                │               └── cell value (polymorphic: string | boolean | timestamp | double | integer)
                ├── property document[] (key-value properties)
                │   ├── property name (value datum, REQUIRED)
                │   ├── property type (value datum, REQUIRED)
                │   ├── unit symbol (value datum)
                │   ├── quantity type (value datum)
                │   └── property value (polymorphic: string | boolean | timestamp | double | integer)
                ├── section aggregate document (RECURSIVE - nested sections)
                ├── molecular structure identifier (value datum - inline chemical structure reference)
                ├── file attachment (POSIX path + media type + scalar string datum)
                └── datum aggregate document (formatted text content)
                    └── datum document[] (indexed datum)
                        ├── scalar string datum (REQUIRED - the text content)
                        └── string format type (REQUIRED - e.g. plain, rich text, HTML)

Key structural observations:

Distinction from technique schemas: Technique schemas model instrument output (measurements → processed data → calculated data). The ELN schema models human-authored structured documents - sections with named fields that hold tables, properties, nested sections, chemical structures, or formatted text. The ELN is a page description language; technique schemas are data description languages.

Consumes: Materials (material transformation aggregate documents for synthesis steps), Samples (referenced via section fields and parent identifiers), Analytical (results captured in table fields or referenced via identifiers), Methods (referenced through property documents and parent linkage), Experiments (entry hierarchy via parent identifier/name, entry type classification)

ASM coverage: Excellent - the REC/2026/06 electronic-lab-notebook model is substantial. The recursive section/field/table structure, versioned audit trail, chemistry-aware aggregates, and polymorphic field content demonstrate that ASM's document model is genuinely domain-agnostic - the same aggregate/indexed patterns that model chromatograms also model structured notebook pages with version-controlled audit trails.

21. LIMS (Laboratory Information Management System)

Definition: A system for tracking what was measured and whether it passed - record-centric, managing sample registration, test assignment, result entry, specification comparison, and approval workflows.

BFO category: planned process (occurrent) + generically dependent continuant (IAO data item) - models both the workflow and the records it produces

BFO-aligned ontologies:

LIMS typed lineage: sample registration → test definition → selected method version → analytical execution → result → conformance assessment → review/approval → decision. Each step preserves source-system IDs and provenance, enabling end-to-end traceability from sample intake to release verdict.

Distinction from ELN: LIMS controls sample-centric laboratory execution from registration and custody through test assignment, result review, approval, and disposition. ELN (§20) supports scientist-authored planning and contemporaneous documentation of experimental work, observations, rationale, and interpretation. Product capabilities may overlap; the authoritative record owner for each workflow must be defined per implementation.

Distinction from MES: LIMS operates at the laboratory level (samples, tests, results). MES operates at the plant level (batches, work orders, process steps). LIMS receives IPC sample requests from MES and returns batch disposition decisions.

Proposed ASM document model:

sample workflow aggregate document (root, aggregate datum)
└── sample workflow document[] (indexed datum)
    ├── sample identifier (value datum, REQUIRED)
    ├── written name (value datum)
    ├── workflow status (category datum → $asm.value-instance-of)
    │   enum: registered, in progress, pending review, approved, rejected
    ├── sample registration document (aggregate datum)
    │   ├── sample identifier (value datum, REQUIRED)
    │   ├── material reference (value datum)
    │   ├── registration date (value datum)
    │   └── priority (category datum → $asm.value-instance-of)
    │       enum: routine, rush, urgent
    ├── test assignment document[] (indexed datum, $asm.array-ordered: true)
    │   ├── test definition reference (value datum, REQUIRED)
    │   ├── selected method version reference (value datum, REQUIRED)
    │   ├── assigned analyst (value datum)
    │   ├── due date (value datum)
    │   ├── test execution reference (value datum, REQUIRED)
    │   ├── analytical run reference document[] (indexed datum)
    │   ├── result reference document[] (indexed datum)
    │   └── conformance assessment document (aggregate datum, optional)
    │       ├── acceptance criteria reference (value datum, REQUIRED)
    │       ├── assessment status (category datum → $asm.value-instance-of)
    │       │   enum: pass, fail, indeterminate, investigation-required
    │       └── rationale and investigation reference (value datums)
    ├── review and approval document (aggregate datum)
    │   ├── review status (category datum → $asm.value-instance-of)
    │   └── reviewer, approver, and timestamps (value datums)
    ├── decision record reference (value datum)
    ├── certificate of analysis document (aggregate datum)
    │   └── CoA parameter summary document[] (indexed datum)
    │       ├── written name (value datum, REQUIRED)
    │       ├── measured value (quantity datum)
    │       └── conformance status (category datum → $asm.value-instance-of)
    ├── reference aggregate document (aggregate datum)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Assessment status, workflow status, and priority use category datum (closed enumerations). Specification and method references use reference aggregate document. Result comparison limits use the same lower/upper limit pattern as objective specification aggregate document. Electronic signatures are omitted (cross-cutting concern). The CoA is structured as a parameter summary array rather than an opaque document.

Consumes: Materials, Samples, Analytical, Methods, Tests

ASM coverage: Partial - ASM's technique schemas model the analytical runs inside LIMS workflows but not the sample lifecycle, test assignment, specification comparison, or approval state machine.

22. MES (Manufacturing Execution System)

Definition: A system for controlling what was produced and how - batch/order-centric, managing recipe execution, equipment allocation, material consumption, and yield tracking. Aligned with ISA-88 (batch control) and ISA-95 (enterprise-control integration, IEC 62264).

BFO category: planned process (occurrent) - IOF ManufacturingProcess

BFO-aligned ontologies:

ISA-95 hierarchy: Enterprise → Site → Area → Process Cell → Unit → Equipment Module → Control Module. MES operates at Level 3 (manufacturing operations), bridging Level 4 (ERP business planning) and Levels 0–2 (process control, PLC/SCADA).

Distinction from LIMS: MES operates at the plant level (batches, work orders, process steps). LIMS operates at the laboratory level (samples, tests, results). MES sends IPC sample requests to LIMS and receives test results back. MES owns the electronic batch record (EBR); LIMS owns the certificate of analysis (CoA).

Proposed ASM document model:

batch record aggregate document (root, aggregate datum)
└── batch record document[] (indexed datum)
    ├── batch identifier (value datum, REQUIRED)
    ├── work order (value datum)
    ├── product identifier (value datum)
    ├── written name (value datum)
    ├── batch status (category datum → $asm.value-instance-of)
    │   enum: planned, in progress, completed, released, rejected
    ├── reference aggregate document (aggregate datum - recipe reference)
    │   └── reference document[] (indexed datum)
    │       ├── reference identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       └── data system identifier (value datum)
    ├── planned vs actual quantities document (aggregate datum)
    │   ├── planned quantity (quantity datum)
    │   └── actual quantity (quantity datum)
    ├── process step document[] (indexed datum, $asm.array-ordered: true - S88 procedural hierarchy)
    │   ├── written name (value datum, REQUIRED - step name)
    │   ├── equipment reference (value datum)
    │   ├── process parameter log document (aggregate datum)
    │   │   └── parameter reading document[] (indexed datum, $asm.array-ordered: true - time-series)
    │   │       ├── timestamp (value datum)
    │   │       ├── value (quantity datum)
    │   │       └── alarm status (category datum → $asm.value-instance-of)
    │   │           enum: normal, warning, alarm, interlocked
    │   └── material consumption document (aggregate datum)
    │       ├── written name (value datum, REQUIRED - material identity)
    │       ├── batch identifier (value datum)
    │       ├── supplier lot number (value datum)
    │       └── quantity consumed (quantity datum)
    ├── IPC document[] (indexed datum - in-process control points)
    │   ├── sample request reference (value datum → LIMS)
    │   ├── conformance assessment reference (value datum → LIMS)
    │   ├── conformance status (category datum → $asm.value-instance-of)
    │   │   enum: pass, fail, indeterminate, investigation-required
    │   └── process decision (category datum → $asm.value-instance-of)
    │       enum: continue, hold, reject
    ├── deviation document[] (indexed datum)
    │   ├── deviation type (category datum → $asm.value-instance-of)
    │   │   enum: minor, major, critical
    │   ├── description (value datum)
    │   └── corrective action (value datum)
    ├── batch disposition document (aggregate datum)
    │   ├── yield (quantity datum)
    │   └── disposition (category datum → $asm.value-instance-of)
    │       enum: released, rejected, quarantined
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

All closed enumerations (batch status, alarm status, conformance status, process decision, deviation type, disposition) use category datum with $asm.value-instance-of. Material consumption fields align with the method schema's naming (written name, batch identifier, supplier lot number). Recipe references use reference aggregate document. Electronic signatures are omitted (cross-cutting concern).

Consumes: Materials, Procedures, Recipes, and LIMS (for in-process tests)

ASM coverage: None - batch records, process parameter time-series, material genealogy, and equipment state tracking are outside ASM's analytical data scope. The ISA-88 procedural hierarchy (§11) provides the structural mapping if ASM were extended into this domain.

23. ERP (Enterprise Resource Planning)

Definition: A system for managing what the business plans, procures, and accounts for - order-centric, covering production orders, inventory transactions, material master data, cost allocation, and quality management modules. Operates at ISA-95 Level 4 (business planning and logistics).

BFO category: generically dependent continuant (CCO PlanSpecification) + planned process (CCO Act)

BFO-aligned ontologies:

Data flow across integration tier:

ERP is the outermost integration layer - it triggers MES work orders, receives batch dispositions back, manages material master data (which feeds the Materials hierarchy at Tier 1), and holds the cost/schedule dimension that no other system owns.

Distinction from MES: ERP plans and accounts; MES executes. ERP owns the production order ("make 500 kg of API, lot L-2026-042"); MES owns the batch record that documents how that order was executed. ERP receives the batch disposition (released/rejected) and updates inventory; MES produces the disposition based on process data and LIMS results.

Distinction from Materials (§1): Materials defines the specification of a substance (what it is, its composition, acceptance criteria). ERP manages the enterprise lifecycle of that material - procurement, inventory, lot genealogy, vendor qualification. The ERP material master record is the source of identity; the Materials document model is the analytical characterization.

Proposed ASM document model:

The ERP document model captures only the surfaces relevant to analytical data traceability - material master records, production orders, and quality management decisions. Financial data (GL accounts, cost centers, purchase order pricing) is excluded as outside ASM scope.

enterprise resource aggregate document (root, aggregate datum)
└── enterprise resource document[] (indexed datum)
    ├── material master document (aggregate datum - enterprise material identity)
    │   ├── material identifier (value datum, REQUIRED - ERP material number)
    │   ├── written name (value datum, REQUIRED)
    │   ├── material type (category datum → $asm.value-instance-of)
    │   │   enum: raw material, intermediate, finished product, packaging material
    │   ├── material group (value datum)
    │   ├── unit of measure (value datum)
    │   ├── shelf life (quantity datum)
    │   ├── storage conditions document (aggregate datum)
    │   │   ├── temperature range (quantity datum)
    │   │   └── humidity range (quantity datum)
    │   └── vendor aggregate document (aggregate datum)
    │       └── vendor document[] (indexed datum)
    │           ├── vendor identifier (value datum, REQUIRED)
    │           ├── written name (value datum)
    │           ├── vendor status (category datum → $asm.value-instance-of)
    │           │   enum: qualified, conditionally approved, disqualified
    │           └── catalog number (value datum)
    │
    ├── production order document (aggregate datum - what to make)
    │   ├── order identifier (value datum, REQUIRED)
    │   ├── product identifier (value datum)
    │   ├── written name (value datum)
    │   ├── batch identifier (value datum)
    │   ├── planned quantity (quantity datum)
    │   ├── actual quantity (quantity datum)
    │   ├── order status (category datum → $asm.value-instance-of)
    │   │   enum: planned, released, in progress, completed, closed
    │   ├── bill of materials aggregate document (aggregate datum)
    │   │   └── bill of materials document[] (indexed datum)
    │   │       ├── material identifier (value datum, REQUIRED)
    │   │       ├── written name (value datum)
    │   │       ├── planned quantity (quantity datum)
    │   │       └── actual quantity (quantity datum)
    │   └── reference aggregate document (aggregate datum - recipe/MES references)
    │       └── reference document[] (indexed datum)
    │           ├── reference identifier (value datum, REQUIRED)
    │           ├── written name (value datum)
    │           └── data system identifier (value datum)
    │
    ├── inventory lot document (aggregate datum - lot/batch tracking)
    │   ├── batch identifier (value datum, REQUIRED)
    │   ├── material identifier (value datum, REQUIRED)
    │   ├── supplier lot number (value datum)
    │   ├── vendor identifier (value datum)
    │   ├── quantity on hand (quantity datum)
    │   ├── manufacture date (value datum)
    │   ├── expiry date (value datum)
    │   ├── lot status (category datum → $asm.value-instance-of)
    │   │   enum: unrestricted, in quality inspection, blocked, quarantined
    │   └── lot genealogy aggregate document (aggregate datum - parent/child lots)
    │       └── lot genealogy document[] (indexed datum)
    │           ├── batch identifier (value datum, REQUIRED)
    │           ├── relationship type (category datum → $asm.value-instance-of)
    │           │   enum: parent lot, child lot, split lot, merged lot
    │           └── quantity (quantity datum)
    │
    ├── quality decision document (aggregate datum - QM module: usage decision)
    │   ├── inspection lot identifier (value datum, REQUIRED)
    │   ├── batch identifier (value datum)
    │   ├── usage decision (category datum → $asm.value-instance-of)
    │   │   enum: accepted, rejected, conditionally accepted
    │   ├── decision date (value datum)
    │   ├── decision maker (value datum)
    │   └── reference aggregate document (aggregate datum - LIMS/CoA references)
    │       └── reference document[] (indexed datum)
    │           ├── reference identifier (value datum, REQUIRED)
    │           ├── written name (value datum)
    │           └── data system identifier (value datum)
    │
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

Four sub-documents capture the ERP surfaces that feed analytical workflows: material master (source of material identity for §1 Materials), production order (triggers MES batch records in §22), inventory lot (lot genealogy and status for sample traceability in §2), and quality decision (usage decisions that consume LIMS results from §21). Financial and accounting data (cost centers, GL accounts, purchase order pricing) is excluded - it has no bearing on analytical data traceability.

Consumes: Materials (material identity), LIMS (test results for quality decisions), MES (batch dispositions)

ASM coverage: None - ERP data is currently outside ASM's analytical scope. However, ERP is the source system for material master records and lot identity, making it the outermost traceability boundary. Without ERP context, a sample's material identity and lot genealogy are opaque strings.

24. Operational Technology

Definition: The industrial control and monitoring systems that operate at ISA-95 Levels 0–2 - SCADA (Supervisory Control and Data Acquisition), DCS (Distributed Control Systems), PLC (Programmable Logic Controllers), and process historians. These are subtypes or system categories within the Operational Technology domain, not separate semantic domains.

BFO category: The physical sensors, actuators, controllers, and control systems are material entities (continuants). Their sensing and control activities are processes (occurrents). Historian series, alarm records, and equipment-state records are information content entities that are about those processes and material entities.

BFO-aligned ontologies and mapped standards:

Boundary with MES: MES (§22) operates at ISA-95 Level 3 - production management, batch scheduling, material tracking. Operational Technology operates below MES at Levels 0–2 - direct process sensing, control, and real-time data logging. The boundary follows the ISA-95 activity model: MES dispatches work orders and collects production records; OT executes physical control loops and captures continuous/discrete sensor data.

Relevance to the context graph: OT systems produce time-series data (temperatures, pressures, flows, weights, environmental conditions) that contextualizes batch manufacturing and provides the environmental provenance for GMP-regulated processes. When a stability study references "storage at 25°C/60%RH," the actual conditions are recorded by OT systems. Integration factories must map OT historian data into the context graph via the MES or directly via structured exports.

Proposed ASM document model:

The OT model is a read-only evidence representation. It captures observations, equipment states, alarms, and their execution context after they are emitted by authoritative control systems. It does not issue commands, modify setpoints, execute interlocks, or replace validated PLC, DCS, or SCADA control logic.

operational technology aggregate document (root, aggregate datum)
└── operational technology record document[] (indexed datum)
    ├── record identifier (value datum, REQUIRED)
    ├── source system document (aggregate datum)
    │   ├── source system identifier (value datum, REQUIRED)
    │   ├── source system type (category datum → $asm.value-instance-of)
    │   │   enum: SCADA, DCS, PLC, process historian, building management system
    │   ├── written name (value datum)
    │   └── data system identifier (value datum)
    ├── equipment hierarchy document (aggregate datum - ISA-95 / ISA-88 context)
    │   ├── site identifier (value datum)
    │   ├── area identifier (value datum)
    │   ├── process cell identifier (value datum)
    │   └── equipment reference document[] (indexed datum)
    │       ├── equipment identifier (value datum, REQUIRED)
    │       ├── written name (value datum)
    │       ├── equipment level (category datum → $asm.value-instance-of)
    │       │   enum: unit, equipment module, control module, sensor, actuator
    │       └── reference aggregate document (aggregate datum - Equipment §8)
    ├── execution context document (aggregate datum)
    │   ├── batch identifier (value datum)
    │   ├── process step identifier (value datum)
    │   ├── recipe identifier (value datum)
    │   ├── procedure or phase identifier (value datum)
    │   └── reference aggregate document (aggregate datum - MES §22)
    ├── observation stream document[] (indexed datum)
    │   ├── tag identifier (value datum, REQUIRED)
    │   ├── written name (value datum)
    │   ├── observed property (class datum)
    │   ├── unit (value datum)
    │   ├── sampling mode (category datum → $asm.value-instance-of)
    │   │   enum: continuous, periodic, event driven
    │   ├── source equipment identifier (value datum)
    │   └── measurement series (datacube datum - timestamp × value × quality code)
    ├── equipment state document[] (indexed datum, $asm.array-ordered: true)
    │   ├── timestamp (datetime, REQUIRED)
    │   ├── equipment identifier (value datum, REQUIRED)
    │   ├── operating mode (category datum → $asm.value-instance-of)
    │   │   enum: automatic, manual, cascade, maintenance, out of service
    │   ├── state (category datum → $asm.value-instance-of)
    │   │   enum: idle, running, held, stopped, faulted
    │   ├── setpoint (quantity datum)
    │   ├── process value (quantity datum)
    │   └── interlock status (category datum → $asm.value-instance-of)
    │       enum: clear, active, bypassed
    ├── alarm event document[] (indexed datum, $asm.array-ordered: true)
    │   ├── alarm identifier (value datum, REQUIRED)
    │   ├── source timestamp (datetime, REQUIRED)
    │   ├── tag identifier (value datum)
    │   ├── alarm class (category datum → $asm.value-instance-of)
    │   │   enum: process, equipment, safety, data quality, communication
    │   ├── alarm state (category datum → $asm.value-instance-of)
    │   │   enum: active, acknowledged, cleared, suppressed
    │   ├── alarm limit (quantity datum)
    │   ├── recorded value (quantity datum)
    │   └── acknowledgement actor and timestamp (value datums)
    ├── data provenance document (aggregate datum)
    │   ├── source record identifier (value datum, REQUIRED)
    │   ├── source timestamp (datetime, REQUIRED)
    │   ├── ingestion timestamp (datetime, REQUIRED)
    │   ├── quality status (category datum → $asm.value-instance-of)
    │   │   enum: good, uncertain, bad, substituted, missing
    │   ├── source time zone (value datum)
    │   └── source checksum (value datum)
    └── version log (aggregate datum)
        └── version log entry[] (indexed datum, minItems: 0)
            ├── version number (value datum, REQUIRED)
            ├── effective date (datetime, REQUIRED)
            └── author, change description, change reason, change type (value datums)

The observation stream carries process values such as temperature, pressure, flow, weight, and relative humidity. The equipment state and alarm event arrays preserve ordered operational context around deviations and process decisions. The execution context binds those records to the MES batch, recipe, process step, and equipment asset without copying the authoritative records from those systems.

Closed state sets use category datum with $asm.value-instance-of. Quantitative readings retain quantity kind and unit semantics through quantity datum or the measures of a datacube datum. Source timestamps, quality codes, and checksums remain attached to the imported evidence so historian interpolation or substitution does not appear as an original controller reading.

Consumes: Equipment (§8), Procedures (§11), Recipes (§12), MES batch and process-step context (§22), and Master & Reference Data identifiers.

Produces: Typed observation streams, equipment-state histories, alarm events, and environmental records referenced by MES batch records, stability studies, investigations, and Decision Records.

ASM coverage: None - no OT-specific ASM schema exists. ASM provides the aggregate, indexed, quantity, category, reference, and datacube structural patterns needed for an evidence representation, but controller configuration, control logic, alarm management, and safety functions remain governed by the authoritative OT systems and their validated engineering standards.

Master & Reference Data (cross-cutting foundation)

Master and Reference Data is not a domain tier - it is the cross-cutting foundation that all semantic domains depend upon. It provides:

• Authoritative identifiers: Globally unique, reconciled identifiers for materials, products, methods, instruments, equipment, sites, and organizational units.
• Controlled vocabularies: Governed term lists (technique types, material roles, lifecycle states, unit systems) used as category datum and class datum values across all domain schemas.
• Stewardship and versioning: Ownership, approval workflows, effective dating, and change history for master records.
• Mappings and identity reconciliation: Cross-system identity resolution (the same material may be "MAT-001" in ERP, "Raw Material A" in LIMS, and "API batch 2024-03" in the ELN). ICAD's C2 sub-principle ("one identity per entity, globally") is operationalized here.

In ASM terms, the reference aggregate document pattern and the life cycle status + version log pattern are the structural primitives through which Master Data governance is expressed in every domain schema.

Summary

This proposal defines a Connected Domains architecture spanning the full pharmaceutical R&D value chain:

• Tier 1 - Atomic (8 domains): Materials, Samples, Analytical, Results, Methods, Specifications, Instruments, Equipment
• Tier 2 - Compositional (4 domains): Tests, Experiments, Procedures, Recipes
• Tier 3 - Systemic (3 domains): Studies, Projects, Programs
• Evidence Outputs (4 governed artifact models): Scientific Interpretations, Scientific Reports, Regulatory Submissions, Decision Records
• Implementation Surfaces (parallel view): ELN, LIMS, MES, ERP, Operational Technology
• Master & Reference Data (cross-cutting foundation): Authoritative identifiers, controlled vocabularies, stewardship, versioning, mappings, identity reconciliation

The Allotrope Foundation's Connected Domains initiative (CR 2026/06) covers the semantic domain tiers (Tiers 1 through 3). This proposal additionally describes Implementation Surfaces (ELN, LIMS, MES, ERP, Operational Technology), Evidence Outputs (Scientific Interpretations, Scientific Reports, Regulatory Submissions, Decision Records), and the cross-cutting Master and Reference Data foundation. The resulting inventory contains 24 modeled structures: 15 semantic domains, four governed artifacts, and five implementation surfaces. The foundation is the twenty-fifth architecture element, not another model. All modeled structures adopt ASM's structural building blocks and the cross-domain patterns defined by the Connected Domains Candidate Release (CR 2026/06). Together, they provide the structural vocabulary required to implement ICAD's Contextualize principle - linking every scientific data point to its full operational context through typed, semantically grounded relationships.

This article is a discussion proposal. The models require validation against real-world data, alignment with the Allotrope product team's schema development roadmap, and harmonization with the Pistoia Alliance ontology initiatives (IDMP-O, CMC-PO, Digital Analytical Methods).

Whether to extend ASM into process-control semantics (Procedures, Recipes) remains an open architecture question. It requires use-case validation, ownership clarification between Allotrope and Pistoia, and demand assessment from the community. CMC-PO and ISA-88/95 should lead process semantics; Allotrope would assess mappings and evidence structures. A scoped discovery and validation project with Pistoia - before schema development - is the recommended next step.

References

Allotrope Foundation. (2024). Allotrope Framework and Simple Model (ASM). Available at: https://www.allotrope.org/product-asm

Colsman, W. (2026). The ICAD Principles: Integrate, Contextualize, Analyze, Decide. ZONTAL Inc. Available at: https://zontal.io/icad-principles. Licensed under CC BY 4.0.

Colsman, W. (2026). From FAIR Data to Scientific Decision Intelligence: The ICAD Context Graph for Pharmaceutical R&D. ZONTAL Inc. Presented at Spring 2026 Allotrope Connect Workshop, Leiden, Netherlands. Available at: https://zontal.io/whitepapers/from-fair-data-to-scientific-decision-intelligence

Pistoia Alliance. (2026). IDMP Ontology (IDMP-O). Available at: https://www.pistoiaalliance.org/projects/current-projects/idmp-ontology/

Schafer, W. (2026). Connected Domains model update - Q2 CR release. Presented at Spring 2026 Allotrope Connect Workshop, Leiden, Netherlands.