# Choose the first slice for what it teaches you

> Compare possible starting points for a new application by the uncertainty they resolve, the useful software they leave behind and the next engineering decision their results can support.

Paper: 06.2
Published: 2026-11-09
Canonical: https://harten.io/papers/06-2-choose-the-first-slice-for-what-it-teaches-you/

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/06-2-choose-the-first-slice-for-what-it-teaches-you.jpg?v=660b33ab9607). Illustrative cover artwork, not an application screenshot or a record of measured results.

## What This Paper Examines

The first work in a modernisation programme should examine an important assumption about the replacement and leave something the later work can use. Here, a slice means a bounded piece of engineering work, not necessarily a separate service or production release. This paper compares three starting points in an illustrative payments service: reference data, a payment decision in isolation and a narrow end-to-end payment path. For the circumstances described, I would choose the end-to-end path as the first completed slice. The platform is familiar, while a correct calculation alone would not establish that operational holds prevent an inappropriate settlement request. The paper explains why connecting that path is worth the additional work, how engineers can use AI to build and examine it, and what subsequent teams can reuse without mistaking the result for permission to operate live payments.

## Three Possible Starting Points for the Payments Application

Imagine the team has agreed to build a new payments application. It understands the intended outcomes and has a candidate design, but several questions remain. The application must recognise operational holds, use current account information, explain decisions to staff and interact correctly with settlement. The engineers also need a reliable way to build, deploy and observe it in the chosen environment.

There are at least three credible first pieces of work. The team could implement a read-only reference-data capability, such as an endpoint returning the supported payment types and their descriptions, and use it to establish deployment, identity and monitoring. It could implement the payment decision and compare its results with approved examples and selected historical cases. Or it could build a narrow path through the new application, from receipt of an instruction to an explained decision and a controlled settlement response.

Each can be described as a small slice, but the word does not tell us which is the right starting point. The reference-data work is not automatically trivial, and the end-to-end path is not automatically more valuable. Their relative value depends on the question the programme most needs to answer before committing further effort.

In [A small code change can have a large consequence](https://harten.io/papers/06-1-a-small-code-change-can-have-a-large-consequence/), we followed a validation result through operational holds, shared state and downstream consumers. That investigation helped establish the scope of the change. The next decision is how to turn that understanding into useful engineering work, rather than choosing whichever component is easiest to mark complete.

For this example, the team already has a familiar deployment and operating environment. What remains uncertain is whether the proposed payment inputs, recorded state and receiving components work together correctly when an operator intervenes. I would therefore choose the third option as the first completed slice. The decision function is part of that work and may be implemented first, but its local correctness is not the acceptance boundary. The slice is complete only when the selected behaviour has been demonstrated through the connected path. The following comparison explains what the other two options contribute and why I would not stop at either of them here.

![Three alternative starting points for an illustrative payments application. Read-only reference data examines deployment and operation. The payment decision in isolation examines inputs and agreed outcomes. The narrow end-to-end payment path is recommended for this example because it also examines the interactions between assessment, recorded state, operations and a controlled settlement receiver. The decision is built within that slice, not treated as its completed outcome.](/assets/papers/06-2-comparing-first-pieces-of-work.svg)

*Figure 1. The narrow end-to-end payment path is the recommended first completed slice for this example. Reference-data work would leave the main payment questions unanswered, while the decision in isolation would not establish how its result is used. The decision can be built first within the chosen path. These are not compulsory stages, and completing this slice does not authorise live payments.* [View the diagram at full size](https://harten.io/assets/papers/06-2-comparing-first-pieces-of-work.svg).

## The Assumption to Test Before Building More Workflows

I would begin by identifying the next commitment that would be expensive to reverse. Perhaps the team is about to build several workflows around a proposed distinction between accepted and settled payments. Perhaps it intends to use a data feed whose timing has not been established. Perhaps the target environment has restrictions that could alter the design. These are different uncertainties and should produce different first tasks.

An agent can help prepare this comparison before implementation begins. Given the approved requirements, current source and available test results, it can identify which dependencies each proposed task would exercise and which important questions it would leave unanswered. The engineer should be able to follow those conclusions back to the material inspected. A recommendation made without access to production configuration is different from one supported by a deployment the team has already reproduced. This gives the engineer something concrete to challenge, rather than asking an agent to choose the first task from component names alone.

For our example, suppose the platform arrangements are already familiar, but the team does not know whether the new decision path can operate from an explicit set of inputs without quietly reading additional legacy state. If that assumption is wrong, the candidate interface is incomplete and several later components will be built against the wrong contract. A further demonstration of basic deployment would not resolve that issue.

The decision implementation within the end-to-end slice would let the team begin examining that assumption. It could require every assessment to identify the account information, operational hold state and rule version it used. Engineers would then exercise the conditions that might reveal missing inputs. Recording those inputs explains a calculation; it does not, by itself, prevent an earlier result from authorising a payment after the hold state has changed. The connected path must examine how the receiving component uses that result and whether a settlement request is prevented. Its result would support a concrete decision: whether to keep the proposed contract or change it before developing the remaining workflows around it.

The shared daily account limit identified in 06.1 also belongs in this discussion. Where that limit affects the decision, the contract needs to account for the authoritative account position, including activity handled by either application. The first exercise may concentrate on one instruction and its hold, but that does not demonstrate that concurrent instructions respect the shared limit. The team should retain that dependency and the required concurrency check explicitly in the remaining work, rather than lose them when it narrows the first task.

That makes success more specific than a demonstration running without errors. A successful investigation can reveal that a proposed contract is inadequate, provided it supplies enough evidence to improve the design. That does not make the incomplete implementation ready for use. Equally, discovering interesting details without resolving the question or producing a usable result is not enough. The scope needs to say what the team intends to establish and how it will recognise that outcome.

## When Reference Data Is the Right First Choice

A reference-data capability can be a very sensible place to begin. Suppose this is the team's first use of the target environment and it needs to establish how a service obtains identity, reads configuration, is deployed and is diagnosed when something fails. The payment-type endpoint is modest, but it still needs those arrangements to work. A bounded read-only capability can exercise them while limiting its effect on the live payments service.

The output should then be more than a successful response from an endpoint. Another engineer should be able to reproduce the deployment, identify the running version and investigate a deliberately introduced failure. The team should know which parts of the deployment and monitoring approach can be reused and which are specific to the reference-data workload. That is useful implementation and operational knowledge for the replacement.

An agent could prepare the deployment configuration, implement the endpoint and add a check for an unavailable dependency. The engineer can then examine the actual deployment and failure response. The distinction matters when the generated configuration looks plausible but has not been exercised under the target environment's identity or network restrictions. The useful result is the working arrangement and the evidence from using it, not merely the files the agent produced.

There are limits to what it proves. A read-only service does not establish that the payment application can enforce a hold during concurrent updates, reconcile an uncertain settlement instruction or support staff handling exceptions. Those questions remain separate. Completing the platform exercise should make them easier to investigate, not become a substitute for investigating them.

Conversely, where the platform is already proven for the relevant conditions, selecting reference data simply because it is easy can defer the real design problem. I would ask what uncertainty remains after the task and why that is acceptable at this point in the programme. In our example, the team would still need to establish whether a changing hold is respected when the payment decision is used. That is why I would not choose the reference-data endpoint as the first slice here. It would demonstrate a capability the team already understands without answering the question that could change the payment design.

## Comparing the Payment Decision With Agreed and Historical Cases

The second option is to implement the candidate payment decision and exercise it outside live authority. This is useful when the uncertainty concerns rules, input completeness or the explanation of a result. The team can begin with approved examples, then use suitable historical cases where access and permitted use have been established.

Historical comparison needs care. An account's current status may not be the status that existed when a payment was assessed. An operational hold may have been added or removed later, and a policy may have changed. Replaying yesterday's instruction against today's data can create a difference that says little about whether either implementation handled the original situation correctly.

The comparison therefore needs an account of the inputs applicable to the original decision, including material timing and version information. Where that account cannot be reconstructed, the team should mark the case as limited evidence rather than invent the missing values. The lack of a reliable snapshot may itself be a useful finding about what the new application needs to retain.

This is useful work to delegate in parts. An agent can assemble the comparison harness, associate results with their input versions and group cases that appear to have the same cause. For example, it might identify a group in which the old application recorded a hold but the candidate received no hold information. That gives the engineer a specific discrepancy to investigate. The proposed grouping still needs checking against the individual records, and the agent must not fill missing history with plausible values just to make the comparison run.

Suppose the comparison reveals that the candidate approves an instruction the old application held. The team should first establish why. The candidate may have ignored an authorised intervention. The old application may have applied a rule the organisation has deliberately retired. The two runs may have used different inputs. Or the intended behaviour may still require a decision from the service owner. Grouping all four under a single mismatch count would obscure the work needed to proceed.

This is where [How to prove the new system still behaves as required](https://harten.io/papers/04-3-how-to-prove-the-new-system-still-behaves-as-required/) provides the earlier foundation. The existing system is useful evidence about behaviour, not an unquestionable definition of what the replacement must do. In Series 06, the planning question is which differences must be resolved before the next implementation or release decision can sensibly be made.

I would retain this comparison work within the selected end-to-end slice, but I would not accept the decision function alone as the completed result. It could produce the required answer from a complete set of inputs while a receiving component still acted on it after a hold had changed. Examining the calculation cannot establish whether the application prevents that later action. The wider path is needed because the unanswered question concerns how the result is used, not only how it is calculated.

## Comparing Live Inputs Without Giving the Replacement Control

Where appropriate and permitted, the candidate can later receive copies of live inputs while the established application remains authoritative. This can expose current data shapes, operating patterns and dependencies that were absent from the selected historical cases. It can also give operations real examples to examine without allowing the candidate decision to release payments.

That arrangement needs to be genuinely non-authoritative. The candidate must not issue settlement instructions, modify the live decision record or send customer notifications. Its use of shared resources also needs limits. A comparison that overloads a database or exposes sensitive information in an unrestricted log has introduced consequences even though its decision result is ignored.

The observations have a defined scope. A shadow run can provide evidence about the inputs received and decisions calculated under those conditions. It does not automatically reproduce contention over authoritative writes, the behaviour of the live settlement integration or the workload operators will face after transfer. A result that never reaches a customer cannot establish whether the actual customer journey works.

Sampling matters as well. A comparison dominated by ordinary instructions may contain few operational holds, retries or delayed responses. The team should deliberately exercise the important rare conditions in controlled tests rather than wait indefinitely for them to occur naturally. It can then use live comparison for the questions that real traffic is well suited to answer.

The result should make those distinctions visible. A high agreement rate might be useful, but it is not a release decision by itself. An unexplained difference in a consequential hold condition may matter more than many harmless differences in formatting. The team needs the cause, the consequence and the authorised treatment, not just a reassuring aggregate.

## An End-to-End Path Through the Replacement

The third option is a narrow but complete path through the new application. An instruction is received, its input is validated, a decision is recorded, an operator can inspect the explanation and a controlled downstream response is handled. This is the first completed slice I would choose for our example because the important uncertainty concerns those interactions rather than the logic of the calculation alone.

The path can be built inside a completely new application. It does not require an adapter to reproduce every legacy component, and it does not mean the finished architecture must consist of separate services. The team is choosing a manageable scope of behaviour to implement and examine, not allowing the old repository structure to determine the new design.

The boundaries of the exercise must still be explicit. A controlled settlement response can help establish how the application handles acceptance, rejection and uncertainty. It cannot establish that the real external system behaves as the simulation assumes. That integration remains a distinct piece of work, with its own contract and evidence. The simulation should be designed to challenge the application, rather than always return the response that makes the demonstration succeed.

For the operational-hold example, the path should include a hold arriving during assessment, the resulting decision and the explanation visible to staff. An ordinary happy-path payment alone would omit the very interaction that justified the exercise. The purpose of keeping the scope narrow is to make a meaningful behaviour manageable, not to remove every condition that might expose a design problem.

An engineer could ask an agent to build a test that pauses after the assessment has read its inputs, records the hold, then allows the assessment to finish. The test should observe both the resulting instruction state and whether any request reached the controlled settlement receiver. Checking only that the hold flag remains set would miss an application that retained the flag but still sent the payment. Operations can review whether the explanation makes the outcome understandable. The agent undertakes the implementation and repeated execution; the engineer checks that the test actually exercises the agreed requirement.

Connecting the path takes more work than testing the decision in isolation. In return, it lets the team examine whether the result reaches the right consumer, whether a later intervention prevents settlement and whether the explanation available to staff matches the recorded outcome. Those are questions that a working reference-data endpoint or a matching set of calculated results would leave unanswered. I would accept the additional integration work here because the later payment workflows will depend on these same relationships. A defect found now can change the contract before that contract is used throughout the replacement.

This approach can leave useful software behind even when it changes the plan. If the first implementation reveals that staff cannot determine why a payment is held, the team can revise the explanation and retained information before repeating the same design across further workflows. The next piece of work starts from a better application, not merely from a document saying the first experiment was informative.

## Revising the Payment Contract After a Failed Hold Test

To follow the example through, suppose the first controlled exercise exposes a flaw in the proposed contract. The assessment receives the ordinary validation information and the hold state as they existed when processing began. Its response contains a positive result, but nothing that allows the receiving component to establish whether the relevant state has changed since those inputs were read. The controlled settlement receiver records a request even though the operator's hold is now active. The test has identified a particular failure, rather than merely producing a mismatch count.

The engineer traces the result to that gap and revises the contract before other workflows are built around it. In this version of the design, the assessment carries a state version that changes when the hold changes. The component accepting permission to release checks that version against authoritative state as part of the same atomic operation that records its decision. A hold recorded before that operation therefore causes the earlier result to be rejected. The engineer also specifies the explanation operations should see when an assessment has been superseded. This is one possible design for the illustrative service, not a requirement that every application use the same mechanism.

The agent updates the implementation and the controlled test. The team reruns the ordinary case and the interrupted assessment, checking both the recorded state and the settlement receiver. In the revised example, the held instruction remains held, no settlement request is issued for it and the operator can see why the earlier assessment was not used. The input contract, implementation and repeatable checks now give the next team something usable. The separate checks for concurrent instructions against the shared account limit and for the real settlement integration remain identified. The first slice has changed a design decision before that decision was repeated throughout the replacement.

## Accepting the First Implementation Without Approving Live Payments

Before beginning, I would write down the decision the work is intended to support. In this case, it is whether the proposed contract and connected handling of an instruction are adequate to use as the starting point for further payment workflows. Acceptance would cover a defined payment category through receipt, assessment, the recorded decision, the operational explanation and the controlled settlement receiver. The team should be able to identify the required information, reproduce an assessment, explain material differences and demonstrate that an operational hold prevents a settlement request under the selected timing conditions. A passing set of tests for the decision function is an intermediate result, not completion of that scope.

Those are acceptance conditions for a bounded engineering result. They are not permission to operate every payment category. Live responsibility would require the relevant integration, operational and recovery evidence as well. Keeping the claims separate avoids two opposite mistakes: treating an experiment as proof of the whole application, or refusing to acknowledge useful completed work because the whole application is not yet ready.

The investigation also needs a stopping point. If the available evidence supports the stated decision, the team should proceed rather than add unrelated questions to make the result feel more complete. If a material uncertainty remains, it should state what is missing and which next action is likely to resolve it. That could be a targeted operational review, a specific integration test or a revision to the proposed design.

DORA's [small-batch guidance](https://dora.dev/capabilities/working-in-small-batches/) emphasises shortening the feedback cycle and avoiding the regrouping of completed work into large downstream batches. For our replacement, the implication is to examine the meaningful result while it can still change the plan. Completing several isolated components and leaving their combined behaviour untested would lose much of the value of the smaller work packages.

## What the Next Team Should Be Able to Reuse

A good first result leaves a practical starting point for later work. In the payments example, that could include the agreed input contract, a set of representative cases, the reasons for resolving important differences and a working way to reproduce a decision. The operational explanation and deployment path may also be reusable. Each item should retain enough context to show where it applies.

Suppose the next roadmap item adds another payment category with different eligibility rules but the same requirements for operational holds and staff explanations. Its team can begin with the connected implementation, adapt the decision rules and extend the cases instead of rediscovering how to carry a result through to the settlement boundary. It can also reuse the way the first team assigned bounded work to an agent, constructed the controlled timing test and inspected the returned evidence. The first slice has then contributed to a required capability and to the team's ability to deliver the next one. Any reduction in delivery time still needs to be observed; reuse alone does not establish a measured acceleration.

That context matters because reuse can transfer a mistake as efficiently as it transfers useful work. A test fixture based on a retired rule should not silently become the default for a new payment category. A successful load check for one pattern should not be presented as evidence for every workload. Engineers need to know which assumptions a later change preserves and which it invalidates.

The result should update the existing requirements and engineering records, not create another disconnected folder of conclusions. A resolved question about a hold belongs with the requirement and its verification cases. An unexpected dependency belongs with the relevant interface or application knowledge. A design decision should retain the reason it was made, so another engineer can recognise when the circumstances have changed.

This is the continuing responsibility developed in [How to build a new application and keep it evergreen](https://harten.io/papers/05-3-the-route-to-the-target-is-part-of-the-architecture/). The first piece of work should begin the maintenance of that knowledge. It should not produce a one-off proof of concept whose useful findings disappear when the demonstration ends.

## The Engineer's Review of Agent-Assisted Work

Across these starting points, AI assistance can help the team investigate more than the simplest demonstration. The agent can prepare working code, construct a controlled execution, organise comparisons and retain the source and results needed to repeat the work. That can make a meaningful first piece of engineering more practical. The benefit depends on whether those outputs answer the question the team set, not on how many alternatives the agent generates.

The engineer's review should concentrate on the relationship between that question and the work performed. Did the test place the hold after the inputs were read? Did it check that settlement was prevented, rather than only that a status looked correct? Were the historical cases run with the relevant input versions? A passing suite does not answer those questions unless its design actually covers them. The expected outcomes should come from the approved requirement and reviewed cases, not from the candidate implementation's own behaviour.

The service owner has a different decision to make when an investigation exposes an unresolved business rule. Operations may need to explain the exceptions and whether the proposed response is workable. An agent can assemble the evidence and propose a treatment, but a missing decision should remain visible rather than becoming whatever behaviour was easiest to implement. Once the requirement and task limits are settled, the agent can continue routine implementation and testing without a human approving every edit.

There is also a temptation to let the agent continue expanding the experiment because generating another variant is easy. The work should stop when it has supplied the evidence required for the stated decision, or when a specific unresolved issue prevents it from doing so. More generated code and more test cases are useful only when they add relevant information or complete the intended capability.

The agent's report should make the result inspectable: what was implemented, what was executed, what happened and which conclusions follow. It should not turn a proposed check into a completed one or describe agreement with another agent as independent verification. The team can then accept the demonstrated result for its stated scope and separately decide whether the next task or an increase in live responsibility is justified.

## Why I Would Choose the End-to-End Payment Path

For the application described here, I would choose the narrow end-to-end payment path as the first completed slice. I would limit it to a defined payment category, but follow that instruction from receipt through assessment, the recorded decision and the explanation available to operations, ending at a controlled settlement receiver. The team might implement the decision function first, but I would treat that as an intermediate step within the slice rather than its completed outcome.

I would not begin with the reference-data endpoint in these circumstances because the team already understands how to deploy and operate software in the target environment. That work would leave the main uncertainty unresolved. I would also not stop at the decision function. It could return the expected answer for every selected case while the surrounding application still acted on an outdated result or gave operations an explanation they could not use. Those interactions are part of what we need to examine before building further workflows around the proposed design.

The end-to-end path lets us investigate them together. We can establish which inputs the decision actually needs, whether a hold recorded during assessment prevents the instruction from proceeding, and whether the stored state and operational explanation describe what happened. In the worked example, observing the settlement receiver reveals a failure that checking the hold flag alone would have missed. The team then revises the contract before other workflows depend on it. That is why I would accept the additional work of connecting the path: it examines a consequential assumption while changing the design is still relatively contained.

The result should also make subsequent delivery easier. The next team can start with a working implementation, an explicit contract and repeatable checks, rather than recreate the same investigation. Engineers can reuse the way they gave an agent the task, constructed the controlled execution and reviewed the returned evidence, while checking which requirements differ for the next payment category. The shared account-limit concurrency checks and real settlement integration remain separate work; completing this slice does not imply that either has been verified.

I would therefore choose this path because it develops useful software and answers questions that later work depends on. It is not the right starting point merely because it touches more components. It is the right starting point for this example because the important uncertainty lies in how those components work together.

The final question in this series follows from that progress. Once the new application is allowed to change authoritative records or issue external instructions, what must happen when something goes wrong? **06.3, Planning recovery before a new application changes live data**, examines that responsibility and the evidence needed before the programme crosses it.

---

*Editorial clarification, 9 November 2026: the opening, comparison, acceptance conditions, figure and conclusion now identify the narrow end-to-end payment path as the recommended first completed slice for this example. Implementing the payment decision first is an intermediate step within that slice. The revision makes the comparative reasoning and reusable result explicit; it does not report new empirical findings.*

*The payments service, candidate starting points and worked outcomes are illustrative. The contract revision is a hypothetical continuation of the example, not a report of a Harten implementation or test run. No historical replay, live shadow run or measured comparison is claimed. External references are attributed where used; the choice of first work is the author's recommendation for the stated example.*

*This paper is part of The Modernisation Control Papers, the first major sequence within The Harten Papers. [Read the complete series on harten.io](https://harten.io/papers/).*