ICAD Principles / I. Integrate / I3
I3

I3: Each integration build creates a reusable asset

Integration is industrialized — each build creates a reusable asset that reduces the cost and time of the next integration.

What does this mean?

Traditional instrument integration in pharma operates as a project: a team scopes the requirements for connecting a new instrument, builds a point-to-point integration, validates it, and moves on. The next instrument starts from scratch. There is no compound learning, no reusable architecture, and no reduction in marginal cost.

I3 requires that each integration build produces reusable components — format converters, validation rules, metadata schemas, protocol adapters, workflow orchestration, and regression test suites — that are cataloged and available for subsequent builds. AI-assisted converter factories can handle native vendor formats in most cases, dramatically reducing the engineering effort per new vendor. The architecture compounds with every build: converter patterns, validation rules, metadata schemas, and testing frameworks all accumulate. Integration 50 should cost a fraction of integration 1 because the factory has learned from the prior 49.

The factory model

Industrialized integration treats instrument connectivity as a manufacturing process, not a services engagement. The key components:

  • Format converters: AI-assisted converter generation can handle native vendor formats in most cases. The AI drafts the conversion mapping from sample output, an engineer reviews and validates, and the converter is released into the pipeline. Converter patterns and extraction logic accumulate across builds, making each subsequent converter faster to produce
  • Protocol adapters: Connection handlers for SiLA 2, OPC-UA, REST APIs, file system watchers, and database connectors are shared infrastructure, not per-integration custom code
  • Validation modules: Data quality checks (file integrity, expected field presence, value range validation) are composed from a library of reusable rules
  • Metadata extractors: Instrument-specific metadata (run parameters, column identity, calibration state) is extracted by domain-specific extractors that accumulate across builds

The factory and open standards

An industrialized factory does not just convert native data into an internal format. It produces output compliant with formal technique specifications defined by open standards bodies. Allotrope, for example, defines a technique as a composite specification: JSON schemas (Allotrope Simple Model, or ASM) describe the data structure, RDF ontologies (Allotrope Foundation Ontology, or AFO) define the scientific vocabulary, and a manifest describes how they compose. A converter that produces Allotrope-compliant output makes the data interoperable by design — not as a downstream transformation step.

The factory operates at three levels relative to these specifications:

  • Produce compliant output when a technique specification exists — the converter maps vendor-native fields to the corresponding ASM schema and AFO terms
  • Propose extensions to existing specifications when a vendor's output contains scientifically relevant fields not yet covered by the current schema — the factory identifies the gap and drafts the extension
  • Draft new technique specifications for instrument families that have no existing specification — because without a specification, data from that instrument family cannot be converted to a standards-compliant representation, and the entire downstream ICAD sequence (C→A→D) is blocked for that data

This makes the factory a contributor to the standards ecosystem, not just a consumer. Each new technique specification the factory produces expands the coverage of the standards body, which in turn benefits every organization using those standards — compounding beyond the boundaries of a single organization.

Operational test

What percentage of a new integration build uses components from prior integrations? If the answer is below 50%, the integration process is not yet industrialized. Mature integration factories achieve 70–90% reuse on instrument types within the same technique family.

Compounding economics

The compounding property of ICAD is most visible in I3. Consider a facility with 300 instruments across 15 analytical techniques and dozens of vendors. A project-based approach treats each instrument type as a standalone effort — even where instruments share a technique, significant per-vendor engineering is required because there is no shared infrastructure to build on. An AI-assisted factory approach generates each converter from sample output, accumulating patterns across every build. By the fiftieth converter, the factory has learned enough about format structures, metadata conventions, and validation patterns that new converters are generated in hours and validated in days.

When a new instrument model or software version arrives, it may introduce format differences — modified file headers, shifted metadata fields, changed export schemas, or restructured result tables. Every vendor release risks breaking existing converters. The factory's value is not that breakage never occurs. It is that recovery is fast. AI-assisted generation drafts an updated converter from sample output, the engineer reviews the diff, and the regression suite confirms nothing else broke. The updated component is available for new instruments and future builds — validated systems already in production remain untouched. What took months in a project model takes days in a factory model. This is what compounding returns means in practice.

Example — technique family reuse

An organization builds its first plate reader integration for one vendor's native format. The AI-assisted factory drafts a converter from sample output, an engineer validates the mapping, and a regression test suite is built. The second plate reader integration — for a different vendor with a different format — follows the same pattern: the AI drafts a new converter from that vendor's sample output, reusing the validation module (dose-response curve completeness, expected well layout, blank subtraction checks) and regression framework from the first build. By the fifth plate reader integration, each new converter is generated faster because the factory has accumulated converter patterns, validation rules, and testing infrastructure across all prior builds. Every validated pipeline run produces a conversion that meets the regulatory definition of a true copy — the process is validated, reproducible, and auditable (MHRA GxP Data Integrity Guidance, PIC/S PI 041-1).

Why the factory targets data models, not reports

Industrialized integration must target the data model, not the report template. Plate reader software illustrates why: every lab, every assay, every user can produce a structurally different report from the same instrument. Parsing reports cannot scale — a parser for one ELISA template breaks when a cell viability template arrives. Integration factories that parse the underlying data model (raw reads, well maps, calculation definitions) handle all assay types from the same software, achieving the factory economics that I3 requires.

What this is not

I3 is not a claim about any specific instrument or software product. It is an architectural principle: integration infrastructure must be designed for reuse and compounding. An organization using custom Python scripts per instrument is not industrialized, regardless of engineering quality. An organization using an enterprise integration platform with per-instrument custom mappings is similarly not industrialized if the mappings share no reusable components.

Relationship to other principles

I3 amplifies I1 and I2. If every integration must be built from scratch, point-of-creation capture (I1) for 300 instruments is economically infeasible. Industrialization makes I1 achievable at scale. I3 directly enables I4 (factory-speed onboarding) — the factory cannot operate at speed without reusable assets to compose from.