← FIELD methodology

FIELD · Handbook · 5 min read

Assess the engineering and operating constraints

Connect customer promises to workload, machines, failure behavior and authority.

Arunank Sharan · Kuzushi Labs ·

In this article

Engineering assessment makes the customer commitment physically and operationally credible. It asks whether the proposed behavior can be delivered within the data, resource, latency, availability and ownership constraints. Diagrams are useful only when their boundaries and failure semantics are clear.

Write an operating envelope

AttributeSpecifyEvidence required
DemandAverage, peak, burst duration, seasonality and tenant skewRepresentative arrivals and load trace
LatencyStart/end events, p50/p95/p99, time to first useful outputStage timing and end-to-end distribution
AvailabilityEligible operations, window, dependency behaviorUser-visible success and outage records
CorrectnessBusiness invariants, acceptable uncertainty and escalationTask/state checks and adversarial cases
ConsistencyRead freshness, conflict policy and accepted stalenessConcurrent-write and stale-read tests
DurabilityWhat an acknowledgement guaranteesCrash and replay tests
RecoveryRTO, RPO, dependencies and reconciliationTimed restore exercise
IsolationTenant/user boundaries and fair resource accessCross-scope and noisy-neighbor tests
CostPer attempt, verified outcome and reserved capacityUsage, staffing and invoice reconciliation

An SLO is a target for a defined service. An SLA is a contractual commitment with agreed terms. They should not be used interchangeably. At 99.9% availability, a time-based 30-day window permits 43.2 minutes of unavailability under that particular definition; request-based budgets use eligible requests instead.

Carry the workload down to resources

Little’s law gives mean in-flight work as arrival rate multiplied by mean time in the bounded subsystem, when the relevant averages and stability assumptions hold. Thirty tool calls/s waiting 0.4 seconds implies 12 calls in flight on average. It does not imply 12 CPU cores. If each call consumes three milliseconds of CPU, CPU demand is 0.09 core-seconds/s before framework overhead.

Size CPU from measured service demand, memory from resident state and concurrency, storage from retained bytes plus indexes/replication, and network from payloads in both directions. A vCPU is a provider scheduling unit, not a promise of a full physical core. Inspect processor architecture, SMT, container limits, memory bandwidth, NUMA and network/storage ceilings where they matter. Native libraries can spawn their own threads; multiplying workers and native threads can degrade tail latency.

For model serving, distinguish prefill from token-by-token decoding. State model weight precision, parameter count, batch/concurrency, prompt/output distribution, KV-cache geometry, workspace and fragmentation. A raw 8-billion-parameter model at two bytes/parameter requires 16 GB for weights alone. Fitting weights says little about safe serving concurrency. GPU memory, bandwidth, compute, interconnect and supported kernels all matter; measured throughput at the required latency is the basis for procurement.

Never infer a production machine count from an advertised peak FLOPS value. Keep headroom and demonstrate the failure condition the customer is buying: a fleet that handles normal load may still fail when one node is unavailable.

Define state and effects

Identify the authoritative store for each business fact. Separate source data, cached projections, workflow state, audit events, approvals and external receipts. Write the invariant in business terms, such as “One approved operation creates no more than one refund.” Specify operation identity, transaction boundary and what to do when a dependency times out after possibly committing.

Retries require an idempotency contract or reconciliation. A queue’s delivery guarantee does not by itself make an external payment exactly once. Cancellation prevents future work; it does not undo an already committed effect. Compensating actions need their own authority and may be imperfect.

Make risk a concrete design input

Inventory assets, actors, trust boundaries, entry points and consequential actions. Evaluate cross-tenant access, prompt injection, credential leakage, unsafe tool arguments, denial of service, poisoned data, exfiltration and misuse. Mitigate at the enforcing boundary: identity propagation, least privilege, scoped endpoints, validation, sandboxing, approvals, limits and auditable receipts.

Record personal-data flows, purpose, retention and deletion. Assign review of jurisdictional or sector-specific duties to the responsible customer specialist. FIELD draws on NIST’s AI risk management framework for lifecycle risk accountability; using this checklist does not establish regulatory compliance or certification.

Where quality can vary across language, geography, user group or accessibility need, report those slices. Averages can hide a harmful or unusable subgroup. For uncertain consequential outputs, define abstention and human escalation with enough staffing to make them practical.

Compare options and name the reversal threshold

Compare an improved manual process, deterministic automation, hosted service, custom application and model adaptation where relevant. Record delivery lead time, capability, operating burden, cost, lock-in and exit effort. A decision should state what evidence would reverse it: review exceeding 3.27 minutes, a source quota preventing catch-up, an unsupported language slice or a customer restriction on data egress.

Finish with a capacity worksheet, authority map, dependency register, recovery plan and acceptance tests. Each is tied to the same customer outcome. The release review checks that the promised operating envelope was tested on the configuration being released.