Run the engagement as a learning loop with explicit release gates

TL;DR: Revisit scope and design as evidence arrives, while keeping evaluation, permissions and operational readiness ahead of release. Feed useful patterns into shared capabilities when the demand, maintenance and cost case support doing so.

Where you are. You have mapped the last-mile work and the roles that collaborate on it. This lesson gives the rest of Foundations a working structure and a small planning exercise you can run before learning the implementation details.

Use the loop as a set of questions

The diagram keeps eight activities visible. It is not a mandatory chronological deployment plan. In particular, identity, integration and security cannot wait until after a production release simply because “integrate” appears later in the drawing. Those checks begin during discovery and must meet their release conditions before affected use.

Evaluation is part of the specification, especially for probabilistic behavior. It does not replace deterministic requirements such as permission enforcement, valid state transitions and recovery. A human review step can reduce some risks, but it needs defined scope, information and capacity; its mere presence is not release approval.

Samples and prototypes can produce useful evidence about limited questions. State which questions they answer and which require the target environment or a representative evaluation. Production data is not the default testing material when a safer approved fixture can answer the question.

Follow one change around the loop

In this synthetic freight pilot, the initial request is “summarize every exception.” Observation shows operators first need to identify the shipment and find the applicable contract. The proposal becomes a domestic read-only decision aid for a defined set of records, with uncertain matches routed to manual review.

The team agrees its eligible cases and quality checks before implementation. Integration testing then shows that some contract reads do not preserve the caller's scope. That finding sends the team back to the design and release decision. It is not an issue to observe casually after rollout.

After the access path is corrected and verified under the responsible process, a bounded release may proceed if the other required checks pass. Later observation reveals that operators spend more time verifying summaries for multi-leg shipments. If those were excluded, record whether any entered the workflow unexpectedly; if included, investigate the failed segment and revisit the scope. Do not quietly remove inconvenient cases from the success report.

A release can be paused, reduced or reversed where the evidence and authority require it. Iteration is not a promise that every problem will yield to one more prompt change. Agree the time, cost and evidence that would justify continuing before the experiment becomes indefinite.

Distinguish repetition from a reuse case

A recurring need is a reason to investigate a shared component. It does not prove that the third similar implementation is the correct moment to generalize. Three customers may use similarly named fields with different semantics, permission models or lifecycle rules.

Compare the stable core and the variation. An adapter might share parsing, validation and checkpoint machinery while leaving customer-specific mapping and credentials in configuration. Shared behavior needs tests across the supported contracts, migration planning for existing users and an owner who can maintain it.

Reusable work can serve the current customer too: a supported connector may reduce their maintenance burden. Conversely, a one-off integration may be appropriate when demand is narrow and a general framework would cost more than it saves. The decision is not a moral ranking of software and services.

Calculate a small reuse decision

This synthetic estimate compares engineering hours across future deployments. Bespoke work takes 20 hours per deployment. A shared connector needs 36 hours up front and eight hours per deployment for configuration and verification. Initially ignore maintenance to expose the basic arithmetic, then add it explicitly.

def costs(deployments, shared_maintenance=0):
    if type(deployments) is not int or deployments < 0:
        raise ValueError('Deployment count must be a nonnegative integer')
    if shared_maintenance < 0:
        raise ValueError('Maintenance hours cannot be negative')
    bespoke = 20 * deployments
    shared = 36 + 8 * deployments + shared_maintenance
    return bespoke, shared

for count in range(1, 6):
    print(count, costs(count), costs(count, shared_maintenance=12))
assert costs(3) == (60, 60)
assert costs(4) == (80, 68)
assert costs(4, 12) == (80, 80)
assert costs(5, 12) == (100, 88)
# 1 (20, 44) (20, 56)
# 2 (40, 52) (40, 64)
# 3 (60, 60) (60, 72)
# 4 (80, 68) (80, 80)
# 5 (100, 76) (100, 88)

Without the added maintenance estimate, three deployments tie and the fourth saves 12 hours. With 12 extra maintenance hours over the same planning horizon, four tie and the fifth saves 12. The estimates do not establish that five customers will arrive or that shared behavior will fit them.

These are engineering-hour comparisons, not profit estimates. A real decision may also include support, opportunity cost, migration, reliability, licensing and strategic value. Add comparable costs to both options and avoid counting already-spent effort as a future saving. A component that saves setup time but centralizes a risky failure mode needs a reliability review as well.

Decide who carries the learning forward

A reuse proposal should name the repeated need, source evidence, stable interface, supported variations, expected demand, estimated costs, migration and maintenance owner. Coordinate with the product team rather than assuming the field engineer can add every useful abstraction to the shared platform.

Sometimes the right output is better documentation, a deployment template, a test fixture or a clearly documented unsupported case. Product learning is broader than a new feature. It should help future decisions without leaking customer data or preserving an accidental workaround as the product contract.

After a pilot, record what changed in the workflow and what remains uncertain. A clean handover can coexist with future iteration under a new owner; the original engineer need not stay indefinitely to keep the loop alive.

Do this before moving on

Run the cost fixture. Change shared setup from 36 to 60 hours while retaining eight hours per deployment and 12 maintenance hours. Six deployments tie at 120 hours; shared becomes cheaper at seven, assuming the same inputs. Explain why counting occurrences alone misses that change.

Write one row per loop activity for the supplied pilot. Put the caller-scope failure before any affected production release. For the observed verification burden, identify the metric, segment and next test rather than merely proposing to “improve the model.”

Then draft a reuse proposal for the adapter. List the shared behavior, two customer-specific variations, a test for each, the expected deployment count and who maintains it. It passes when the scope and arithmetic are explicit and the unknown demand is still described as unknown.

Go deeper

• AI cost and unit economics puts numbers on whether a deployment pays for itself, which is the question the productize stage has to answer.
• Scoping ambiguous problems covers the second stage, where the scope must match the available evidence and constraints.
• RAG pipeline end to end walks the ship stage for the most common AI deployment shape.
• Taking a RAG proof of concept to production scale is the integrate stage as an interview question, with the operating checks a release needs.
• What a Forward Deployed Engineer actually does puts the same loop next to a representative week.

Key takeaways

• The loop revisits decisions as evidence arrives; it is not a release sequence that postpones controls.
• Evaluation complements permissions, deterministic contracts and operational requirements.
• Observation must include failed, unfinished and difficult work.
• Reuse depends on stable behavior, demand, costs and maintenance, not an automatic third occurrence.
• Carry learning into shared code, tests or documentation under an accepted owner.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1The drawing places integrate after ship. May caller-scope enforcement wait until after production release?

   Yes, the loop fixes it laterNo; required integration and access checks precede affected useYes, if there is a human reviewer

2. 2With 36 setup hours, eight per deployment and 12 maintenance hours, when does the shared option first become cheaper than 20 hours per deployment?

   The third deploymentThe fourth deploymentThe fifth deployment

3. 3Three adapters look similar. What should you check before generalizing?

   Answer it, then reveal