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.

The loop as a set of questions

The diagram keeps eight activities in view and puts integration ahead of the affected production release. Its arrows are dependencies to revisit, not a one-way project plan. Identity, integration and security questions start during discovery, and their required checks must pass before use. Evaluation criteria are defined early and exercised again against the integrated revision. A failed check returns the team to the relevant assumption, design or scope decision.

Evaluation is part of the specification, especially for probabilistic behavior, but 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, so say 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.

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, meaning the request ran with the service's own broader credential instead of the permissions of the person asking. That finding sends the team back to the design and release decision; it is not something to watch 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 shows operators spending 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, and iterating is no 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.

Repetition is not yet a reuse case

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

Compare the stable core with 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, since a supported connector may reduce their maintenance burden. A one-off integration, on the other hand, may be the right call when demand is narrow and a general framework would cost more than it saves. The decision is not a moral ranking of software against services.

A small reuse decision, calculated

This synthetic estimate compares engineering hours across future deployments. Bespoke work takes 20 hours per deployment, while a shared connector needs 36 hours up front and eight hours per deployment for configuration and verification. Leave maintenance out at first so the basic arithmetic is visible, 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 tie is where the two lines cross: 20 hours per deployment against 36 up front plus 8 per deployment, so 20d = 36 + 8d and d = 3. Every deployment past the tie saves the difference in the per-deployment rates, 20 minus 8, which is why the saving is 12 hours each time. Adding 12 maintenance hours moves the up-front figure to 48 and the crossing to d = 4, and raising setup to 60 in the exercise moves it to 6. 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, and 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.

When the current commitment calls for a one-off

Apply the same synthetic cost estimates to an actual scheduling choice. One deployment is funded and due next week, and four other organizations have expressed interest without any of them committing. The engineer has 28 working hours available next week; eight are already committed to unrelated customer work. The estimates above cover implementation, configuration and verification for the proposed connector scope. For this exercise, both approaches are technically acceptable if the required checks pass, and the one-off has an accepted support owner. Those conditions would need evidence in a real engagement.

Write a recommendation that separates next week's capacity from the longer planning horizon. There are 20 hours available for this deployment: 28 minus eight. Bespoke work uses exactly those 20 hours. The shared option needs 44 hours before its first deployment, 36 of setup plus eight of configuration and verification, which is 24 hours more than the project has. Neither prospective demand nor a future saving supplies those hours next week.

The eight hours of unrelated work are already deducted from capacity; do not add them again to the connector's cost. The 12 shared-maintenance hours belong to the longer comparison, not the first-week implementation estimate. They represent additional shared-component maintenance in this fixture. If either option has other support costs, include them on a comparable basis before using the totals for a real decision.

A worked recommendation chooses the bounded one-off for the funded delivery, records the interface and tests that might be reusable, and schedules a separate reuse review when demand and ownership are clearer. That serves an important current customer without committing to a general platform. State that the 20-hour estimate leaves no spare project capacity; an overrun needs a scope, staffing or date decision, not invisible overtime. Do not quietly consume the other customer's eight hours.

Changed input: all five deployments become funded, a shared maintainer accepts the stated scope, and the first deadline moves to allow 52 total working hours before it. Eight hours stay reserved for unrelated work, which leaves 44 for the shared first deployment, so it now fits the estimate exactly, and the full-horizon comparison favors shared work by 12 hours. Revise your recommendation if the contracts really share the assumed behavior. What changed the choice was demand and time, not repetition. The revised plan still has no spare capacity at its first milestone.

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, because 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.