The Applied AI Field Guide

From a real workflow to measurable, operated value.

This is the shared mental model for turning an AI request into a useful, supportable change to real work. It covers discovery, value, engineering, adoption, and operation—whether you work inside the organization or alongside a customer. If a brief is already breaking, start with the five-minute field guide. Come back here when you need the full loop.

The Guide explains the method. The Handbook supports live delivery. The Engineering Kit provides contracts, controls, code, and tests. They are three depths of one method—not separate frameworks.

Reading time: about 15 minutes. This is guidance, not production approval or a substitute for a target organization's policy, security, architecture, or risk review.

1. What the delivery team is responsible for

The team turns an ambiguous operating problem into a supported software service that improves an accepted outcome. That takes several kinds of work:

Applied-AI engineers build and test the behavior. Product and workflow owners decide which work should change. Platform, data, security, and service teams own their boundaries. An FDE connects these responsibilities in an unfamiliar operating environment. Titles vary; record the actual decision rights and missing expertise rather than asking one person to own everything.

The output is an owned change to real work with a verifier, bounded authority, full-cost case, operating team, and exit path.

Tokens are an input. Autonomy is a design choice. Accepted outcomes are the product.

2. The operating loop

The repository uses one canonical lifecycle:

flowchart LR
    A["Inherit the brief"] --> B["Observe and reconcile the work"]
    B --> C["Charter value and scope"]
    C --> D["Make data fit for the decision"]
    D --> E["Select the mechanism"]
    E --> F["Build one controlled slice"]
    F --> G["Prove it with cases and users"]
    G --> H["Launch with operating ownership"]
    H --> I["Operate, learn, or retire"]
    I --> B

Stopping or narrowing weak work is a valid result. A sponsor, model score, renewal, launch, or usage number cannot average away a failed value, authority, safety, ownership, or production gate.

3. Observe the work before designing the system

Monday morning, the sponsor says invoice exceptions should post automatically. By lunch, the queue owner has shown you the approval step and the controls manager has cited the policy that requires it. You haven't found a prompting problem. You've found a boundary the brief got wrong. It makes no difference whether that brief came from sales, a product roadmap, or an internal executive request.

Treat the inherited brief as a hypothesis. Preserve it before improving it. Find the process knower through a recent case and a material exception; compare what was promised or requested with operator practice, system behavior, and policy; then ask the person who actually controls the affected boundary for a scoped decision.

The hard conversation can be plain. On a customer engagement:

We sold automatic posting. The walkthrough and controls policy require approval first. We can still reduce queue time by recommending and staging a correction. Until the service owner accepts, rejects, or defers that narrower path, the manual queue stays in place.

Don't soften the evidence, ask a sponsor to overrule an operating owner, or let silence become approval.

Test the story against the target environment too. Inspect the decision-bearing code or configuration, data and reconciliation seams, identity and permission boundaries, and representative execution or failure evidence. Questionnaires, diagrams, and maturity scores help organize investigation; they don't prove readiness. Missing access stays visible as an unknown or blocker.

Use Field Engagement and Accountable Reframing, the observation log, and the engagement-reframe record. The worked invoice evidence keeps sold, observed, policy, system, and human-decision sources separate.

4. Engineer the value contract

A use case becomes buildable when its outcome can be owned, measured, and challenged. Define:

• the eligible population and exclusions;
• a dated baseline;
• the event that counts as an independently accepted outcome;
• its verifier;
• target, guardrails, attribution, full lifecycle cost, residual loss, and owner.

cost per accepted outcome =
  total operating and allocated lifecycle cost
  / independently accepted outcomes

Keep forecast, demonstrated pilot evidence, and realized production value separate. Don't annualize a narrow pilot without an owned extrapolation, and don't count the same benefit twice.

The worked invoice value case forecasts 240 accepted outcomes against $1,000 in monthly cost. Net value is only $320. A small miss in adoption, acceptance, review effort, or support cost erases it.

The 12 Factors of AI Value Engineering provide the full framework. Four are hard gates: an owned outcome, credible verifier, bounded authority and expected loss, and plausible positive value after full cost. Use the one-page scorecard for a live decision.

5. Make data fit for the decision

Data readiness is not a generic maturity score. It asks whether the information needed for this decision is authoritative, accessible, timely, representative, lawful, economical, and operable.

Keep operational state, knowledge and context, evaluation and training, and telemetry and feedback separate. For each decision-critical source, record:

Brownfield work must reconcile contracts, policy, code, database state, runbooks, and practice without assuming one is always authoritative. Greenfield work must create identifiers, corrections, quality telemetry, and ownership before synthetic assumptions harden into contracts.

If source repair exceeds the workflow's value ceiling, narrow the population, collect or review the missing evidence, choose a smaller mechanism, or stop. Use the data-readiness guide and data-context manifest.

6. Select the smallest sufficient mechanism

“Use AI” is not an architecture decision. Split the workflow into consequential decisions, then choose each mechanism separately.

Keep every route observable, testable, replaceable, and costed. Add multiple agents only when permissions, tools, context, ownership, or latency really differ. Record the choice in the intelligence-selection record.

7. Design the whole decision system

The model sits inside a software and operating boundary. Design the domain and state, governed context, behavior, authority, typed capabilities, durable runtime, operator work surface, and operating path together.

The central action rule is:

The model may propose. Trusted software authorizes and commits. A source-of-truth readback proves the result.

Keep credentials outside model-visible context. Recheck current identity, tenant, scope, policy, release admission, and approval at the effect boundary. Derive duplicate safety from a stable business-operation identity. After an effect, verify the authoritative state before reporting completion.

Legacy browser or desktop automation is its own controlled action boundary. Bind the session, treat visual content as untrusted, stop on interface drift, and verify the result independently. See the computer-use blueprint, architecture selector, and production controls.

8. Build one controlled vertical slice

The first slice should cross the real interface and control boundaries without pretending to be the full product. Include one representative trigger and user, authoritative context, the selected decision route, the final work surface, a bounded effect, explicit failure states, acceptance telemetry, and owner-led recovery.

Start adoption and handoff during the pilot. In the worked invoice case, a five-case fixture passes and the result is still handoff_blocked: the receiving team hasn't reproduced the adoption numbers, added an evaluation case, exercised rollback, handled an incident, or retired the service. Documents can't replace those exercises.

Measure adoption as a path through eligible work: eligible -> exposed -> completed or dispositioned -> independently accepted -> verified business effect -> sustained net value. Diagnose the first weak transition from representative cases. Low exposure may point to access, routing, integration, or eligibility; low completion to product flow, timing, trust, training, or fallback; low acceptance to evidence, behavior, policy, or authority. Don't label every break “resistance,” and don't expand beyond reviewer or support capacity.

Predeclare the pilot duration, evidence cutoff, and separate technical, operator, adoption, value, economics, and production-readiness gates. A good demo doesn't get to drift into production. Use the delivery and adoption plan, production service readiness, and customer handoff.

9. Prove claims on representative work

An evaluation is a release claim under stated conditions, not a permanent score.

Test representative normal work, difficult slices, known exceptions, adversarial inputs, dependency failures, policy changes, timeouts, retries, cancellation, recovery, and reviewer capacity. Preserve the environment and behavior versions needed to replay the result.

Separate capability (“can the mechanism do it?”), behavior (“does the system route and stop correctly?”), and outcome (“did the workflow improve accepted results without breaking guardrails?”). Promote through offline evaluation, shadow, canary, and a named production segment. Define rollback before rollout.

Use the evaluation guide, evaluation-case template, and release gates.

10. Operate the service and transfer ownership

Production is a recurring decision, not the last deployment step. Monitor accepted outcomes, value, adoption, source health, behavior versions, reliability, cost, prohibited effects, reviewer load, support, and owner continuity. Then decide whether to continue, improve, expand, constrain, pause, or retire.

For company-wide adoption, centralize reusable identity, evaluation, telemetry, security, cost, and delivery rails while keeping outcome, source, policy, effect, service, and retirement accountability with each workflow. Operate AI-enabled services rather than counting agents. Grant authority separately by segment and effect class, and require every bounded proof to name its evidence cutoff, decision owner, receiving owner, separate graduation gates, and stop or reshape path.

Any new population, authority level, action, model route, or environment is a new evidence and release decision.

Transfer is complete when the receiving team can operate, change, recover, support, and retire the service without delivery-team heroics. An internal team may remain the long-term service owner: make its funded capacity, backup coverage, incident response, and change responsibilities explicit instead of inventing a handoff. A specialist or FDE team brought in temporarily should have an exit path. Keep it embedded while ambiguity is producing consequential evidence; when the remaining work is ordinary implementation or support, give that work an explicit owner and service arrangement.

Use Operate and Scale, the service review, the workflow portfolio review when several services share funding or enablement, and the handoff template.

11. Turn field learning into product capability

The compounding advantage is not reusable private data or a pile of custom code. It is learning which parts are local and which patterns travel.

Keep policy, thresholds, identities, permissions, confidential sources, and operating decisions within the owning workflow and organization. Before building, classify the work as customer or business-unit configuration, a target-owned extension, a shared product or platform capability, a time-bounded experiment, or prohibited/deferred work. Don't leave a field-owned parallel service as a shadow product.

Productize only after recurrence appears in independent contexts, the candidate is sanitized, reuse rights and transfer rights are clear, an owner and destination exist, and target validation succeeds. Preserve negative evidence. Never manufacture dependence.

Before standardizing, classify recurring differences as policy-required, segment-specific, role-specific, system-constrained, or accidental dysfunction. Preserve necessary differences, repair dysfunction, compare only like cohorts, and keep each target's own gates. Put the next unit of effort into the first unresolved hard gate—not the lowest average maturity score.

Use the field-learning register and product-capability guide.

12. See the method in executable systems

The invoice-exception reference connects a complete worked engagement to an executable controlled-write system. Read its runtime, evaluation report, and regression tests.

The shipment-risk walkthrough combines classical ML, deterministic policy, optional model explanation, and human review. Its runtime shows why an AI-enabled system need not be agent-first.

npm ci --ignore-scripts
npm run test:reference
npm run test:evals
npm run test:hybrid

These are in-memory teaching implementations. Tests prove only their declared local behavior. Map them to target source, integration, identity, state, audit, reconciliation, load, recovery, and environment requirements with Enterprise Integration and Scale Reality.

13. Start a real engagement

Before implementation, answer:

1. What exact workflow and decision are changing?
2. Which representative cases and exceptions were observed?
3. Who owns the outcome, risk, and operating service?
4. What is the baseline, eligible population, target, and attribution method?
5. What event counts as acceptance, and who verifies it?
6. What is the maximum tolerable effect and residual loss?
7. Which mechanism is smallest and sufficient?
8. Which systems, identities, permissions, and sources of truth are involved?
9. What can users inspect, correct, reject, pause, or escalate?
10. How will the pilot stop, graduate, roll back, transfer, and retire?

If a consequential answer is missing, stay in discovery. A model choice won't resolve it.

Continue into the repository

• Run the method: Handbook.
• Build or review a system: Engineering Kit, blueprints, and examples.
• Learn the practice: capability roadmap.
• Use a recurring design hypothesis: solution portfolio.
• Work with a coding agent: AGENTS.md, the optional task skills, and the Applied AI Field Guide local plugin when local engagement continuity is useful.