The new AI layer looked clean. It assembled customer context from CRM, product, risk and communication systems, then stored a convenient profile for an assisted service workflow. Within months, other teams read that profile directly. Corrections reached the original systems at different speeds. Nobody could state which version governed a customer decision.

The modern layer had not transformed the estate. It had created a second customer truth with better presentation and weaker authority. Its store was technically derived, operationally useful and institutionally ambiguous. The most serious risk was not one stale field. It was that decisions, controls and downstream work began to depend on a state that could not be reliably reconstructed or retired.

Most enterprise AI enters this kind of brownfield. Authoritative systems are old but indispensable. Business meaning is distributed across tables, procedures, queues and experienced staff. Controls live partly in code and partly in operating practice. Downstream consumers are incompletely registered. Replacing all of it at once is neither credible nor safe.

Brownfield intelligence is therefore a coexistence design problem. The task is to couple a bounded AI-assisted capability to existing commitments while preserving a single account of authority, making every side effect reconcilable, containing failure and retaining a credible exit. Coexistence may be temporary or permanent, but it must never be accidental.

Coexistence as an operating stateTemporary architecture still needs permanent-grade accountability

Software estates evolve under continuing pressure from changing requirements, environments and organisations.[1] Legacy research similarly describes systems whose replacement difficulty comes from business dependence, accumulated complexity and inadequate knowledge, not merely old technology.[2] An AI initiative arrives inside that history. It cannot treat the existing estate as a passive database with a thin API in front.

The coexistence state begins by declaring the bounded capability. It names the customer or operating outcome, population, participating systems, authoritative records, permitted decisions and duration. This boundary prevents an orchestration layer from collecting every convenient field, persisting general business state and becoming the estate’s undocumented centre.

A copied database is not a system of record because it is easier to query. Authority comes from an operating contract: ownership, update rights, valid-time rules, correction process, retention, evidence and consumer obligations. A derived store may cache or index authoritative facts, but it must expose provenance, freshness and reconstruction. If it cannot be rebuilt from governed sources and events, it has acquired business state that requires its own explicit authority decision.

The strong rival deserves acceptance. Wrapping legacy can preserve the complexity transformation was meant to remove. Adapters multiply, translation logic spreads and temporary dual-running consumes scarce people. Machine-learning systems add boundary erosion through data dependencies, feedback loops, undeclared consumers and configuration debt.[3] Technical-debt research also warns that expedient design choices create obligations whose cost grows when they are left implicit.[4]

The answer is not to pretend coexistence will be brief. Every adapter, sidecar and comparison path receives an owner, consumer register, service objective, cost ledger, expiry and exit test. Where no credible exit exists, permanent coexistence is priced honestly. Architecture becomes safer when leaders can see the continuing obligation rather than calling it a bridge forever.

Coexistence completion is proved through receipts: authoritative state reconstructed, typed commands accepted or rejected, divergent results adjudicated, outage fallback completed, hidden-consumer scan performed, cost allocated and one retirement trigger tested. A diagram shows intended connectivity. Receipts show that the boundary works under operating conditions.

Original synthesisThe ten-control brownfield coexistence envelope

The brownfield coexistence envelope is this article’s synthesis. It surrounds one bounded AI slice with ten controls. The controls are not a maturity checklist. They are a contract among business, legacy, AI, security, risk and operations owners for the period in which more than one technical implementation participates in one capability.

The first control resolves authority before connectivity. For every consequential field, state transition and decision, it records the governing source and the owner empowered to correct it. Authority can differ by concept: CRM may own legal identity, a product ledger may own balance and a case system may own workflow status. The AI slice composes those facts without claiming ownership through convenience.

The read and write controls are deliberately asymmetric. Reading for advice can often be bounded through purpose, minimisation, freshness and provenance. Writing changes the estate and needs a typed command, expected precondition, idempotency key, approval authority, result event and recovery behaviour. A general credential that lets an agent update arbitrary records destroys this boundary even if each individual action appears reasonable.

Semantic translation is a business control. An API field called “balance” may represent available, ledger, settled or exposure balance across products. A null may mean unknown, inapplicable or not yet calculated. Timestamps may represent observation time, effective time or ingestion time. The envelope records these meanings and versions them. Technical availability without semantic agreement is API optimism.

Identity separation makes action attributable. The customer, employee, service and AI component each retain distinct identity and entitlement. The command records on whose behalf an action was proposed, which policy authorised it and which system executed it. Shared credentials prevent reliable reconstruction and should block consequential coupling.

Five bounded designsChoose a coexistence pattern, not a vague integration style

The envelope supports five patterns. They are alternatives shaped by consequence, semantics, coupling, resilience and transition intent, not levels on a ladder. A low-consequence advisory use may need the first pattern for its entire life. A high-consequence capability may proceed directly to a controlled dual-run. The pattern applies to one slice, so neighbouring functions may use different boundaries.

Read-only advisory adapter

The adapter reconstructs context from governed sources and presents advice without changing authoritative state. It records source, valid time, purpose and model version beside the recommendation. An employee or deterministic workflow makes the consequential decision through the existing authorised path. This pattern fits uncertain value, weak write semantics or a need to observe variation before committing to automation.

Read-only does not mean risk-free. Advice can alter human decisions, enter notes or become an undeclared input to another process. The consumer register names where output appears, retention and whether it may be copied. Monitoring looks for recommendation dependence and feedback into training data. When AI is unavailable, the workflow continues through the established route with a visible loss of assistance, not a loss of state.

Deterministic anti-corruption layer

An anti-corruption layer translates old semantics into a typed domain contract and shields the new workflow from legacy idiosyncrasy. It is deterministic because the same valid input and contract version produce the same command or rejection. This pattern fits available interfaces with inconsistent field meanings, error conventions or units, especially when the intelligence sits above a stable boundary.

The layer owns translation, not business truth. It validates preconditions, maps errors and emits evidence about every transformation. It cannot silently infer a missing status or convert an ambiguous null into a convenient default. Each mapping is versioned against source and target definitions. The cost ledger includes changes required whenever either side moves, because that continuing translation burden is the price of coexistence.

Event-backed coexistence sidecar

A sidecar reconstructs operational state from authoritative events and holds only state that can be replayed. It may support low-latency context, monitoring or a bounded decision service while systems of record remain unchanged. This pattern fits estates where direct synchronous reads are too slow or fragile, provided event completeness, ordering, correction and replay are proved.

The sidecar exposes lag and provenance to its consumer. A delayed event cannot masquerade as current truth. Corrections supersede rather than erase earlier observations, and replay tests show that the same governed history reconstructs the declared state. Any sidecar field that cannot be rebuilt is either removed or promoted through an explicit authority decision. The sidecar fails closed or falls back when lag exceeds the outcome’s tolerance.

Controlled dual-run

Dual-running lets an existing and new path handle the same bounded cases while one remains authoritative. It is justified when comparison can resolve consequential uncertainty about semantics, controls or operating outcomes. The contract states which path may write, how results are paired, what counts as divergence, who adjudicates and which evidence permits migration.

Two live writers without conflict control are not a dual-run; they are divergence by design. The safe form uses one write authority or typed commands with version preconditions and idempotent reconciliation. Comparison includes customer outcome, control evidence, queue effects and recovery, not only model agreement. The period ends at a stated evidence threshold or expiry rather than continuing because nobody owns the migration decision.

Migrated system-of-record capability

A capability becomes authoritative only after state, decision rights, historical data, controls, consumers, recovery and retirement are transferred. Migration is appropriate when the new boundary has proved the operating contract and continuing coexistence costs more than consolidation. The designation is a governance event, not the moment a new database receives production traffic.

The change register identifies every known consumer of the old capability and the evidence that each has moved or been retired. Archive and legal retention are settled before shutdown. The old write path is disabled, credentials removed and reconciliation completed. If an undeclared workflow breaks during retirement, the response is governed recovery and consumer registration, not indefinite restoration of two truths.

Reads, writes and meaningType the boundary before attaching intelligence

The shadow-customer-record failure begins with a read convenience. Product, communication and risk data are copied into a profile whose freshness varies by source. The new workflow edits annotations locally. A campaign tool becomes a hidden consumer. Soon the profile influences service decisions even though corrections and valid-time semantics remain elsewhere. The design has crossed from cache to unofficial authority without a decision.

A governed read contract blocks that drift. It names the business purpose and population, lists the minimum fields, links each value to source and valid time, states freshness tolerance, defines retention and prohibits onward use outside registered consumers. Sensitive fields require entitlement at query and display, not merely during ingestion. Derived features carry the inputs and version needed to reproduce them.

A write contract is narrower. The intelligence proposes a typed business command such as “request evidence review” or “schedule approved communication”. The command includes actor, subject, expected state version, policy basis, parameters and idempotency key. A deterministic authority validates it. Success produces an authoritative event; rejection produces a reason the workflow can handle. The model never receives a general database update tool.

Dual-write divergence shows why this matters. If a new workflow and a legacy case tool can both set status, updates race. One says “resolved” while the other says “awaiting customer”. Retries may duplicate side effects and reporting selects whichever table it reads first. Without version preconditions, a conflict policy and a reconciliation owner, the organisation cannot explain the case history.

For a bounded transition, the existing case system may remain the sole writer while the new path sends commands. If two implementations must write, each operation is idempotent and state-versioned, conflicts enter a visible queue, and one owner adjudicates by a stated rule. Reconciliation is completed before the case leaves the bounded population. “Eventual consistency” is not an answer unless the allowed interval and customer consequence are explicit.

Comparison and adjudicationDual-running produces evidence only when divergence has an owner

A useful dual-run begins with paired cases, common inputs and declared timing. Results are compared across decision, reason, evidence, customer effect, control outcome and downstream queue impact. A difference is classified as timing, semantic translation, data freshness, policy interpretation, model behaviour, human override or execution fault. Agreement alone can also be misleading if both paths share the same bad source.

The adjudicator is independent of delivery targets and empowered to decide which result governs the case. They can pause the bounded slice, correct a mapping, revise the comparison population or reject migration evidence. Every decision produces a receipt linking inputs, versions, outputs, classification, governing outcome and remediation. Unresolved divergence does not disappear into an average accuracy score.

Comparison thresholds reflect consequence. A difference in suggested wording can tolerate review; a difference in eligibility, price, legal communication or account status may require case-level resolution before execution. The contract also distinguishes expected improvement from unexplained variance. A new path should not be forced to mimic a defective legacy decision, but it must prove why the difference is better and authorised.

The counter-case is a regulated, read-first workflow. It reconstructs case state from governed CRM, product and risk sources without creating a durable shadow record. A bounded model assists only an ambiguous evidence step. Any side effect passes as a typed command through existing authority. Outcomes are paired during dual-run, fallbacks are rehearsed and reconciliation receipts determine whether a slice migrates.

Three reusable components may survive even if the model-assisted step does not: the semantic read contract, the typed command gateway and the reconciliation ledger. This is valuable brownfield transformation because it improves authority and reversibility without making the AI layer the new centre. A weak outcome can stop the intelligent step while leaving the estate boundary safer.

Resilience boundaryDesign the outage before accepting the coupling

Availability objectives must refer to the business capability, not just the model endpoint. The AI service may be healthy while a legacy dependency times out, an event stream lags or an entitlement service fails. Conversely, intelligence may be unavailable while the established workflow can continue. The envelope maps these modes and the effect of each on customers, controls, queues and recovery.

A circuit begins with time and consequence limits. A slow advisory call is cancelled before it holds a case lock or causes duplicate submission. A failed sidecar read returns an explicit stale-state condition rather than a plausible old answer. A rejected command does not trigger an unconstrained retry. Retries use the same idempotency key and stop at a boundary that prevents repeated side effects.

Fallback can be a deterministic rule, existing manual path, smaller population or halt. It is chosen by consequence, not by an assumption that some answer is always better. The workforce needed for manual recovery is reserved and practised. If the manual route can absorb only a fraction of demand, admission control protects it. A paper fallback that depends on unavailable staff is not resilience.

Recovery proves more than service restoration. The team identifies in-flight cases, reconciles accepted commands, replays authoritative events, checks consumer state and closes any temporary access. A recovery receipt records the outage window, affected population, fallback decisions, residual divergence and customer remediation. Basel operational-resilience principles connect continuity to critical operations and tolerance for disruption.[10]

Third-party dependencies extend the circuit. The current Basel principles cover governance, assessment, due diligence, contracts, monitoring, continuity and exit across the provider lifecycle.[11] Provider fallback must include data portability, credential revocation, pending commands and concentration exposure. A second provider is not a substitute if it depends on the same event feed or identity service.

NIST’s secure development framework puts secure practices across preparation, protection, production and vulnerability response.[6] NIST AI risk resources add governance, context, measurement, management and continual review.[7][8] In brownfield work, those practices meet at the coexistence boundary: release evidence must include legacy assumptions, not only the new component.

Hidden consumers and exitMake temporary architecture decay visibly

The permanent-temporary layer begins with a reasonable exception. A team needs a translator to deliver one outcome. A second consumer arrives, then a batch export and a dashboard. The layer gains custom fields, retained state and privileged credentials. Its original owner moves. Retirement becomes risky because nobody can enumerate what would break.

A consumer register is therefore enforced at access, not maintained as a voluntary spreadsheet. Each client has an identity, purpose, data contract, owner, service objective and expiry. Logs detect unregistered access and unusual output reuse. The register includes human workflows: copied model output in a note or report can create dependence even when no technical API consumer exists.

Feedback-loop monitoring asks whether an output later re-enters context, labels or evaluation. A recommendation that shapes a human decision may become part of the historical record used to train the next model. Without separation, the system evaluates itself against outcomes it helped create and hidden dependence grows. The envelope marks model-originated evidence and preserves independent outcome measures where possible.

The full cost ledger covers build, translation changes, infrastructure, reconciliation, duplicate controls, manual recovery, incident response, consumer migration, audit, data retention and eventual retirement. These costs sit across budgets and are easily excluded from a local business case. Assigning them to named owners allows a fair comparison between continued coexistence, deeper migration and leaving the capability alone.

Exit triggers are observable: a new system can satisfy the semantic contract, a legacy release constraint ends, dual-run evidence clears, consumer count falls or continuing cost crosses an approved threshold. The retirement test removes one bounded dependency in a rehearsal and watches for undeclared effects. Evidence includes revoked credentials, archived records, removed schedules, consumer confirmation and successful recovery from an attempted old call.

Regulated organisations also need continuity and human oversight across the boundary. Digital operational resilience rules address ICT risk, incident handling, testing and third-party arrangements.[12] The EU AI Act’s human-oversight and accuracy, robustness and cybersecurity provisions matter where applicable.[13] Revised US model-risk guidance emphasises a risk-based approach for models within its scope.[9] The envelope locates evidence at the actual coupling rather than appending a general approval.

Interactive instrumentBrownfield Coexistence Pattern Selector

The selector turns boundary evidence into one of five patterns. It does not reward greater coupling. It may recommend a read-only design for a critical capability, or reject any AI connection when authority, semantics, reconciliation or recovery cannot be made safe. The dominant boundary and missing evidence remain visible beside the outcome.

ConclusionCoexistence is safe only when its authority and ending are observable

Brownfield transformation does not begin on a clean technical plane. It enters systems and procedures that continue to carry customers, money, decisions and legal obligations. A new AI layer can improve one bounded capability while making the estate less governable if it creates copied truth, broad write access, unowned divergence or hidden dependence.

The ten-control coexistence envelope keeps the boundary explicit. It declares authoritative state, governs minimised reads, types writes, versions semantics, separates identities, reconciles dual-running, isolates failure, monitors consumers, joins change ownership and attaches every temporary component to an exit contract. These controls belong to the operating slice, where evidence can be tested.

The five patterns provide real alternatives. Advice can remain read-only. Translation can be deterministic. Derived state can be replayable. Migration can use a controlled dual-run. A capability can become authoritative after its obligations move. When semantics, credentials, reconciliation or recovery remain unsafe, refusing the coupling is a sound architecture decision.

Temporary layers receive the same honesty. Their full cost and consumers remain visible. Expiry causes a decision, while retirement requires evidence. If coexistence must continue, its service, resilience and ownership obligations are funded as permanent. This prevents “temporary” from becoming a device for hiding another legacy system.

The strongest brownfield outcome is not a modern façade. It is an enterprise that can state where truth lives, how intelligence may influence it, how every side effect is attributed, how service continues during failure and how the coupling can end without discovering an invisible business process too late.

Evidence spineReferences

1. Lehman, M. M. (1980), ‘Programs, Life Cycles, and Laws of Software Evolution’, Proceedings of the IEEE, 68(9), 1060–1076. doi:10.1109/PROC.1980.11805.
2. Bisbal, J., Lawless, D., Wu, B. and Grimson, J. (1999), ‘Legacy Information Systems: Issues and Directions’, IEEE Software, 16(5), 103–111. doi:10.1109/52.795108.
3. Sculley, D. et al. (2015), ‘Hidden Technical Debt in Machine Learning Systems’, Advances in Neural Information Processing Systems 28. NeurIPS record.
4. Kruchten, P., Nord, R. L. and Ozkaya, I. (2012), ‘Technical Debt: From Metaphor to Theory and Practice’, IEEE Software, 29(6), 18–21. doi:10.1109/MS.2012.167.
5. US Government Accountability Office (2020), Technology Readiness Assessment Guide, GAO-20-48G. GAO.
6. National Institute of Standards and Technology (2022), Secure Software Development Framework Version 1.1, NIST SP 800-218. doi:10.6028/NIST.SP.800-218.
7. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
8. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
9. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
10. Basel Committee on Banking Supervision (2021), Principles for Operational Resilience. Bank for International Settlements.
11. Basel Committee on Banking Supervision (2025), Principles for the Sound Management of Third-Party Risk. Bank for International Settlements.
12. European Union (2022), ‘Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector’. EUR-Lex.
13. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 14 and 15. EUR-Lex.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.