FIELD · Handbook · 5 min read
References, influences and contribution
What FIELD draws from, how it adapts those ideas and what it does not claim.
Arunank Sharan · Kuzushi Labs ·
In this article
FIELD is a Kuzushi Labs synthesis of public consulting, product, engineering and operational practices. This register identifies the sources that materially informed the method. It is a selective review, checked on 17 September 2026, rather than a claim to have surveyed every organization’s internal playbook.
Methodological influences
| Source | Idea informing FIELD | Our adaptation |
|---|---|---|
| Palantir: use-case lifecycle and functional requirements | Start with useful capabilities and outcomes for identifiable users | A workflow outcome contract and a bounded first journey |
| McKinsey: seven-step problem solving | Decompose a problem and prioritize analysis | Test the assumptions most likely to invalidate the engagement |
| Bain: five steps to better decisions | Explicit roles and accountability for consequential decisions | Name decision, review and execution responsibilities at each commitment |
| BCG: foundations for generative AI | People and process change are substantial parts of AI delivery | Budget adoption and operating ownership as concrete work |
| Deloitte: product operating model | Connect value, ownership and enduring capabilities | Operational handover and a second-consumer reuse test |
| Christensen Institute: Jobs to Be Done | Understand the progress sought in a specific circumstance | Observe the task, alternatives and adoption friction |
| Google Research: HEART | Connect user goals, signals and metrics | Eligible-use, verified completion, review effort and return use |
| Google SRE: evolving engagement and production readiness | Establish readiness before accepting operational responsibility | Explicit load, recovery and customer-operator exercises |
| DORA: value-stream mapping | Expose handoffs and waiting in delivery | Map both delivery dependencies and customer workflow delay |
| OpenAI: evaluation best practices | Representative task evaluation and calibrated judgment | Configuration-bound quality evidence and regression criteria |
| NASA: requirements verification matrix | Trace requirements to verification | Link promises, controls, tests, evidence and affected decisions |
| CMU SEI: dependability cases | Connect claims, arguments and evidence with explicit limits | A reviewable rationale for each release decision |
| NIST: AI Risk Management Framework | Account for AI risks through the lifecycle | Owned risk decisions, monitoring and reassessment triggers |
Bain’s RAPID name and the other established methods belong to their respective authors or organizations. FIELD is independent; these references do not imply endorsement, certification or participation. We do not reproduce their complete methods or apply their labels to proprietary Kuzushi Labs material.
Technical reference points
The agent applications use the official MCP documentation, A2A documentation, Google ADK documentation, OpenAI Agents SDK documentation and Agent Client Protocol documentation. Check the pinned revision and runtime for an actual implementation; this publication is not a compatibility guarantee.
For the machine-level analysis, the relevant primary references include NVIDIA’s CUDA best-practices guide, PyTorch distributed documentation, the PagedAttention paper, and the LoRA paper. These explain mechanisms; they are not sources for the planning prices, throughput measurements or client results in the worked applications.
Additional application-specific references are Google’s Gemma thinking guidance, the Hugging Face TRL DPO trainer and GRPO trainer, and the Google ADK A2A wrapper source. The first informs serialization checks; the trainer references explain adaptation objectives; the wrapper source supports inspecting persistence defaults. None supplies the worked scenario’s numerical results.
What is specific to FIELD
FIELD joins customer qualification, workflow evidence, resource constraints, authority, economics, release decisions, adoption and ownership in one engagement record. Its practical contribution is the connection between them: changes identify which promises need new evidence; economic sensitivity points to the next experiment; ownership is demonstrated through an operator exercise; and reuse is evaluated with a second consumer.
None of requirement traceability, business cases, release reviews or outcome measurement is newly invented here. The claim is a particular applied synthesis and usable set of tools. This publication does not establish that FIELD outperforms other methods. Such a claim would require comparative use, measured review overhead and independent assessment of outcomes.
How to interpret and reuse the examples
The application library contains worked scenarios with planning assumptions, formulas and proposed decisions. Exact quantities make the reasoning inspectable. They are not a disguised record of named or unnamed customer outcomes. Actual client experience is presented separately in the website’s project articles.
When adapting an example, replace volume, quality, staffing, price, model and authority assumptions with your own evidence. Preserve attribution to the established sources. Do not treat a suggested threshold as an industry standard or a software permission as a legal right. Record the method version and material changes so the next reviewer understands the basis for the decision.
The commercial price and capacity examples are deliberately specified scenarios, not market benchmarks, rate cards or validated procurement recommendations. Their purpose is to show the assessment calculation and the evidence needed to turn it into a commitment.