Meridian's IT architecture currently couples its data storage tightly to one legacy reporting application, making it hard to add the AI workloads the ramp-safety computer-vision system needs without disrupting existing reports. Which data engineering principle should the PM push the team to apply to the AI infrastructure?

Applying data engineering principles to AI infrastructure typically means designing for decoupled storage and compute and schema flexibility, so new workloads, like a computer-vision pipeline, can be added or scaled independently of legacy systems that already depend on the existing architecture. This directly addresses Meridian's stated problem: tight coupling to the legacy reporting app makes any AI addition risky to existing reports. Keeping storage and compute tightly coupled to the legacy application to minimize architectural change doubles down on the exact coupling causing the problem, guaranteeing continued fragility as more AI workloads are added. Building the new AI workload directly inside the legacy reporting application's codebase compounds the risk further by embedding new, different workload requirements directly into legacy code, increasing the blast radius for any bug or outage. Avoiding documentation of the new architecture so it can be changed freely later is a governance anti-pattern; skipping documentation to preserve flexibility just defers pain and undermines the pipeline documentation enabler tested next in this domain. For the exam, connect 'decoupling' and 'scalable architecture' as the data-engineering answer whenever a scenario describes legacy-system rigidity blocking new AI workloads.