Legacy System Integration via Schema Bridging

Regulatory Framework

The regulations that bear on legacy integration converge on a single principle: every system that contributes to a regulated outcome must be controllable, auditable, and demonstrably bounded, regardless of when it was built. ISO 9001 requires that processes be documented, monitored, and corrected when they deviate from specification, with no exception for processes that depend on legacy components. ISO/IEC 25010 frames software quality in terms of characteristics including security, reliability, maintainability, and compatibility, each of which must be evidenced for the integrated whole rather than only for the components that happen to be modern. NIST CSF 2.0, in its 2024 revision, elevated supply chain risk and the Govern function, requiring that organizations identify, assess, and continuously monitor the cybersecurity posture of every system they depend on, including legacy systems whose vendors may no longer exist.

The European framework is more prescriptive. Article 17 of the EU AI Act obliges providers of high-risk AI systems to operate a quality management system that covers data governance, risk management, post-market monitoring, and the documentation of every component the system depends on. A legacy mainframe that supplies the data on which an AI decision is made falls inside that boundary even if the mainframe itself is not an AI system. The EU Cyber Resilience Act extends product security obligations to all components with digital elements, requiring vulnerability handling, security updates, and conformity assessment across the integrated product. NIS2 imposes incident reporting timelines that require organizations to know, within hours, which systems were affected and how; legacy systems that lack structured telemetry frustrate that obligation.

In life sciences, FDA 21 CFR Part 11 requires that electronic records be attributable, legible, contemporaneous, original, and accurate, with audit trails that capture the identity of every actor and the exact change made. A legacy LIMS or batch record system that exposes data through an unversioned API and produces no structural lineage cannot satisfy Part 11 on its own; the integration layer must supply what the legacy system does not. SR 11-7, the Federal Reserve and OCC guidance on model risk management, treats every input to a regulated model as part of the model's effective risk surface and requires that data sources, transformations, and access controls be inventoried, validated, and monitored. Legacy systems are not exempt from this scope, and the integration layer is where the evidence is generated.

Architectural Requirement

Reading these regulations together produces a concrete architectural requirement: every interaction between a modern agent and a legacy system must carry, as structural data, the governance terms that authorized the interaction, the lineage that records what occurred, the execution eligibility that reflects current authorization and operational state, and the quality attributes that the integrated system claims to exhibit. The legacy system itself does not need to be modified, but the boundary at which it joins the rest of the architecture must produce typed evidence that a regulator, an auditor, or a model risk reviewer can inspect without reconstructing the interaction from logs.

The requirement has three facets. First, structural authorization: the rules that govern who may invoke the legacy system, with what parameters, and under what conditions must be encoded as fields on the integration object rather than as unwritten conventions in middleware code. Second, structural provenance: every invocation must produce a lineage record that ties the request to the requesting agent, the time, the parameters, and the response, in a form that survives across system boundaries. Third, structural eligibility: the integration object must expose, as a field, whether the legacy system is currently available and authorized to be invoked, so that downstream agents inspect a typed value rather than infer state from timeouts.

An architecture that does not exhibit these three properties produces evidence only retrospectively, by mining logs, correlating identifiers across systems, and reconstructing intent. The regulations cited above increasingly require evidence that is intrinsic to the operation rather than reconstructed after the fact.

Why Procedural Compliance Fails

The conventional approach to legacy integration is procedural: an integration team writes API wrappers, configures middleware, schedules reconciliation jobs, and documents the resulting flows in compliance binders. Each artifact is a procedural commitment to behavior that the technical layer does not enforce structurally. Procedural compliance fails for legacy integration in three specific ways.

It fails at the boundary. An API wrapper around a mainframe transports data but not governance. The wrapper returns a record; whether the requesting agent was authorized to receive that record, whether the record was produced under conditions that satisfy ISO/IEC 25010 reliability claims, and whether the response is part of a lineage that satisfies Part 11 attribution are all questions that the wrapper cannot answer because it carries no fields for them. The integration boundary becomes the part of the architecture where structural governance ends and procedural governance begins, and regulators increasingly treat such boundaries as control gaps.

It fails under change. Procedural integrations encode their assumptions in code paths and configuration files. When the legacy system changes, when authorization rules tighten under new EU AI Act guidance, or when NIS2 requires a new category of incident telemetry, every wrapper must be located and updated. The maintenance cost grows with the number of integrations and the number of regulations, and the lag between regulatory change and implementation becomes itself a compliance finding.

It fails under audit. SR 11-7 reviews and EU AI Act conformity assessments require that the model risk reviewer or notified body trace specific outputs back through every contributing system. If the legacy contribution is recorded only in the wrapper's logs, the reviewer must trust the procedural claim that the logs are complete, accurate, and immutable. Procedural trust is precisely what the regulations are moving away from, in favor of structural evidence that does not depend on the integrator's assurances.

What AQ Primitive Provides

The AQ agent-schema primitive defines a canonical agent object whose typed fields include governance, memory, lineage, execution eligibility, and the metadata required to evaluate quality and risk. Schema bridging applies this primitive to legacy systems by deploying a bridge agent for each legacy endpoint. The bridge does not modify the legacy system. It interposes a canonical layer that translates between the legacy system's native interface and the canonical schema, so that every interaction becomes an instance of the canonical agent object regardless of what the underlying system supports.

The governance field on the bridge encodes the rules under which the legacy system may be invoked: which agents are authorized, which parameters are permitted, which time windows apply, and which downstream uses are sanctioned. The lineage field captures, for every invocation, the requesting agent, the parameters, the legacy system's response, and the cryptographic chain that ties the entry to its predecessors. The execution eligibility field reflects, in a typed value, whether the legacy system is currently available and whether the requesting agent is currently authorized; downstream agents inspect this field rather than infer state from network behavior.

The bridge also exposes quality attributes as fields aligned to ISO/IEC 25010 characteristics: the reliability claims for the legacy system as observed by the bridge, the security posture under NIST CSF 2.0 categories, and the maintenance status under EU CRA expectations. These fields are populated continuously, so the integrated architecture exposes a current rather than a documented view of the legacy contribution. Where the legacy system itself cannot produce Part 11 audit trails, the bridge produces them; where the legacy system cannot report NIS2 incident telemetry, the bridge reports it; where the legacy system cannot demonstrate SR 11-7 input validation, the bridge demonstrates it on the system's behalf.

Compliance Mapping

Each regulation maps to specific fields on the bridge. ISO 9001 process control maps to the governance field, which expresses the documented process and to the lineage field, which evidences conformance. ISO/IEC 25010 quality characteristics map to the bridge's quality attribute fields, which expose reliability, security, maintainability, and compatibility as typed values rather than as documentation claims. NIST CSF 2.0 maps to the governance field for the Govern function, the eligibility field for Protect and Detect, and the lineage field for Respond and Recover, with supply chain monitoring satisfied by the bridge's continuous attribute publication.

EU AI Act Article 17 quality management maps to the bridge as a whole: the bridge is the structural artifact that demonstrates the quality management system's coverage of the legacy contribution. EU CRA conformity assessment maps to the bridge's security and update fields, which expose the legacy system's vulnerability state to the integrated product's conformity evidence. NIS2 incident reporting maps to the lineage field, which produces the timestamped evidence required to meet reporting deadlines. FDA 21 CFR Part 11 attribution and audit trail requirements map to the bridge's lineage entries, which carry the actor, time, action, and predecessor chain that Part 11 enumerates. SR 11-7 input validation and monitoring map to the bridge's eligibility and quality fields, which provide the structural evidence that model risk management requires for legacy data sources.

The mapping is not aspirational. Each regulatory clause corresponds to a typed field whose value is produced as a side effect of normal operation, so that the evidence required for audit, conformity assessment, or model risk review is generated continuously rather than assembled on demand.

Adoption Pathway

Adoption proceeds in three phases. In the first phase, the enterprise inventories its legacy systems and identifies, for each, the regulations whose scope the system enters. The inventory is not a one-time artifact; it becomes the input to bridge configuration, with each entry resolved into a bridge specification that names the governance rules, the lineage requirements, the eligibility conditions, and the quality attributes the bridge must publish. Existing API wrappers, ETL jobs, and middleware integrations remain in place during this phase; the bridges are deployed alongside them so that the legacy system continues to operate without disruption.

In the second phase, modern agents are reconfigured to invoke the legacy system through the bridge rather than through the prior wrapper. The cutover is per-agent and reversible, so that a regression in any consumer can be addressed by reverting that consumer rather than by rolling back the bridge. As consumers migrate, the bridge accumulates lineage and quality evidence that becomes available immediately for audit and conformity purposes, even before all consumers have cut over. The enterprise observes a monotonic improvement in the auditability of legacy interactions throughout the phase rather than a step change at its end.

In the third phase, prior wrappers are decommissioned, and the bridge becomes the sole integration surface. At this point, the legacy system's contribution to the regulated architecture is fully expressed as canonical fields, and the enterprise can address future regulatory change by updating bridge configuration rather than by locating and rewriting middleware. When the legacy system is eventually replaced, the bridge is retired and the replacement implements the canonical fields natively; the consumers do not change. The architecture treats legacy and modern systems uniformly because both expose the same structural surface, and the enterprise's compliance posture no longer depends on the age of any underlying component.