← FIELD applications

FIELD · Customer delivery · 4 min read

An assistant inside the customer network

Read-only SQL and ticket lookup through the approved outbound proxy.

Arunank Sharan · Kuzushi Labs ·

In this article

This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.

Planning basis and engagement boundary

ItemBasis for this application
Demand and context500 daily users; 20 tasks/s peak; 250 ms assumed nonmodel dependency wait
First delivery boundaryRead-only SQL and ticket lookup through the approved outbound proxy
Acceptance to agree and testProve allowed and denied access, proxy streaming, certificate trust and graceful outage behavior
Exclusion or constraintNo bypass of the approved network boundary or personal credentials.

F — Frame the outcome

Enable one task in the customer's permitted environment; data handling and working connectivity are prerequisites to choosing hosted versus local inference.

Value measure: Eligible task completion, integration lead time and support incidents.

I — Investigate the workflow

Test DNS, proxy authentication, certificates, outbound routes and identity from the real runtime. Confirm permitted data categories with their owners.

First evidence task: Run the smallest authorized end-to-end task through the actual proxy.

E — Engineer the solution

Map the authorized inference/SQL/tool path and independent model concurrency, CPU and connection budgets. Use durable status polling if the network cannot support the required stream.

The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.

Discovery

Confirm allowed data categories, destinations, retention, model-provider usage and network routes with the actual owners. “Private network” does not establish whether model calls may leave it. Test DNS, proxy authentication, TLS trust, outbound allowlists and streaming behavior from the real runtime environment.

Implementation plan

Run the application/tool gateway and durable state inside the approved environment. Users authenticate through enterprise identity. Scoped service/delegated credentials access authorized SQL views and ticketing operations. Send only permitted context through outbound HTTPS to an approved inference endpoint, or deploy a local model if the requirement and quality/capacity support it. Keep secrets out of model context and redact operational traces.

Sizing

Assume 20 tasks/s with 250ms mean nonmodel I/O wait: about five waiting calls at that boundary. With 5ms CPU/task, application CPU demand is 0.1 CPU-s/s, excluding parsing/tokenization/model work. If a model call averages 4s, model concurrency is about 80, not five. Budget proxy connections/stream limits, database pool and token quota accordingly. A local model adds weight/KV/runtime memory and load testing; it is not automatically feasible on the application host.

Diagnostic sequence

A fixed streaming timeout suggests proxy/load-balancer behavior: compare buffered and streamed calls, examine idle/total timeouts and heartbeats permitted by the contract. Resolve DNS from each environment and verify certificate chains. For expired tokens, refresh at a trusted boundary and resume only safe operations; an uncertain ticket creation must be reconciled by operation ID.

Acceptance

Produce an environment-specific connectivity matrix, authenticated end-to-end smoke test, permission tests, redacted trace, deployment manifest and operator runbook. Test the proxy outage and identity outage without disabling TLS or broadening egress to “make it work.”

Alternative

Polling a durable task status can replace fragile long streams, trading immediacy for a simpler network contract.

L — Launch with evidence

Accept the deployment only after authenticated end-to-end and failure tests in that environment. A cloud diagram or local demo does not establish integration success.

Critical decision condition: Unapproved data egress or inability to enforce identity blocks real customer use.

Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.

D — Develop ownership and reuse

The customer's operator owns secrets, proxy configuration and a diagnostic runbook; rehearse token expiry and network failure without broadening access.

Candidate reusable asset: Connectivity probe and deployment contract.

Commercial decision and next commitment

Accountable decision owner: Customer environment/resource owner and release owner.

The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.

Approve only the next exposure level supported by the evidence. The next useful investment is: run the smallest authorized end-to-end task through the actual proxy.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register.