Architecture should be a consequence of evidence

Imagine a modernisation team presenting the target architecture for an ageing eligibility service. The current application has served the organisation for years, and everybody agrees it needs to become easier to change and maintain. The proposed design looks entirely reasonable. The application will be divided into six services, with separate components for case intake, rules, evidence, decisions, reporting and operations. Each will have clearer interfaces, its own deployment process and, where appropriate, its own data.

The diagram answers many of the questions people have been asking. The platform team can estimate infrastructure, delivery teams can discuss responsibilities and suppliers have something tangible to price. The intention is sensible too. Nobody wants a small policy change to require a coordinated release of an entire ageing application. Yet when somebody follows one household-income rule through the existing system, the proposed boundaries begin to look less certain.

The initial six-service proposal, before investigating where the business rules and operational dependencies actually sit.

This is where I want to begin Series 05. In Series 04, I explored how to establish the behaviour a replacement must preserve and how to verify that it actually does so. Once those decisions are made, the natural question is what the replacement should look like. The difficulty is that a target architecture can be technically credible and still divide the system in ways that make the required behaviour harder to deliver.

The eligibility service in this paper is an illustrative example, but the design problem is familiar. A diagram describes the arrangement we would like to build. It does not, by itself, establish whether the organisation can operate the resulting system or whether we have understood what must happen when a business rule changes.

The Household-Income Rule Behind the Proposed Rules Service

The modernisation team starts with a straightforward assumption. Household-income eligibility is a business rule, so it should move into the new rules service. The current system has a calculation component, and extracting that code looks like a manageable first step.

Now suppose a policy change is proposed. The income threshold is altered, and the team needs to understand which cases will be affected. It begins with the calculation code, but tracing the actual decision takes it much further. The public application validates some of the income information before a case can be submitted. A stored procedure calculates a derived value used by the main application. A reporting view reads the result from the operational database, while a scheduled process recalculates certain open cases overnight. Operations also has a way to correct cases where evidence arrived late or an earlier value needs to be reconsidered.

For somebody applying for support, those pieces are not six separate services. They determine whether the case can proceed, whether the decision is explained correctly and whether a correction made by an authorised person is reflected in the information other parts of the organisation use.

We could move the calculation into a new service and make every interface technically valid. That would not necessarily solve the problem. If the web application continues applying an old validation rule, a case may never reach the new service. If reporting recalculates the figure independently, the applicant may see one result while a management report shows another. If the overnight job changes an open decision without respecting the new rule's version, the system can become internally inconsistent. If an operations correction has no place in the new design, an important part of how the business reaches its final decision may disappear.

The team now has a different question to answer. It is not simply where to put the calculation. It needs to establish which components take part in one eligibility decision, which information must remain consistent, where an authorised correction is recorded and when downstream consumers can rely on the result. These are things the first architecture diagram did not explain, yet they directly affect whether a proposed boundary will work.

How AI Helps Recover Dependencies Without Deciding the Architecture

This is the sort of investigation where I see a substantial role for AI-assisted engineering. In a large estate, a person can spend days identifying every reference to an income value, following calls between languages and repositories, checking stored procedures and finding the scheduled processing that updates older cases. An agent can search those sources, follow references, propose relationships and assemble a first view of the affected behaviour much more quickly.

The value is not that the agent produces a polished architecture diagram. It is that the team can examine more of the system before committing to a design. Rather than relying on a few familiar modules and somebody's recollection of how they interact, it can inspect the actual calculation, the SQL that reads and writes the value, the paths that consume the result and the places where a change might have consequences. I would want those findings supported by source references so another engineer could check them.

An illustrative discovery and review flow, not Wayfinder's internal architecture.

But I would not ask the agent to decide that the rules service is the right boundary simply because it has traced those code paths. Code shows what the application does and how it does it, but it is not the entire business process. The reason an operations analyst corrects a case may sit in an incident record, a policy decision or the experience of the people carrying out the work. A static dependency trace cannot establish whether shared state must remain transactionally consistent, and a procedure may contain an old workaround that the replacement has deliberately been authorised to remove.

There is another risk when the output becomes very detailed. A diagram with hundreds of nodes, attractive groupings and confident explanations can appear complete even when the evidence is uneven. One inferred relationship may be plausible but unconfirmed. One downstream consumer may be missing because it is outside the repositories examined. A manual correction may not appear in the source at all. I would want the analysis to distinguish what was found, what was inferred and what still needs to be checked.

AI has made it practical to investigate more of an estate before making architectural decisions. We should take advantage of that. The resulting design still needs to respond to the evidence, including the gaps, rather than allowing a model's first interpretation to settle the architecture.

Where the Eligibility Decision Should Remain Together

After investigating the income rule, the team can reconsider the six-service proposal. Some parts may still be appropriate, but they no longer need to be accepted as a package.

Take reporting. It mostly needs information about completed decisions. It does not ordinarily take part in the transaction that makes those decisions, and it may tolerate a short delay before a new outcome becomes available. A defined event or read model could allow reporting to change independently without reading directly from the operational tables. That begins to look like a useful boundary.

Now consider the rules calculation, case state and exception handling. If a decision cannot be considered final until all three agree, splitting them into separately deployed services with separate data introduces another problem. The organisation must then handle messages arriving late, failures between updates, disagreement about which version of a rule applies and recovery when an authorised correction reaches only part of the system.

None of those problems makes distributed architecture inherently wrong. There may be good reasons to accept them, especially if the organisation has independent teams, very different workloads or a need to change certain capabilities frequently. But the extra independence must be valuable enough to justify the coordination and operational responsibility.

For this eligibility service, the evidence may instead support keeping the core decision capability together as a modular application, at least initially. Rules, case state and authorised corrections can have explicit internal ownership without requiring separate network services and distributed transactions. Reporting can be separated because its dependencies are different. Public intake might also become an independent component where its availability and scaling needs justify that separation.

The proposed revision after discovery. Intake and reporting may be separate, while the eligibility decision remains together. These are candidate boundaries, not a final implementation.

The revised design has fewer boxes than the first diagram. It may also be easier to operate, easier to test as a complete decision and safer to change when the next policy revision arrives. Those are the reasons to prefer it, not the fact that a modular design happens to look simpler. The important question is whether each proposed boundary gives the organisation something it can genuinely change and operate independently. I explore that further in 05.1, Find the boundaries the system actually has.

Choosing Between Plausible Designs for the Same Service

Even with a better understanding of the business process, there will usually be several credible designs for the replacement. Evidence helps reject bad assumptions, but it does not automatically choose the architecture. For our eligibility service, a distributed set of independently deployed capabilities and a more cohesive decision application are both possibilities. The former might allow different teams to release changes separately and scale different workloads; the latter could keep eligibility rules, case state and authorised corrections within one reliable decision process.

The point is that we are comparing ways of building a new application. We are not required to take whichever modules the legacy system already has, translate them and connect them together again. The old implementation gives us important evidence, but it does not define the shape of the replacement. This is where I think modernisation can become much more ambitious than incremental code conversion, provided we have recovered enough required behaviour to support the change.

The comparison still needs to be grounded in the organisation's work. How often do the rules need to change independently from the decision process? What should happen when supporting evidence arrives late? Can a decision be completed while a dependency is unavailable? Who is responsible when an applicant receives an incorrect result, and which team has to restore the service? Those questions determine whether more deployment independence is worthwhile or whether it introduces additional work for the same people.

An AI-assisted engineering system can help explore those alternatives, prepare representative interfaces, identify technical dependencies and test difficult failure scenarios. That makes it practical to examine more options before implementation. But a model can only compare evidence and assumptions it has actually received. If operating costs are guessed, business authority is unclear or the operational team has not confirmed how corrections work, a precise-looking recommendation is still incomplete.

For this example, I would provisionally favour a new modular decision capability, with reporting separated and intake designed around its distinct needs. This is a judgement from the coupling we have investigated, not a universal recommendation for every legacy application. The more distributed option should remain visible in the design record, along with the evidence that would justify revisiting it. In 05.2, A target architecture must explain its trade-offs, I go further into those competing choices.

Building a New Application While the Existing Service Continues

By this point, I think the programme should be asking a different question. If we have understood the existing application well enough to describe the behaviour the organisation actually needs, why should the replacement inherit the old architecture? We can design a new application from the agreed future specification, rather than defaulting to moving legacy procedures, tables and interfaces into newer technology.

That is what I mean by a greenfield approach to modernisation. We are not starting without knowledge of the business. Quite the opposite: the new design is informed by the behaviours we recovered from the existing estate, the controls the organisation deliberately chose to preserve, and the operational knowledge that source code cannot fully explain. Greenfield describes the freedom to choose a different implementation, not permission to discard the required behaviour. It also need not mean that every piece of existing software must be thrown away. Where reuse is justified by evidence, cost or risk, the programme can choose it deliberately instead of making it the architectural default.

AI-assisted engineering makes this approach increasingly practical. An agent can help investigate a complex estate, reconstruct candidate specifications, examine design options and implement and test a new application without needing to reproduce the legacy code structure. The danger is that the agent can misunderstand a business rule just as easily as a human team can. The replacement therefore needs independently reviewable requirements, tests based on the approved behaviour and explicit handling of the cases we still do not understand.

The existing eligibility service may nevertheless have to remain in production throughout that work. Applications continue to arrive, cases remain open and staff still need to correct decisions. The new application can be developed in its own environment, exercised against representative cases and, where permitted, compared with results from the old service while the old system remains authoritative. The design can be greenfield even though the operational transition is carefully controlled.

The existing service continues to operate while a differently designed replacement is built and verified. Greenfield does not mean an automatic or immediate cutover.

The decision to move live work to the replacement is separate from the decision about how to build it. Some services may support a single, rehearsed cutover after independent verification. Others may need a period of parallel operation or a phased transfer because historic cases, interfaces and data ownership cannot safely move at once. A staged transition should be a response to actual risk, not an assumption that the new system must be assembled piece by piece from the old one.

Suppose the replacement has a new intake capability, but the legacy service still owns live case records. Giving both systems permission to write directly to the old database would create an unclear ownership boundary. During a limited transition, an adapter that uses the old application's accepted contract may be appropriate; alternatively the new application may remain read-only or operate with representative data until an authorised cutover. Which path makes sense depends on what the organisation can reconcile and recover. An agent may build an adapter or a migration script quickly, but that does not give it authority to change the system of record.

This is why the journey to a greenfield replacement belongs in the architectural decision. We must know which system owns each consequential action, how data and historical cases move, what failure recovery requires and when the old application can actually be retired. These are the questions explored in 05.3, The route to the target is part of the architecture.

The Evidence Behind the Revised Target Architecture

Back in our review, I would want the team to explain why the architecture is different from the original six-service proposal. Not by describing the technology it prefers, but by showing what was learned about the eligibility service.

Reporting is a candidate for separation because it consumes completed decisions and does not participate in the transaction that creates them. Rules, case state and corrections remain together because they currently depend on one consistent outcome and are operated as one decision capability. Public intake has a separate interface because its scaling and availability needs are different. The new system is designed independently of the legacy modules. A temporary adapter may still be required if authority has to move in stages, but it is a transition mechanism rather than a component that defines the target. Each choice has an observable reason and could be challenged if new evidence changes it.

There should also be an account of what we do not know. Perhaps a historic reporting consumer still reads an operational table. Perhaps the reason for one overnight recalculation has not been established. Perhaps the volume of cases requiring manual correction is too uncertain to justify a separate operations service. These questions need owners and a means of resolution; they should not become confident architectural decisions simply because an agent has produced a convincing explanation.

I would want a reviewer to be able to move from an architectural choice back to the behaviour, source evidence, operational dependency and approved requirement that informed it. Where an agent has helped assemble that material, the source and any unresolved interpretation should remain available. That gives the organisation a way to challenge the design without having to trust either the architect's memory or the model's account of the system.

An example of how one architectural decision can be traced back to observed behaviour, an authorised requirement and the tests that challenge it. Any unresolved dependencies remain visible.

The target should also remain open to revision. Building and testing the first components will teach us things that discovery could not establish completely. If the intake boundary proves useful, that strengthens the decision. If splitting a rule creates constant coordination and expensive recovery, that should change our view. An architecture supported by evidence does not have to pretend it can never be wrong.

The broader lesson for AI-assisted engineering is that faster analysis and generation make a sound basis for decisions more valuable, not less. We can investigate more of an estate, explore more alternatives and build a new application around the behaviour the organisation needs, rather than simply converting the old implementation. But if that speed turns an early assumption into a fixed architecture, we can make the wrong decision much more expensive to reverse. The people responsible for the service need enough information to approve what is being built, and the agents carrying out engineering work need a precise account of what they are free to change.

Series 05 follows this work from the boundaries we discover, through the choices we make, to the transfer of responsibility between the old and new applications. The important shift is that modernisation need not start with translating or extracting the legacy implementation. With sufficient evidence and an authorised specification, the team can design a new system and decide separately how to introduce it safely. Series 06 will examine how to organise that change into deliverable steps without assuming every repository or legacy component is a natural unit of work.

---

Editorial note, 15 October 2026: This paper was expanded after its initial publication to explain the greenfield replacement approach, distinguish new-system design from production cutover, and show the evidence behind the revised architectural decision.

This paper uses an illustrative eligibility-service scenario, not a claim about a particular customer application.

This paper is part of The Modernisation Control Papers, the first major sequence within The Harten Papers. Read the complete series on harten.io.