[{"data":1,"prerenderedAt":142},["ShallowReactive",2],{"thoughts-index":3},[4,49,94],{"slug":5,"path":6,"url":7,"title":8,"metaTitle":9,"description":10,"published":11,"modified":11,"datePlaceholder":12,"keywords":13,"image":23,"imageUrl":29,"summary":30,"faqs":31,"reference":-1,"material":-1,"cta":44,"html":45,"referenceHtml":46,"wordCount":47,"readingMinutes":48},"harness-engineering-for-a-fleet","\u002Fthoughts\u002Fharness-engineering-for-a-fleet","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fharness-engineering-for-a-fleet","Harness engineering for a fleet: how I run Claude, Codex and pi across a dozen repos","Harness engineering for a fleet | Gavin Erasmus","How the harness around Claude Code, Codex and pi is set up for a fleet of agents: one instruction file, tiered memory, split roles, CI gates and hooks.","2026-10-24",false,[14,15,16,17,18,19,20,21,22],"harness engineering","AI agents","Claude Code","Codex","pi","agent fleet","PreToolUse hooks","multi-agent coordination","agent memory",{"src":24,"src2x":25,"width":26,"height":27,"alt":28},"\u002Fthoughts\u002Fharness-engineering-fleet.png","\u002Fthoughts\u002Fharness-engineering-fleet@2x.png",1280,720,"Title card reading 'Harness engineering for a fleet', with the line 'Codex builds, Claude coordinates, pi attacks' beneath it.","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fharness-engineering-fleet.png","A harness is everything around the model: the instructions it reads, the tools it may call, the memory that survives a context reset, the checks that decide whether a run passed, and the gates that stop it doing what the rules forbid. On a normal day here there are ten to fifteen agent panes open across six or seven repos, three providers and several accounts. This is the setup as it stands on 24 October 2026, and every rule in it has a receipt.",[32,35,38,41],{"q":33,"a":34},"What is harness engineering?","A harness is everything around the model: the instructions it reads, the tools it may call, the memory that survives a context reset, the checks that decide whether a run passed, and the gates that stop it doing what the rules forbid. Harness engineering is the design of those parts, and at fleet scale it also decides who builds, who talks to whom and what the coordinator does.",{"q":36,"a":37},"Who builds and who coordinates?","Any work order with a written spec goes to Codex. Claude coordinates and inspects the result once, through a read-only inspector that never fixes anything itself. pi is the security reviewer. Nobody certifies their own changes.",{"q":39,"a":40},"Why use hooks rather than instructions alone?","Prose fails under load: the model reads the instruction, parses twenty other constraints, and skips it when the context is full. The prose stays so the agent understands the goal, and the hook makes the failure impossible rather than unlikely.",{"q":42,"a":43},"What should I copy first?","Put the model choice on every dispatch and gate it. Give every repo a handoff file that a fresh session can resume from, and make updating it part of finishing. Then take the three rules that have already cost you something and turn each into a hook.","If you are running more than one agent and want to talk through the harness around them, I would welcome the conversation.","\u003Cp>A harness is everything around the model: the instructions it reads, the tools it may call, the memory that survives a context reset, the checks that decide whether a run passed, and the gates that stop it doing what the rules forbid. For one agent on one task that is a contract, a map, external memory, sensors and mechanical gates. On a normal day here there are ten to fifteen agent panes open across six or seven repos, three providers (Claude Code, Codex and pi), and several accounts with separate cloud identities. At that scale the harness has to answer three more questions: who builds, who talks to whom, and what the coordinator does.\u003C\u002Fp>\n\u003Cp>This is the setup as it stands on 24 October 2026. Every rule in it has a receipt, meaning an incident that cost money or a weekend.\u003C\u002Fp>\n\u003Ch2>1. One instruction file, and it is a map\u003C\u002Fh2>\n\u003Cp>There is a single global instructions file. It is canonical in one place and symlinked into every agent's config directory, so Claude, Codex and every account profile read the same text. Nobody forks a copy.\u003C\u002Fp>\n\u003Cp>It holds rules about how to work, and nothing else. Reference material (the server estate, cloud traps, deploy models) lived in it until today, when it was split out into separate docs with a one-line pointer each. The file is loaded into every session, and a session started in the home folder loads it twice, so every paragraph of reference in it was paying rent in every conversation. The cloud traps now live in a path-scoped rule that loads only when an agent touches a deploy manifest, an env file, a Dockerfile, Terraform or a workflow.\u003C\u002Fp>\n\u003Ch2>2. Memory in three tiers, with a hard wall between them\u003C\u002Fh2>\n\u003Cp>Global memory holds cross-project facts about tools and access. Each repo has a HANDOFF.md at its root that holds state, decisions with attribution and date, assumptions, people, next steps and how to unwind. Repo-specific lessons go in that repo's project memory. Client content never goes in the global tier; the database and the file layout enforce that, not goodwill.\u003C\u002Fp>\n\u003Cp>A session-start hook loads the memory index. A stop hook reminds the agent to update the handoff. The rule is that any session that changed state, a decision, an assumption, a person or a blocker updates HANDOFF.md and commits it with the change, without being asked. A fresh session starts from that file, which is also how a long conversation gets retired before it degrades.\u003C\u002Fp>\n\u003Ch2>3. Codex builds, Claude coordinates, pi attacks\u003C\u002Fh2>\n\u003Cp>Any work order with a written spec goes to Codex. Claude coordinates and inspects the result once, through a read-only inspector subagent that returns findings as claim, verdict, evidence and correction, and never fixes anything itself. pi is the security reviewer: threat models, auth, secrets, injection, attack paths through a diff. Claude and Codex keep correctness and design review. Nobody certifies their own changes.\u003C\u002Fp>\n\u003Cp>Review loops are capped at two fix rounds per reviewer. After that the branch is held and the open findings are reported. Reviews run in batches, one Codex review and one pi review per integration round covering every branch in it. The receipt is a session on 19 and 20 October that hit the weekly usage limit after one fix ran fifteen review rounds and Claude subagents did most builds at 300,000 to 620,000 tokens each.\u003C\u002Fp>\n\u003Ch2>4. The model is chosen on every dispatch\u003C\u002Fh2>\n\u003Cp>A subagent dispatched without a model inherits the main session's model, which is Opus. One repo spent 77 per cent of its account on Opus subagents that way. The rule is Sonnet by default for searches, tests, CI waits, merges, drafting and well-specified builds; Opus only when a wrong call is costly, with the reason in the brief; Haiku for trivial lookups. As of today a PreToolUse hook refuses an Agent dispatch with no model set.\u003C\u002Fp>\n\u003Ch2>5. Sensors, and what counts as green\u003C\u002Fh2>\n\u003Cp>CI is the gate. A push is not finished until the run completes, and the agent reads the failure before judging it. A green lint job next to a red integration job is a red run. A green local suite is not the same claim, because CI builds the database and environment from scratch and local runs never do. Where a change could shift runtime behaviour, the agent runs both paths against main and diffs the outputs, because passing tests do not prove the behaviour changed correctly.\u003C\u002Fp>\n\u003Ch2>6. Dual encoding: the rules that bit twice became hooks\u003C\u002Fh2>\n\u003Cp>Every rule above existed as prose. Prose fails under load: the model reads the instruction, parses twenty other constraints, and skips it when the context is full. Today the five rules that have cost the most were given a mechanical gate in Claude Code's PreToolUse hooks:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>An Agent call with no model is refused.\u003C\u002Fli>\n\u003Cli>A docker run without --rm is refused.\u003C\u002Fli>\n\u003Cli>A deploy command (Cloud Run, Ansible, Wrangler, Vercel, a provisioning script) is refused unless the latest CI run on the current branch is completed, green, on the same commit as HEAD, with nothing unpushed. If the CI state cannot be read, it is refused.\u003C\u002Fli>\n\u003Cli>A gcloud login is refused unless the folder is mapped to a cloud identity or the command sources the repo's env file first. The receipt is a login that silently repointed a different estate.\u003C\u002Fli>\n\u003Cli>Reading a .env file prompts. Sending or forwarding mail prompts, even where the connector is otherwise allowed without prompts.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The prose stays in the instructions file so the agent understands the goal. The hook makes the failure impossible rather than unlikely. The gates fail closed where the action is rare and expensive, and prompt where the action is sometimes legitimate.\u003C\u002Fp>\n\u003Ch2>7. The fleet layer: panes, peers and one coordinator\u003C\u002Fh2>\n\u003Cp>Each agent runs in its own pane in a terminal workspace manager (Herdr). Agents in the same repo or across repos message each other directly with a small peer tool, by pane, by repo or by agent kind. Handoffs, second opinions and review requests go peer to peer instead of through me. A send receipt is not an acknowledgement, so a relay stays alive until the peer answers or a bounded timeout expires.\u003C\u002Fp>\n\u003Cp>One pane is the coordinator. Its job is status, dispatch and decisions, not building. A status skill reads every pane's Herdr state, session transcript and repo state and reports in three bands: needs me, working, done or idle. It never prompts a working or blocked agent, because that interrupts the turn or answers its pending approval. From a phone, the coordinator can relay a decision, answer a blocked agent's prompt one keypress at a time, and queue work for the agents that are idle.\u003C\u002Fp>\n\u003Cp>Delegation never widens authority. A subagent drafts freely but never sends mail, posts, deploys or changes production without the same confirmation I would have to give the main session. Messages between agents do not expand what any of them may do.\u003C\u002Fp>\n\u003Ch2>8. Account and identity routing is part of the harness\u003C\u002Fh2>\n\u003Cp>Each folder group maps to an account: a Claude profile, a Codex login, a cloud configuration directory, a browser profile. The mapping is set per folder automatically, in agents and in shells, and an unmapped folder gets no cloud login at all. The wrong cloud identity fails as a 403 that reads like missing IAM, which cost hours before the routing existed. Terraform's state backend uses application default credentials rather than the active account, so the routing covers that separately.\u003C\u002Fp>\n\u003Ch2>9. Disk and spend are sensors too\u003C\u002Fh2>\n\u003Cp>A session checks free disk before any run that writes large artefacts, and stops under a threshold. Every ephemeral container runs with --rm and a named volume the teardown deletes. A worktree is removed once its pull request merges. The receipt is a clean-up on 16 October that recovered 313 GiB of frozen input copies left in 79 merged worktrees, and 234 GB of anonymous Docker volumes from test databases, 1,376 of them.\u003C\u002Fp>\n\u003Ch2>What to copy first\u003C\u002Fh2>\n\u003Cp>If you run one agent, the first six sections are the list. If you run several, start with three things. Put the model choice on every dispatch and gate it. Give every repo a handoff file that a fresh session can resume from, and make updating it part of finishing. Then take the three rules that have already cost you something and turn each into a hook. The prompt guides the intention. The gate protects the system.\u003C\u002Fp>\n","",1635,7,{"slug":50,"path":51,"url":52,"title":53,"metaTitle":54,"description":55,"published":56,"modified":56,"datePlaceholder":12,"keywords":57,"image":67,"imageUrl":71,"summary":72,"faqs":73,"reference":-1,"material":83,"cta":90,"html":91,"referenceHtml":46,"wordCount":92,"readingMinutes":93},"ai-basics","\u002Fthoughts\u002Fai-basics","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fai-basics","AI Basics: An Interactive Primer","AI Basics: An Interactive Primer | Gavin Erasmus","An interactive primer on eleven AI concepts, from language models and tokens to agents and guardrails. Open it in a browser, or download it to use offline.","2026-10-23",[58,59,60,61,62,63,64,15,65,66],"AI basics","interactive primer","large language models","tokens","context engineering","tool calling","MCP","embeddings","guardrails",{"src":68,"src2x":69,"width":26,"height":27,"alt":70},"\u002Fthoughts\u002Fai-basics.png","\u002Fthoughts\u002Fai-basics@2x.png","The home view of the AI Basics interactive primer: the headline 'AI Basics, but you get to break it.', a short introduction, two buttons, and the first row of concept cards under the heading Understanding the Brain.","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fai-basics.png","A single interactive page that explains how AI systems work and how they are put to use. Each of eleven ideas, from language models and tokens to agents and guardrails, comes with a small demonstration you can operate yourself. The primer opens in any browser and runs offline once it has been downloaded.",[74,77,80],{"q":75,"a":76},"What does the AI Basics primer cover?","It explains eleven ideas about how AI systems work and how they are put to use, in three parts: how AI thinks, how it takes action, and how it delivers value. The concepts run from large language models and tokens to agents, multi-agent systems, and guardrails and governance.",{"q":78,"a":79},"How is the primer different from a written explainer?","Each concept has a short explanation and a hands-on demonstration that you can operate yourself, so the idea can be tried as well as read.",{"q":81,"a":82},"What do I need to use it?","Nothing beyond a browser. The primer is a single HTML page that needs no installation and no account. You can open it in a new tab, or download the file to keep a copy, and once downloaded it runs offline.",{"href":84,"filename":85,"size":86,"openLabel":87,"downloadLabel":88,"type":89},"\u002Fthoughts\u002Fai-basics-interactive.html","ai-basics-interactive.html","74 KB","Open the interactive primer","Download the primer (HTML)","text\u002Fhtml","If you are working out where these ideas apply in your own organisation, I would welcome the conversation.","\u003Ch2>What the primer covers\u003C\u002Fh2>\n\u003Cp>The primer is a single HTML page in three parts: how AI thinks, how it takes action, and how it delivers value. Each concept has a short explanation and a hands-on demonstration, so the idea can be tried as well as read.\u003C\u002Fp>\n\u003Cp>The eleven concepts are:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Large language models\u003C\u002Fli>\n\u003Cli>Tokens and cost\u003C\u002Fli>\n\u003Cli>Context engineering\u003C\u002Fli>\n\u003Cli>APIs\u003C\u002Fli>\n\u003Cli>Tool calling\u003C\u002Fli>\n\u003Cli>MCP\u003C\u002Fli>\n\u003Cli>Skills\u003C\u002Fli>\n\u003Cli>Agents\u003C\u002Fli>\n\u003Cli>Embeddings and similarity search\u003C\u002Fli>\n\u003Cli>Multi-agent systems\u003C\u002Fli>\n\u003Cli>Guardrails and governance\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Using it\u003C\u002Fh2>\n\u003Cp>Open it in a new tab to use it here, or download the file to keep a copy. It needs no installation and no account, and once downloaded it runs offline in any browser.\u003C\u002Fp>\n",258,1,{"slug":95,"path":96,"url":97,"title":98,"metaTitle":99,"description":100,"published":56,"modified":56,"datePlaceholder":12,"keywords":101,"image":111,"imageUrl":115,"summary":116,"faqs":117,"reference":130,"material":-1,"cta":-1,"html":138,"referenceHtml":139,"wordCount":140,"readingMinutes":141},"decision-models-for-agent-workflows","\u002Fthoughts\u002Fdecision-models-for-agent-workflows","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Fdecision-models-for-agent-workflows","Applying The Decision Model to long-running agent workflows","The Decision Model for agent workflows | Gavin Erasmus","Why long-running AI agent workflows make inconsistent decisions, and a design using The Decision Model to make them consistent and auditable.",[102,103,104,15,105,106,107,108,109,110],"The Decision Model","TDM","decision modelling","agentic workflows","determinism","rule families","DMN","Jev","LLM",{"src":112,"src2x":113,"width":26,"height":27,"alt":114},"\u002Fthoughts\u002Ftdm-three-components.png","\u002Fthoughts\u002Ftdm-three-components@2x.png","Diagram of three components and their roles: Jev, a typed decision model, answers narrow judgement questions; The Decision Model's rule families apply the business rules deterministically; the LLM agent calls only the tools the conclusion permits.","https:\u002F\u002Fgavinerasmus.com\u002Fthoughts\u002Ftdm-three-components.png","Large language models do not apply the same rule in the same way on every run, and in long-running agent workflows the inconsistency compounds. The approach described here removes business decisions from the prompt and models them with The Decision Model (TDM), a method published by Barbara von Halle and Larry Goldberg in 2009. Rule families apply the business rules in code, a typed decision model answers only the narrow questions that need judgement and abstains when uncertain, and the LLM acts only within the conclusion.",[118,121,124,127],{"q":119,"a":120},"What is The Decision Model?","The Decision Model (TDM) is a method for representing business logic, published by Barbara von Halle and Larry Goldberg in 2009. It expresses decisions as rule families, which are small tables of conditions and conclusions that chain together, and normalises them so that each fact appears once and every dependency is visible.",{"q":122,"a":123},"Why are AI agent workflows not deterministic?","A large language model interprets its instructions afresh on every run, so the same input can lead to a different decision. In a long-running workflow, each step depends on earlier decisions, so small inconsistencies compound across the process.",{"q":125,"a":126},"What does the typed decision model do in this design?","The typed decision model, Jev, answers only narrow judgement questions that rules cannot resolve, such as whether a document is a bill. It must choose from candidates extracted by code, returns a confidence score, and is treated as uncertain below a set threshold, in which case a person decides.",{"q":128,"a":129},"Does this make the LLM itself deterministic?","No. The LLM continues to interpret input and call tools, but the business decisions are made by rule families in code, and the agent may act only within the conclusion those rules return.",{"text":131,"name":132,"authors":133,"year":136,"publisher":137},"von Halle, B. and Goldberg, L. (2009). *The Decision Model: A Business Logic Framework Linking Business and Technology.* Auerbach Publications.","The Decision Model: A Business Logic Framework Linking Business and Technology",[134,135],"Barbara von Halle","Larry Goldberg",2009,"Auerbach Publications","\u003Cp>AI agents are now able to run business processes that span many steps, including reading a document, matching it to existing records, applying policy, writing to a system of record and confirming the result. However, a large language model (LLM) does not apply the same rule in the same way on every run. In a short task the variation is tolerable, but in a long-running workflow each step depends on the decisions made before it, and the inconsistency compounds. As an illustration, a workflow containing twenty decisions, each made consistently 98 per cent of the time, completes all twenty consistently on approximately two runs in three. A process that behaves in this way cannot be audited and cannot be permitted to act without a person checking each step.\u003C\u002Fp>\n\u003Cp>The common response is to extend the prompt. Agent procedures are written as prose, and the model interprets that prose afresh on every run. As a result, the same input can produce a different decision, a required step can be skipped without any signal, and the logic cannot be reviewed, as it exists only in the model's reading of the text. On the CLTF platform, before the current controls were introduced, finance agents created a supplier that did not exist, drafted a bill payable to the business owner rather than the supplier, entered dates with no year and omitted a verification step the procedure required. In each case the model made a business decision implicitly and made it incorrectly, while its handling of the language was sound.\u003C\u002Fp>\n\u003Ch2>An established method\u003C\u002Fh2>\n\u003Cp>The approach removes those decisions from the prompt and models them explicitly, using a method published in 2009. The Decision Model (TDM) was developed by Barbara von Halle and Larry Goldberg. I applied it as Corporate and Institutional Banking Debt Change Programme Director at the Royal Bank of Scotland (RBS) on the end-to-end London Interbank Offered Rate (LIBOR) loans process and system transformation programme. Larry Goldberg trained the debt change team in the method. The LIBOR loan processes across the front, middle and back office were redesigned using Business Process Model and Notation (BPMN) process models and TDM decision models, implemented in an IBM Business Process Manager workflow integrated with LoanIQ, and a permanent process and decision modelling centre of excellence was established within the change team.\u003C\u002Fp>\n\u003Cp>TDM represents business logic as rule families. A rule family is a small table in which each row is a set of conditions leading to a single conclusion, and the conclusion of one family can serve as a condition in the next, so that the families chain into a complete decision. The logic is normalised in the same manner as data in a relational database, so that each fact appears once and no rule depends on another without that dependency being visible. The logic is also held separately from the process that uses it. The Object Management Group's Decision Model and Notation (DMN) standard draws on the same principles. The method was designed for a regulated bank that required its decisions to be consistent, explainable and owned, which is the same requirement now placed on agents executing finance processes.\u003C\u002Fp>\n\u003Ch2>The design\u003C\u002Fh2>\n\u003Cp>The design combines TDM with two newer components, each assigned a single function. Before any rule is applied, code extracts candidate values from the source document, comprising the dates, amounts and references printed on it. Only values extracted in this way are eligible to be written to the ledger. Rule families then apply the business rules in code and return the same conclusion for the same input on every run. Each family has an explicit hold outcome, which refers the case to a person where the rules do not resolve it.\u003C\u002Fp>\n\u003Cp>Certain questions cannot be resolved by rules, such as whether a document is a bill, or which of two printed dates is the invoice date. These are referred to a typed decision model, and Jev, a model developed by TypeSafe and available through OpenRouter, is being tested in this role. Jev answers a fixed-choice or yes\u002Fno question, selects only from the candidates supplied by code, and returns a confidence score. Where the confidence falls below a set threshold, the answer is treated as uncertain and a person decides. The typed model supplies facts to the rule families and does not evaluate the decision itself, as a probabilistic evaluation of the full decision would remove the consistency the rule families are intended to provide.\u003C\u002Fp>\n\u003Cp>The LLM agent retains the tasks to which it is suited, being the interpretation of unstructured input and the calling of tools. It may call only the tools the decision permits, with the values the decision permits. A required step, such as reading a record back after writing it, is enforced by the runtime as a rule rather than left to the agent as an instruction. The workflow is consequently consistent at each decision point the business has specified, while the agent retains latitude in reading and handling the input.\u003C\u002Fp>\n\u003Ch2>Worked example: supplier bill capture\u003C\u002Fh2>\n\u003Cp>Jev determines whether an emailed document is a bill. Code matches the sender against existing suppliers, and a rule prevents the business itself or its owner from being recorded as the supplier. Code extracts the candidate dates and completes a missing year, and Jev selects between two plausible dates or abstains. Code checks for duplicates using the same key as the accounting system. A final rule family reads only the conclusions of the earlier families and, where all are clear, sends an approval request to a person. Following approval the agent may write the bill, but it cannot mark the task complete until the record it reads back matches what was approved. Each of the failures described above corresponds to one of these rule families.\u003C\u002Fp>\n\u003Ctable class=\"rule-family\">\n\u003Ccaption>Rule family: Bill can be written. One row permits the agent to act; every other row holds the case for a person.\u003C\u002Fcaption>\n\u003Cthead>\n\u003Ctr>\u003Cth scope=\"col\">Is a bill\u003C\u002Fth>\u003Cth scope=\"col\">Supplier valid\u003C\u002Fth>\u003Cth scope=\"col\">Invoice date resolved\u003C\u002Fth>\u003Cth scope=\"col\">Duplicate\u003C\u002Fth>\u003Cth scope=\"col\" class=\"conclusion\">Conclusion\u003C\u002Fth>\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd class=\"conclusion\">Request approval\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>No or unsure\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>Unsure\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>–\u003C\u002Ftd>\u003Ctd>Yes\u003C\u002Ftd>\u003Ctd class=\"conclusion hold\">Hold\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>Current position\u003C\u002Fh2>\n\u003Cp>Runtime enforcement of procedure loading and an approval gate before finance writes are in production. The decision model for bill capture has been designed and has not yet been built, and Jev has been tested offline for routing only. The next step is a shadow evaluation against past runs, and no accuracy figures will be reported until that evaluation is complete.\u003C\u002Fp>\n","von Halle, B. and Goldberg, L. (2009). \u003Cem>The Decision Model: A Business Logic Framework Linking Business and Technology.\u003C\u002Fem> Auerbach Publications.",1288,6,1793536248627]