Why Your LLM Architecture is Flawed: Mastering Dot-and-Index Paths and Context Isolation in Jev A developer advocates structuring LLM state as a strict, addressable tree of dot-and-index paths, similar to CSS selectors or filesystem paths, to reduce hallucination and inference cost in production AI systems. The approach, implemented with the Jev System One architecture and its TypeScript SDK, evaluates multiple isolated questions in parallel against a single shared state object, with the author recommending a maximum of three to four levels of path depth. If you are building production AI systems, you have likely hit a frustrating wall. Your prompts are meticulously engineered, your retrieval-augmented generation RAG pipeline is fully operational, and yet your model still hallucinates, drifts off-topic, or gives wildly uncalibrated answers when faced with complex, multi-tenant payloads. The problem isn't your prompt. The problem is your state architecture. In early tutorials, passing a single customer message or a short transaction string into an AI model works seamlessly. But production systems don't handle single sentences. They handle massive JSON projections containing orders, users, historical messages, policies, feature flags, and latent workflow states. If you treat your state as a passive "input payload" rather than a strict, traversable API contract, you are opening your application up to context rot, prompt injection, and statistical dilution. Let's fix that. To build reliable, sub-100ms decision loops with Jev, you need to understand the fundamental asymmetry of a System One architecture: The state is shared, but the questions are isolated. When you submit a request to Jev, you pass a single state object alongside a collection of independent questions. Every question evaluates against that same state in parallel. No question sees another question's answer. The state is the only channel through which information flows. Because of this, the state is not a neutral container. It is the terrain over which every judgment walks. Think of your state object like the Document Object Model DOM in front-end development. You don't interact with a web page by dumping its raw text into a black box; you interact with it through a structured, addressable tree using CSS selectors. Jev state works identically. When you write a question that targets ticket.messages 0 .text , you are writing a selector. You are describing an absolute path through a structured object by walking named keys and numeric indices. Similarly, think of a filesystem path like /var/log/nginx/access.log . The hierarchy encodes semantics and access models. A path like order.charges 0 .status coerces the model's attention. It tells the reader—before a single byte of reasoning occurs—that this query is about a charge, it is the first charge in a list, and we are asking about its status, not its timestamp or amount. Path specificity is inversely proportional to inference cost. The more completely a path specifies its target, the less the model must guess, and the more concentrated its probability distribution will be around the correct answer. The concepts and code demonstrated here are drawn directly from my ebook Jev: The Definitive Guide to System One AI here http://tiny.cc/Jev . Check also the 9 volumes bundle: TypeScript AI & Agentic Engineer Masterclass https://leanpub.com/b/TypescriptAgenticBundle When designing your state schema, three competing priorities must be balanced: path clarity, update locality, and context isolation. workflow.stages 2 .steps 5 .outputs.results 0 .data.amount force the model to maintain too many cognitive frames of reference. This increases traversal cost, lowers confidence scores, and broadens probability distributions. Aim for a maximum of three to four levels of depth. Let's look at a complete, end-to-end TypeScript program that puts these theoretical foundations into practice. This billing triage example handles a nested JSON state, uses backticked dot-and-index paths, evaluates three primitive types noul , choice , and score in a single parallel request, and composes the final business logic entirely in code. js // src/lib/triage.ts import { TypeSafeClient, choice, noul, score } from "@typesafe-ai/sdk"; / One per-process client. Reads TYPESAFE API KEY from the environment and defaults to jev-latest . Reuse this object across requests so the connection pool and retry policy stay warm. / const client = new TypeSafeClient ; / The state is the single blob of evidence the model reads to answer every question. Paths inside this object are the addressing surface that the questions point at, using backticked dot-and-index expressions such as ticket.messages 0 .text . / const state = { ticket: { id: "T-1042", messages: { from: "customer", text: "I was charged twice for order A-104. Please refund the duplicate.", }, { from: "support", text: "We are checking the charges.", }, , }, order: { id: "A-104", charges: { amount usd: 49, status: "captured" }, { amount usd: 49, status: "captured" }, , }, refund policy: "Duplicate charges are eligible for a refund.", }; / Every question is defined statically. The keys refund requested , department , etc. are what the answers are keyed by in the response. / const questions = { refund requested: noul "Does ticket.messages 0 .text request a refund?", , duplicate charge: noul "Do order.charges 0 .amount usd and order.charges 1 .amount usd match?", , policy supports refund: noul "Given refund policy , does it support the request in ticket.messages 0 .text ?", , department: choice "Which team should handle ticket.messages 0 .text ?", { billing: "Payment or subscription issues", technical: "Bugs or integration problems", sales: "Pricing or account questions", } , frustration: score "How frustrated is the customer in ticket.messages 0 .text ?", "Calm and factual", "Frustrated but civil", "Very angry, strong language", , , }; / Orchestrates one triage pass in a single systemOne call. / export async function triage : Promise