Stay with the problem until the workflow works.

The failure pattern is consistent: a model performs well on a curated example, the demo impresses the room, and then the work stalls at the boundaries. Real authentication, messy data, a user who does not behave like the script, systems nobody documented: the demo touched none of it.

Forward-deployed work starts at the boundaries instead. I sit where the work happens, learn the environment the change has to survive in, and make a small change that survives it. Then the next one. The method follows the same steps each time, on purpose.

Every engagement opens with a written discovery record, not a proposal. Seventeen fields, every one mandatory: the business trigger that makes this worth doing now. The observable outcome, split into what the system can directly cause versus what it can only influence, because I promise the first and not the second. Who the parties are: users, buyers, operators, and the people affected who never touch the software. How the work gets done today, including the spreadsheets and workarounds nobody mentions in meetings.

Then the harder half: which systems are canonical sources of truth for each kind of data. Who may see and do what across each trust boundary. The specific decisions the system must support, who makes them, and what a wrong answer costs, written as a consequence table with a price on false positive, false negative, omission, delay, and stale data. The one end-to-end path that must demonstrably work. The explicit no-gos. And the proof each claim will require.

Where evidence is absent, the record says so. Every unknown gets labeled a question or a recorded assumption with an owner. What it never gets is an invented answer, because a model that manufactures customer truth produces a plan nobody can check.

The request that arrives is rarely the change that matters. Before scope is discussed, the discovery record has to survive a set of hostile questions asked in writing:

• Are we solving a real workflow failure or an elegant abstraction?
• What would make the user not adopt this even if it works?
• What can stay manual for the first field deployment?
• Where could a model silently corrupt state or invent evidence?
• Does the implementer have a way to falsely declare success?
• What is the fastest field test that could disprove the design?

Only after those answers does the outcome get stated in the customer's terms, with the promises explicitly not made written down beside it. The owner signs a plain-language description of success. That signature is the gate: nobody builds toward a success nobody agreed on.

The first change is not the smallest feature. It is the smallest change that exercises the riskiest assumption end to end: real input, a real decision, a real consequence. If the riskiest part of the plan does not survive contact with the environment, better to learn that in week two than month five.

The slice gets a named owner, explicit failure paths, review points, and a definition of done agreed before implementation begins. No large dependency graph gets built before the first slice has delivered through every gate, unless the risk evidence says otherwise.

I stay hands-on through implementation. Business logic owns its own interfaces; providers, databases, and model SDKs live in adapters at the edge of the system, so the customer's workflow never inherits a vendor's vocabulary. Every outward call carries its deadline, retry classification, and degraded mode, and recovery paths get tested rather than asserted.

For AI work specifically, model output is bounded: typed input, a structured output schema, eval fixtures including adversarial cases, a cost and latency budget, and a deterministic validator standing between the model and anything it could change. Model output never becomes system state on its own say-so.

Behavior changes begin with a failing test. Where a material decision is uncertain, research comes before invention and sources rank: observed local reality first, then project authority, then upstream documentation, then proven prior art, then a controlled experiment. Model memory ranks last; it can propose hypotheses and never justify a decision on its own.

Two rules keep proving honest. A custom implementation of something with mature prior art must document why the alternatives failed. And after two failed attempts at the same problem, patching stops: the next legal move is a written diagnosis with a root cause, not a third guess.

A technically live feature its users do not use is not complete. After delivery I keep a field record: activation, completion, time-to-value, confusion and help events, adoption, operator interventions, failures, unit cost, and the downstream outcomes the change was bought to move.

If the field contradicts the plan, the plan updates. Production evidence can reopen any earlier chapter, and the discovery record, not memory or rank, decides what happens next. What the field teaches feeds the next round of understanding, which is why this is a loop and not a line.