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
| Attribute | Specify | Evidence required |
|---|---|---|
| Demand | Average, peak, burst duration, seasonality and tenant skew | Representative arrivals and load trace |
| Latency | Start/end events, p50/p95/p99, time to first useful output | Stage timing and end-to-end distribution |
| Availability | Eligible operations, window, dependency behavior | User-visible success and outage records |
| Correctness | Business invariants, acceptable uncertainty and escalation | Task/state checks and adversarial cases |
| Consistency | Read freshness, conflict policy and accepted staleness | Concurrent-write and stale-read tests |
| Durability | What an acknowledgement guarantees | Crash and replay tests |
| Recovery | RTO, RPO, dependencies and reconciliation | Timed restore exercise |
| Isolation | Tenant/user boundaries and fair resource access | Cross-scope and noisy-neighbor tests |
| Cost | Per attempt, verified outcome and reserved capacity | Usage, 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.