Designing a Thin Vertical Slice to Validate High-Risk Assumptions

Hello! The previous lesson left the support-assistant design with a proposed decision: check approval against the final reply text before the assistant sends it. It also left an important uncertainty. Can that check actually govern the assistant’s send path in the customer’s ticket system?

This final lesson of the planning module turns an uncertainty like that into a thin vertical slice: the smallest end-to-end piece of a solution that can produce credible evidence about a consequential assumption. You’ll learn how to choose the assumption, bound the implementation, and decide what its results do—and do not—justify. Allow about 40 minutes, including the video and readings.

Start with the decision you need to make

A team could spend weeks building a polished drafting interface, a policy index, and an approval database before discovering that its ticket integration cannot enforce the agreed send rule. The costly mistake would not be imperfect code. It would be investing in a design whose critical assumption had never been tested.

Product Pathways’ Introduction to Product Discovery offers a compact method for finding that assumption. Watch its discussion of importance versus evidence, then the opening of its discussion of turning an assumption into a test.

For an FDE, highest risk usually means a belief that is both consequential if false and weakly supported by evidence. Impact, uncertainty, and timing all matter: a question that blocks the next deployment decision deserves earlier attention than one that can safely wait.

Here is an illustrative comparison for the support-assistant pilot—not a claim about what this customer has already confirmed:

This ranking is conditional. If the customer will not permit assistant-initiated sending in the pilot, the first assumption no longer governs that pilot’s design. Re-rank the risks instead of building a send integration merely because it appeared in an earlier proposal.

Turn the chosen belief into a question that an observation could answer:

Assumption: On the intended assistant integration path, a review-required reply can be sent only when its final text matches an authorized approval.
Decision question: Does a controlled test of that path allow an approved, unchanged reply while rejecting an unapproved or edited one?

“Build an approval service” is not a testable assumption; it is a proposed task. “The integration will enforce final-text approval” is a belief that might be wrong. That distinction keeps the experiment aimed at learning rather than completion.

Make it vertical, then make it thin

A horizontal plan finishes a layer—perhaps all ingestion, then all model work, then all API work—before a user-facing workflow runs. A vertical slice carries one narrow workflow through the components it needs. It can reveal integration problems and produce feedback before the rest of the system exists.

Thoughtworks’ Three delivery planning principles for iterating towards the right data product contrasts those approaches and gives a data-product example in which the team selected only the source tables needed for initial value. Read the indicated parts, paying attention to what was included to make the first workflow real and what was deferred.

The image is a planning aid, not a promise that every small end-to-end build is automatically desirable, safe, or ready to release. Vertical describes the shape of the workflow tested. Thin describes the limited cases and capabilities chosen for that test.

For the approval assumption, the slice needs enough of each relevant boundary to observe a genuine outcome:

1. A representative synthetic ticket and reply in an authorized test environment.
2. A way to register test approval for an exact final text—using a temporary test mechanism while production storage and retention remain undecided.
3. An assistant send action that reaches the proposed application check.
4. The intended ticket-system sandbox integration, so the team can observe whether the reply was actually sent.
5. A record of the approval check and sandbox outcome, so a rejected request is not mistaken for a successful safeguard if another route sent it.

That is one narrow workflow, not the full assistant. It need not generate drafts with a model, index all policies, support every ticket category, or build a polished interface. For this assumption, a supplied draft is sufficient: the uncertainty concerns authorization at sending, not draft quality.

A mocked ticket API can help develop the check, but it cannot establish that the real integration path uses it. Conversely, a production-grade approval store is unnecessary—and may be impermissible—just to discover whether the integration can enforce the rule. Include fidelity where the risk lives; simplify elsewhere.

Set the experiment’s boundary before building

The UK Government Service Manual’s How the alpha phase works makes an important distinction: a prototype need not cover an entire journey or use production-quality code, but it should test the challenging assumption. Its integration example is especially pertinent here.

For this pilot, “not production quality” does not mean “try sending customer replies and see what happens.” Obtain permission for the test environment, use synthetic content, keep any test approval state temporary, and do not enable a customer-facing send action. Those are conditions for running a responsible experiment, even when much of its code may be discarded.

A concise slice definition could look like this:

Slice: In an authorized ticket-system sandbox, attempt to send one review-required synthetic reply through the assistant’s intended integration path. Before sending, the application checks whether the final text matches an authorized test approval. Repeat with no approval and with text edited after approval. Record both the application decision and the ticket-system outcome.

In scope: One ticket type, one permitted test approver, one assistant send action, final-text matching, rejection behavior, and observable sandbox results.

Out of scope: Model-generated drafts, live customer tickets, all approval roles, production approval storage, a complete agent interface, and other ticket-system send routes that the assistant does not control.

Dependency: The customer must authorize sandbox access and confirm which assistant-initiated path is intended. Without that access, the experiment cannot validate the integration claim.

The last sentence is as important as the feature list. If sandbox access is unavailable, API documentation review or a mocked test may still uncover problems. Report that as weaker evidence, not as proof that the intended integration enforces approval.

Thinness also has a limit. Omitting the sandbox ticket-system outcome would make this a component test, not an end-to-end test of the chosen assumption. Omitting the edited-text attempt would miss the very condition that motivated the previous lesson’s ADR. Scope cuts are useful only while the remaining path can still answer the decision question.

Specify what counts as evidence—and what happens next

Before implementation, agree on the outcomes that would change the plan. The following are proposed experiment criteria, not customer-approved acceptance criteria:

Check both sides of each negative case. An application returning “rejected” is not enough if the ticket-system log shows a reply was sent. Equally, a missing reply alone does not show that the approval rule worked; the integration might simply have failed. The paired observations help distinguish those explanations.

A short time box—for example, a few authorized engineering days—makes the experiment a decision point rather than an open-ended mini-project. At its end, capture the test conditions, observed outcomes, and limitations:

• Proceed to the next design decision if the intended path behaves as specified under the tested cases and the customer confirms that it is the path the pilot will use. This supports further work; it does not prove that unauthorized sends are impossible in every production condition.
• Revise or reject the proposed architecture if an edited or unapproved reply is sent, or if the intended path bypasses the application check. One alternative is to keep assistant-initiated sending disabled while agents use a separately approved process.
• Keep the assumption open if access, authorization, or observability prevents a meaningful test. A successful mock is useful engineering evidence, but it cannot close the real-integration risk.

The result should feed back into ADR-007. Evidence may justify accepting its proposed service boundary, changing the option, or retaining the risk and gate. A slice has done its job when it makes that choice clearer—even if the code is thrown away.

Conclusion

A thin vertical slice is one narrow, observable end-to-end workflow chosen for what it can teach you. Select a consequential, weakly evidenced assumption; preserve the real boundary where that assumption could fail; simplify unrelated capabilities; and define the observations that would support, overturn, or leave the proposal unresolved. For the support assistant, that means testing final-text approval through the intended sandbox send path, not merely demonstrating that an approval-check function works.

This closes the planning module. The next module begins the implementation work behind such slices: organizing a Python service so its application logic, configuration, and tests can evolve without becoming entangled.