最后的人类关卡：面向治理自动化的前置部署工程

# The Last Human Gate Forward Deployed Engineering for Governance Automation
Source: [https://arxiv.org/html/2609.29345](https://arxiv.org/html/2609.29345)
September 2026

###### Abstract

Enterprise governance requires decisions, evidence, and accountable authority; it does not require every review task to retain its current human implementation\. We develop a task\-substitution framework for Digital Governance Frameworks \(DGF\), treating each gate as an executable contract\. Substitution requires sufficient accessible information, valid decision and authority checks, and a reduction in total human work after exceptions, verification, correction, and maintenance are counted\. We derive a residual\-work threshold and show why automating most cases can still increase labor\. Forward deployed engineering connects these conditions to an architecture for agents, rule engines, evidence services, and escalation\. DGF\-Bench supplies controlled evidence from 300 synthetic projects and 899 evaluable model–project runs\. Gemini 3\.8 Flash, GPT\-5\.6 Luna, and DeepSeek v4\.1 Flash achieve strict gate success of 94\.98%, 83\.29%, and 74\.18%; complete\-route success is 76\.92%, 42\.33%, and 24\.67%\. A deterministic control passes all 1,700 gates given the supplied rules and structured facts, locating the comparison in execution of a supplied decision kernel\. Evidence audits and 135 repeated runs distinguish correct decisions from reliable execution\. A document counterexample establishes an information\-sufficiency obstruction\. These results support the technical feasibility of replacing human execution of specified governance\-review tasks with agents and software\. The framework specifies a workforce test based on the complete human effort required at fixed output and quality; the present measurements concern review performance\. Sources, dossiers, traces, and analyses are public\.

Keywords:task substitution; forward deployed engineering; AI agents; enterprise governance; human work; DGF\-Bench\.

## 1Introduction: replacing execution, preserving the function

Before an enterprise buys software, connects systems, or releases an application, people review its architecture, security, contracts, cost, and operational readiness\. The required outputs are decisions and their supporting work: identify a missing agreement, reject an unsafe network design, require a recovery test, or authorize a conditional release\. These functions persist even if software performs work previously assigned to analysts, architects, and committee support staff\. A professional title is an organizational allocation of tasks, not a technical specification of how those tasks must be executed\.

This paper argues that a Digital Governance Framework \(DGF\), understood as an enterprise’s connected review gates, is a tractable candidate for early substitution of human review tasks by agentic systems\. The claim concerns execution: an agent that produces a draft for someone to redo has supplied assistance; a system that completes an accepted review has performed that task\. A workflow can contain substituted tasks and remaining human decisions at the same time\. The relevant system can combine language models, deterministic software, and escalation\. Replacing every rule check with a language\-model call is neither necessary nor desirable\.

Figure[1](https://arxiv.org/html/2609.29345#S1.F1)makes this organization concrete: the same project dossier moves through several specialist reviews, each producing a decision and its supporting record\. Buying a solution, connecting systems, and building an application require different review sequences\. General consolidates the preceding reviews into the route’s governance record\.

BUYPurchase a solutionProcurementLegalComplianceSecurityITGeneralINTEGRATEConnect existing systemsITArchitectureSecurityLegalComplianceGeneralBUILDDevelop an applicationITArchitectureSecurityTechReadinessGeneralAt each gate:inspect the dossier; record findings, evidence, actions, and a decision\.Figure 1:Three DGF workflows evaluated in DGF\-Bench\. A project follows the route matching its need\. Arrows show review order and information handoffs; General consolidates preceding reviews\. The benchmark runs all scheduled gates, including after a refusal\. These are example governance routes, not automatic approvals or a universal enterprise standard\.The DGF organizes work into dossiers, policies, named authorities, bounded decisions, and recorded handoffs\. These interfaces give engineering a concrete starting point\. Operational substitution requires accessible facts, manageable exception work, faithful evidence, and authorized commitments\. Each requirement identifies an implementation task and an acceptance criterion\. The current human allocation can change as a software implementation meets those criteria\. The proposed priority of DGF relative to other business functions is a comparative adoption hypothesis to be evaluated across deployment settings\.

We connect three contributions\. First, a gate\-contract formulation identifies information, validity, and authority requirements for delegating review execution\. A source counterexample shows when no reviewer can satisfy a fixed decision contract from the permitted information\. Second, a complete labor account gives a substitution threshold: reducing routine execution only reduces required human work if exception handling, verification, correction, and support remain below a computable budget\. Third, DGF\-Bench provides a public, controlled measurement of specified review tasks and their failure modes, including a deterministic control and repeated trajectories\. The purpose of linking them is to make the route from an agent score to a workforce claim inspectable; none of the three substitutes for the others\.

### 1\.1Research questions and units of analysis

We organize the argument around three questions with different observational units\.*First, can software execute a specified gate contract?*Its unit is a review occurrence, with fixed inputs, rules, and acceptance conditions\. DGF\-Bench measures this question in a synthetic environment\.*Second, can that execution remain dependable across a project?*Its unit is the complete route, including the evidence and conditions passed between gates\. Route success and repeated trajectories address parts of this question\.*Third, does deployment reduce the human work required to deliver the governed output?*Its unit is an operating population over a stated period\. Answering it requires a labor account, including work added outside the nominal review team\. This third quantity is not present in an API trace\.

The units cannot be exchanged without assumptions\. Five thousand scored gates are not five thousand independent companies\. A successful run on a generated dossier is not a measured number of hours saved\. A refusal may be a successful review even though the underlying project does not proceed\. Defining these distinctions makes a positive replacement claim more precise: software can execute an accepted task while humans remain responsible for setting its scope, maintaining its infrastructure, or resolving a subset of exceptions\.

Table 1:Claim structure and evidence required\. A result at one level does not supply the missing observation at another\.The central thesis is consequently about the implementation of a function\. Organizations may still require architecture assurance, a security judgment, or evidence of operational readiness\. That continuing requirement does not establish that every dossier needs the same manual execution\. At the same time, describing a function as a contract does not make its evidence available or resolve policy disagreement\. The proposed engineering work is to turn the subset with adequate information and delegated authority into executable review services, and then measure the cost of the boundary that remains\.

The paper proceeds from the contract to the labor account, then to its FDE implementation and experimental evidence\. We conclude with a deployment test for the workforce hypothesis\. This manuscript synthesizes the longer*The Last Human Gate*and replaces the previous empirical companion in the repository\. The versions share their experimental record; the expanded exposition reports no additional model calls or enterprise observations\.

## 2Related work and the evaluation boundary

### 2\.1From task automation to the organization of work

Task\-based accounts separate the displacement of existing work from changes in demand and the creation of new tasks\([Acemoglu and Restrepo, 2019](https://arxiv.org/html/2609.29345#bib.bib1)\)\. That distinction matters for governance: an automated review can remove execution hours while the organization expands its project portfolio or assigns the released capacity elsewhere\. We study the labor required for a comparable governed workload, before interpreting actual employment\. This fixes an accounting question rather than assuming that every efficiency gain becomes a redundancy\.

Automation can also leave difficult monitoring and intervention work behind\([Bainbridge, 1983](https://arxiv.org/html/2609.29345#bib.bib2)\)\. A routine\-case success rate does not say whether the remaining cases are more expensive than average\. The selection identity in Section[4](https://arxiv.org/html/2609.29345#S4)makes that concern explicit through the share of baseline labor located in exceptions\. Sequential task assignment and complementary quality requirements motivate treating handoffs and bottlenecks as part of the process\([Demirer et al\., 2026](https://arxiv.org/html/2609.29345#bib.bib5);[Gans and Goldfarb, 2026](https://arxiv.org/html/2609.29345#bib.bib7)\)\. Our contribution applies these questions to a defined governance task and reports the quantities needed to move from an execution claim to a net\-work claim\. The equations are accounting relationships and conditional thresholds, not an alternative macroeconomic model\.

### 2\.2Governance gates and executable process obligations

Stage\-gate organization predates language\-model agents\([Cooper, 1990](https://arxiv.org/html/2609.29345#bib.bib4)\)\. It supplies a recognizable decision boundary: a proposal arrives with evidence, reviewers assess it, and a decision controls the next step\. Business\-process compliance research studies how obligations can be represented and monitored during execution\([Ly et al\., 2015](https://arxiv.org/html/2609.29345#bib.bib11)\)\. Agentic business\-process management places agents within a broader process\-engineering agenda\([Calvanese et al\., 2026](https://arxiv.org/html/2609.29345#bib.bib3)\)\. These traditions provide the process foundations for the task\-substitution question studied here\.

The question here is what must hold when execution of such a boundary is transferred from people to software\. A review can include both a deterministic policy kernel and interpretation of evidence whose form is less regular\. The kernel may be compiled into ordinary software; an agent may recover candidate facts, investigate inconsistencies, or assemble a justified record\. The experiment supplies formalized policies and structured facts\. Its rules control identifies the executable decision kernel; the agent runs measure alternative implementations of the review contract under that same information condition\. The contribution of agents to recovering less structured facts is a separate comparison specified in Section[7](https://arxiv.org/html/2609.29345#S7)\.

### 2\.3Enterprise\-agent benchmarks

WorkArena evaluates browser\-based tasks on enterprise software, using ServiceNow as its environment\([Drouin et al\., 2024](https://arxiv.org/html/2609.29345#bib.bib6)\)\. ITBench concerns operational IT scenarios in site reliability, compliance and security operations, and financial operations\([Jha et al\., 2025](https://arxiv.org/html/2609.29345#bib.bib9)\)\.τ\\tau\-bench evaluates policy\-guided interactions among tools, agents, and simulated users, and explicitly studies consistency across repeated trials\([Yao et al\., 2024](https://arxiv.org/html/2609.29345#bib.bib14)\)\. These benchmarks establish important neighboring evaluation problems\. Table[2](https://arxiv.org/html/2609.29345#S2.T2)locates DGF\-Bench by task and acceptance boundary, rather than comparing incompatible scores\.

Table 2:Neighboring evaluation tasks\. The descriptions concern the cited releases; no cross\-benchmark performance ordering is inferred\.The distinction is consequential\. A governance agent that asks for a recovery test has completed one kind of work; an operational agent that repairs the service and demonstrates recovery has completed another\. DGF\-Bench scores the former contract and does not take credit for the latter\. Likewise, the current review tools expose structured facts rather than requiring a browser agent to find every fact in a production interface\. These choices define the measured task; they prevent interpreting a higher percentage as superiority over an agent evaluated on a broader or less prepared task\.

### 2\.4Evidence quality and useful agent comparisons

Work on attribution and citation quality separates a correct answer from a supported one\([Gao et al\., 2023](https://arxiv.org/html/2609.29345#bib.bib8);[Rashkin et al\., 2023](https://arxiv.org/html/2609.29345#bib.bib13)\)\. The separation is central to an auditable review: the final disposition and the record supporting it can fail independently\. Our frozen strict endpoint requires observed sources and conforming excerpts\. A separate structural audit tests how sensitive the conclusions are to field order and numeric representation\. It does not convert lexical or structural matching into an expert judgment about every premise\.

Agent evaluation also benefits from simple baselines and explicit resource accounting\([Kapoor et al\., 2024](https://arxiv.org/html/2609.29345#bib.bib10)\)\. We therefore report the deterministic control, failed attempts, inference costs, and repeated trajectories together with model scores\. In this study the strongest claim is that specified review tasks can execute in software and that their reliability can be inspected at several levels\. Establishing the incremental value of an agent for less structured evidence requires the matched\-information extension in Section[7](https://arxiv.org/html/2609.29345#S7)\. The labor account then supplies a further test: whether the resulting system transfers work without recreating equivalent hours in verification, exceptions, or maintenance\.

## 3A gate as a substitutable contract

A DGF is an organization’s composition of review checkpoints\. It is not a universal sequence: enterprises can merge, split, or reorder gates while preserving their obligations and information dependencies\. Typical tasks include supplier due diligence, contractual checks, technical architecture review, security assessment, readiness verification, and final consolidation\. We study three example routes, Buy, Integrate, and Build; the argument applies to the review contract, not to these particular names\.

### 3\.1The work behind the checkpoints

A project owner assembles a dossier describing the proposed change: its need, users, budget, technical design, supplier commitments, and readiness evidence\. A specialist gate examines the parts relevant to its policy and returns a recorded opinion\. The same dossier can therefore receive different findings from Architecture, Security, and Legal without those reviews being duplicates\. General combines their effective opinions with its own governance checks\. Table[3](https://arxiv.org/html/2609.29345#S3.T3)explains the eight families represented in the experiment\.

Table 3:What each benchmark gate reviews\. Questions summarize the supplied policies; listed records and checks are examples, not exhaustive definitions of the professions\.The five dispositions express different completed review outcomes\.GOpermits proceeding within the reviewed scope\.GO\_WITH\_RESERVATIONSretains conditions alongside that permission\.REWORKrequests changes to the submitted proposal;SUSPENSIONwaits for a prerequisite;NO\_GOrejects proceeding as submitted\. The policy and mandate determine which outcome is admissible\. The experimental schedule collects every review in the route, including after a blocking opinion, to evaluate the remaining specialist work and final consolidation\.

Four responsibilities clarify the unit of substitution: preparing the dossier, examining it, making an authorized decision effective, and carrying out the resulting actions\. An organization may allocate several of these responsibilities to one person, or distribute them across project teams, specialists, and decision owners\. In the experiment, the agent performs the specified review and can use authorized simulated actions\. The generator supplies the dossier; the trace records requested remediation and commitments\. A deployment’s labor account follows each responsibility wherever it is performed\.

For example, a readiness review may identify a draft runbook, require its completion, and record an authorized conditional decision\. The review has then produced its required output; the runbook still has an owner and an open completion condition\. The Falcon trace in Section[6](https://arxiv.org/html/2609.29345#S6)records precisely this separation\. It explains how an agent can replace a review task while another person or system continues the operational work triggered by that decision\. Extending substitution to that operational work requires its own accepted output and authority\.

### 3\.2The review contract

###### Definition 1\(Review contract\)\.

A gate contract specifies permitted evidence and tools, a versioned policy, an authorization mandate, and the conditions for accepting an output\. The output contains a disposition, findings, required actions, supporting evidence, and an authorization record\. Its accepted form and substantive requirements are fixed before evaluating a proposed replacement\.

In DGF\-Bench the dispositions areGO,GO\_WITH\_RESERVATIONS,REWORK,SUSPENSION, andNO\_GO\. A refusal can be a correct completed review\. Conversely, an approval is unsuccessful if it omits a mandatory defect or exceeds the reviewer’s mandate\. Completing the review is distinct from implementing the remediation it requests\. The same boundary must apply to human and software work when estimating substitution\.

### 3\.3What is held fixed when execution changes

A replacement is evaluated on a declared population: for example, supplier reviews below a specified purchasing threshold, or architecture reviews of services using a defined platform\. The population includes difficult cases, missing evidence, and legitimate refusals\. Excluding these after observing failures would change the task being automated\. A narrower deployment can still be useful, but its scope and excluded work must be reported explicitly\.

The contract also identifies a review’s start and end\. Reading a complete dossier and issuing an opinion is a different work package from obtaining that dossier, negotiating a clause, or verifying a corrected deployment\. A study of the first package can establish execution of that package\. It cannot silently count the other packages as replaced\. Conversely, the continued need for remediation does not mean that issuing the review remains a human task\. These distinctions permit substitution to be measured at useful intermediate boundaries\.

Versioning makes the comparison inspectable\. A decision record should identify the policy, source state, and mandate under which it was produced\. A later policy change may justify a different decision on the same project; it does not retroactively make the earlier system inconsistent\. If documents change during a review, the contract must specify whether the agent freezes an evidence version, refreshes affected checks, or reopens the gate\. Such requirements apply to the whole implementation, including its tools and controller\.

### 3\.4Three conditions for a replacement

Information\.The permitted observations must contain what the policy needs, or the contract must allow a request for information or abstention\. A model cannot recover a missing fact merely by generating a plausible answer\. Source accessibility matters as much as physical file existence; the agent may lack permission to read a relevant record\.

Validity\.The system must produce outputs satisfying the review’s quality and service requirements on its declared operating population\. These include evidence support and the handling of uncertainty, not just a disposition matching a label\. A machine\-readable schema can reject malformed records but cannot by itself prove the substantive decision correct\.

Authority\.A valid mandate must permit the system’s action\. An agent’s proposal and the mechanism that makes a commitment effective are separate\. Deterministic enforcement can block forbidden commitments even when an agent requests them; a final authorized output does not establish that the model respected authority unaided\. Delegating bounded execution does not eliminate the organization’s accountability or resolve deployment\-specific legal requirements\.

These conditions describe functional replacement\. Net substitution of human work additionally requires a reduction in all human hours used to deliver that function, as derived next\. Removing a routine reviewer while adding equivalent effort to project teams or support providers moves the work rather than reducing it\.

Quality and coverage must be reported together\. An implementation that escalates every case may avoid unauthorized approvals while performing almost none of the review itself\. At the other extreme, an implementation that approves every case completes many transactions but does not preserve the governance function\. An abstention is valid only when the contract permits it for the observed information or uncertainty; the resulting human investigation still belongs in the labor account\. Correct refusals, permitted abstentions, unresolved reviews, and technical failures therefore require distinct outcome labels\.

For an engineering comparison, acceptance is assessed on the final record and the path by which it became effective\. If an enforcement tool rejects a forbidden request, the system has preserved that authority boundary\. The rejected request remains evidence about the model’s behavior\. Similarly, a corrected evidence excerpt can make the final record usable while revealing a need for extra verification\. Reporting only the final label would conceal these different mechanisms and their operating costs\.

### 3\.5An information obstruction

LetI⁡\(x\)I\(x\)denote all observations permitted in an evaluation condition for underlying casexx, andV⁡\(x\)V\(x\)the set of outputs accepted by its fixed contract\. Policy and mandate are held fixed\.

###### Proposition 1\(Indistinguishable cases\)\.

If two admissible cases satisfyI⁡\(x1\)=I⁡\(x2\)I\(x\_\{1\}\)=I\(x\_\{2\}\)butV⁡\(x1\)∩V⁡\(x2\)=∅V\(x\_\{1\}\)\\cap V\(x\_\{2\}\)=\\varnothing, no system using onlyIIcan guarantee a valid output on both\.

###### Proof\.

Equal observations imply equal output distributions, including for a deterministic system\. Guaranteed validity on both cases would require one distribution to assign probability one to both disjoint accepted sets, which is impossible\. ∎

This elementary observation is an operational test for an automation boundary, not a new general impossibility theorem\. Our offline counterexample makes it concrete: two variants have identical extracted text in all 26 Word documents, but changing the underlying supplier due\-diligence status, recorded in CSV evidence, changes the fixed reference decision from GO to REWORK\. A condition restricted to those Word texts therefore cannot reproduce both reference decisions\. Allowing the CSV, or changing the contract to accept a justified request for missing information, changes the task\. For the fixed reference test, the accepted disposition sets are disjoint\. This obstruction applies to a human reader as well as a model; it identifies a deficient information interface\.

### 3\.6Why the DGF is a candidate

Table[4](https://arxiv.org/html/2609.29345#S3.T4)turns the claim that DGF is suitable for automation into properties that can be checked in an organization\. These are engineering advantages when present, not guarantees that every enterprise already has clean rules and accessible evidence\.

Table 4:Properties that make a governance workflow a candidate for task substitution\.These properties make the workflow an engineering candidate because its obligations can be named and inspected\. They do not require a single agent to perform every operation\. A rule engine can implement an explicit threshold; an agent can investigate a narrative discrepancy; an authorization service can enforce the resulting scope\. The relevant comparison concerns whether the combined implementation executes the accepted work at the required quality and resource cost\. The benchmark’s deterministic control is consequently informative about the formalized decision kernel, even though it cannot establish the benefit of language models for extracting facts or resolving ambiguous policies\.

At route level, replacement also requires compatible handoffs\. An upstream decision may be valid only subject to a condition that a later gate must verify\. Dropping that condition changes the governed output\. Merging two software services is acceptable if both obligations remain enforced; skipping a required check is not\. Because failures and missing evidence can propagate, whole\-route evaluation is necessary alongside individual gate scores\. Multiplying average gate success rates would require assumptions about dependence that this benchmark does not establish\.

## 4When agents replace human gate work

#### A complete account\.

At fixed case volumeλ\>0\\lambda\>0, leth0\>0h\_\{0\}\>0be mean baseline handling hours\. A frozen routing rule sends a fractionqqof cases to substantive human exception handling\. LethEh\_\{E\}be complete human hours on those cases,hRh\_\{R\}ordinary\-path human review, andhWh\_\{W\}additional rework per case\. Recurring human upkeep isBHB\_\{H\}in the baseline andBAB\_\{A\}after deployment\. Then

LH=λ​h0\+BH,LA=λ⁡\{q​hE\+\(1−q\)​hR\+hW\}\+BA\.L\_\{H\}=\\lambda h\_\{0\}\+B\_\{H\},\\qquad L\_\{A\}=\\lambda\\\{qh\_\{E\}\+\(1\-q\)h\_\{R\}\+h\_\{W\}\\\}\+B\_\{A\}\.\(1\)Exceptions include their preliminary review; ordinary review includes mandatory signatures and expected sampled audits\. Rework, downstream repair, supplier effort, evaluation, and policy maintenance are allocated once across the common process boundary\. Changing a department or job title does not remove the hours\. Initial implementation is reported separately for a transition\-cost calculation; recurring adaptation belongs inBAB\_\{A\}\.

The fraction of cases retained by humans is generally different from the fraction of work retained\. LetTTbe baseline handling time,JJindicate exception routing, andh0=𝔼⁡\[T\]h\_\{0\}=\\mathbb\{E\}\[T\]\. Define the residual’s baseline labor shareϕ=𝔼⁡\[T​J\]/h0\\phi=\\mathbb\{E\}\[TJ\]/h\_\{0\}, its effort multiplierη=hE/𝔼⁡\[T∣J=1\]\\eta=h\_\{E\}/\\mathbb\{E\}\[T\\mid J=1\], and the ordinary group’s retained review fractionμ=hR/𝔼⁡\[T∣J=0\]\\mu=h\_\{R\}/\\mathbb\{E\}\[T\\mid J=0\]\. Assume both conditional baseline means are positive and0<q<10<q<1; Equation \([1](https://arxiv.org/html/2609.29345#S4.E1)\) covers the other cases\. Withr=hW/h0r=h\_\{W\}/h\_\{0\}andbs=Bs/\(λ​h0\)b\_\{s\}=B\_\{s\}/\(\\lambda h\_\{0\}\), the workload ratio is

ρ:=LALH=ϕ​η\+\(1−ϕ\)​μ\+r\+bA1\+bH\.\\rho:=\\frac\{L\_\{A\}\}\{L\_\{H\}\}=\\frac\{\\phi\\eta\+\(1\-\\phi\)\\mu\+r\+b\_\{A\}\}\{1\+b\_\{H\}\}\.\(2\)This is an accounting identity, not an estimated effect of agents\.

Table[5](https://arxiv.org/html/2609.29345#S4.T5)identifies what must be recorded to use the identity in an organization\. A common case identifier links human activities before and after routing\. The comparison follows the same work across teams and suppliers, rather than assuming that an hour removed from one department has disappeared from the process\.

Table 5:Operational measurements behind the labor account\. Conditional means use the same frozen routing partition; time categories must not overlap\.###### Proposition 2\(Selection and the substitution frontier\)\.

LetT≥0T\\geq 0be integrable with positive mean, and lete⁡\(t\)=Pr⁡\(J=1∣T=t\)e\(t\)=\\Pr\(J=1\\mid T=t\)\. Under the definitions above,

ϕ=q\+Cov⁡\(T,e⁡\(T\)\)h0\.\\phi=q\+\\frac\{\\operatorname\{Cov\}\(T,e\(T\)\)\}\{h\_\{0\}\}\.\(3\)Thus routing that is nondecreasing in baseline effort retains at least as much baseline labor as its share of cases\. For any target fractional workload reductiond∈\[0,1\]d\\in\[0,1\], achievingLA≤\(1−d\)​LHL\_\{A\}\\leq\(1\-d\)L\_\{H\}is equivalent to

ϕ​η\+\(1−ϕ\)​μ\+r\+bA≤\(1−d\)​\(1\+bH\)\.\\phi\\eta\+\(1\-\\phi\)\\mu\+r\+b\_\{A\}\\leq\(1\-d\)\(1\+b\_\{H\}\)\.\(4\)

###### Proof\.

Conditional expectation gives𝔼⁡\[T​J\]=𝔼⁡\[T​e​\(T\)\]\\mathbb\{E\}\[TJ\]=\\mathbb\{E\}\[Te\(T\)\]\. Expanding the covariance and using𝔼⁡\[e⁡\(T\)\]=q\\mathbb\{E\}\[e\(T\)\]=qproves Equation \([3](https://arxiv.org/html/2609.29345#S4.E3)\)\. For independent copiesT,T′T,T^\{\\prime\}, twice this covariance is𝔼⁡\[\(T−T′\)​\(e⁡\(T\)−e⁡\(T′\)\)\]\\mathbb\{E\}\[\(T\-T^\{\\prime\}\)\(e\(T\)\-e\(T^\{\\prime\}\)\)\], which is nonnegative wheneeis nondecreasing\. Splittingh0h\_\{0\}between the two routing groups yieldsq​hE/h0=ϕ​ηqh\_\{E\}/h\_\{0\}=\\phi\\etaand\(1−q\)​hR/h0=\(1−ϕ\)​μ\(1\-q\)h\_\{R\}/h\_\{0\}=\(1\-\\phi\)\\mu\. Substitution into Equation \([1](https://arxiv.org/html/2609.29345#S4.E1)\) proves Equation \([2](https://arxiv.org/html/2609.29345#S4.E2)\); multiplication by its positive denominator gives the target condition\. ∎

The practical consequence is that an agent success rate cannot be read as the percentage of human labor removed\. For example, 20% of cases retain 40% of baseline labor when their baseline handling time is twice the overall mean\. If their post\-deployment effort rises by 50%, those exceptions alone consume 60% of baseline handling hours\. This is the mechanism by which a small exception queue can prevent a large workforce reduction\.

The selection distinction is measurable before interpreting any automation score\. Apply a candidate routing rule to cases for which baseline effort is recorded, then compare the hours associated with its residual against total hours\. This estimatesϕ\\phifor that partition; deployment is still needed to estimateη\\etaandμ\\mu\. If the routing rule or case mix changes, the partition must be remeasured or reweighted\. Holdingqqconstant is insufficient: two queues containing the same number of cases can retain different shares of baseline labor\. Random auditing can add another reason for human involvement without making those selected cases inherently difficult\.

#### Reliability consumes the same budget\.

If erroneous accepted outputs occur on a fractionppof all cases and cause additional human repair averaginghCh\_\{C\}hours conditional on such an error, their contribution torrisp​hC/h0ph\_\{C\}/h\_\{0\}, counted once\. This links execution reliability to the labor target, but does not make low repair cost a quality guarantee\. An undetected harmful error is unacceptable even if it consumes no repair hours\. Strict benchmark failures, human escalations, and erroneous accepted outputs are different events; the experiments do not measure deployment values ofqqorhCh\_\{C\}\.

#### Coverage does not determine required labor\.

The extended manuscript’s reproducible synthetic example allocates 140 baseline FTE across nine governance populations, at 120 useful hours per FTE per month\. Each population has 100 pooled review visits, exception fractions from 0\.16 to 0\.33, and exception baseline means twice its overall mean\. The workload\-weighted exception fraction is 23\.43%, while the groups retain 46\.86% of baseline labor\. With these partitions unchanged, the calculated requirements are shown in Figure[2](https://arxiv.org/html/2609.29345#S4.F2)\. The scenario parameters\(η,m,hW,BA\)\(\\eta,m,h\_\{W\},B\_\{A\}\)are respectively\(0\.5,0\.10,0,0\)\(0\.5,0\.10,0,0\),\(1,0\.10,0,120\)\(1,0\.10,0,120\),\(1,0\.10,0\.5,120\)\(1,0\.10,0\.5,120\), and\(1\.5,0\.35,2,240\)\(1\.5,0\.35,2,240\)\. HerehR=m​h0h\_\{R\}=mh\_\{0\}, sommdiffers from the group\-relativeμ\\mu;hWh\_\{W\}is hours per case andBAB\_\{A\}hours per population per month\. Baseline upkeep is zero\. The paired population vectors are baseline FTE\(10,10,30,20,10,25,15,10,10\)\(10,10,30,20,10,25,15,10,10\)andq=\(0\.22,0\.33,0\.18,0\.16,0\.22,0\.24,0\.26,0\.33,0\.33\)q=\(0\.22,0\.33,0\.18,0\.16,0\.22,0\.24,0\.26,0\.33,0\.33\)\.

Figure 2:Illustrative human\-work requirements with the same case partition: baseline 140 FTE; four operating assumptions produce 43\.52, 85\.32, 89\.07, and 168\.92 FTE\. The dashed line is the author’s 80% reduction target, not a fitted forecast\. Parameters and calculation are released\.These are sensitivity calculations using declared assumptions, not measurements or forecasts\. The comparison establishes a useful non\-identification result: even fixed coverage and a fixed baseline case partition do not determine the sign of the labor effect\. Their associated quality is not estimated\. A deployment must measure both the contract outcomes and the complete account to identify whether execution has actually been substituted at acceptable quality\. None of these four scenarios reaches an 80% reduction\. Withϕ≃0\.4686\\phi\\simeq 0\.4686and no other residual burden, that target already requiresη≤0\.20/ϕ≃0\.427\\eta\\leq 0\.20/\\phi\\simeq 0\.427\. Thus the forecast requires further reduction in exception effort or in its retained labor share, even before allowing for ongoing review and support\.

#### A worked calculation\.

The Architecture population supplies a self\-contained example of the normalization\. Its 30 baseline FTE giveh0=30×120/100=36h\_\{0\}=30\\times 120/100=36hours per visit\. Withq=0\.18q=0\.18and residual baseline effort twice the overall mean, an exception originally requires 72 hours\. The ordinary group’s baseline mean must therefore be\(36−0\.18×72\)/0\.82≃28\.0976\(36\-0\.18\\times 72\)/0\.82\\simeq 28\.0976hours\. The two conditional means reproduce the same 36\-hour baseline; assigning 36 hours to both groups would erase the selection effect\.

Under the first scenario,η=0\.5\\eta=0\.5reduces exception effort to 36 hours, whilem=0\.10m=0\.10gives ordinary review of 3\.6 hours\. Mean human effort is0\.18×36\+0\.82×3\.6=9\.4320\.18\\times 36\+0\.82\\times 3\.6=9\.432hours, hence100×9\.432/120=7\.86100\\times 9\.432/120=7\.86FTE\. Under the second scenario, exceptions retain 72 hours: case work requires 13\.26 FTE, and 120 monthly support hours add one FTE, producing 14\.26\. The third scenario adds 0\.5 hours on each of 100 visits, or50/12050/120FTE, producing 14\.68 after rounding\. Coverage is unchanged throughout\. These calculations use the declared synthetic parameters and illustrate how effort and upkeep, rather than the case fraction alone, determine the result\.

The first scenario also illustrates why review ratios need their denominator stated:m=3\.6/36=0\.10m=3\.6/36=0\.10, whereasμ=3\.6/28\.0976≃0\.1281\\mu=3\.6/28\.0976\\simeq 0\.1281\. Substitutingmmforμ\\muin Equation \([2](https://arxiv.org/html/2609.29345#S4.E2)\) would undercount review\. The group\-relative form makes selection explicit; the dimensional equation is usually the simplest way to calculate an observed operating total\.

#### Volume and the support boundary\.

Recurring support is not automatically proportional to visits\. With otherwise fixed conditions, more visits spread the sameBAB\_\{A\}over more cases and lower its normalized burdenbAb\_\{A\}\. Additional policy variants, incidents, or service requirements can instead increase support\. The model therefore retains the recorded hours; it does not assume that scale makes them vanish\. Shared services must be allocated once across the evaluated workflow, including supplier work needed to produce and maintain usable evidence\.

Repeated reviews also require a consistent convention\. A failed submission may generate a new visit or additional rework within its original visit, but the same activity cannot be counted both ways\. If automation changes visit frequency, equal visits no longer mean equal governed output\. The deployment comparison should then follow complete cases to the same endpoint and account for each regime’s visits\. The fixed\-volume frontier isolates the effort mechanism; it does not remove the need to measure changed demand or repeated work\.

### 4\.1Route volume and the allocation of recurring support

The same platform can have different effects on the human work required by different routes\. The extended manuscript’s second illustration makes this visible using one specialist team with 100 monthly review visits: five Integrate and 95 Build\. Each visit has a baseline mean of 24 hours, so the combined 2,400 hours correspond to 20 FTE at the same 120\-hour convention\. These are selected operating assumptions, with review visits as the unit; the route names do not imply that their observed enterprise frequencies have been estimated\.

Both routes retainhR=2\.4h\_\{R\}=2\.4ordinary review hours andhW=0\.5h\_\{W\}=0\.5additional rework hours per visit\. Each is allocatedBA=66B\_\{A\}=66recurring support hours per month andBH=0B\_\{H\}=0\. Defineκ=𝔼⁡\[T∣J=1\]/h0\\kappa=\\mathbb\{E\}\[T\\mid J=1\]/h\_\{0\}, soϕ=q​κ\\phi=q\\kappaandhE=η​κ​h0h\_\{E\}=\\eta\\kappa h\_\{0\}\. Table[6](https://arxiv.org/html/2609.29345#S4.T6)supplies the remaining inputs and results\. The conditional ordinary baseline means are fixed by the common 24\-hour mean; for Integrate, this gives\(24−0\.60×1\.4×24\)/0\.40=9\.6\(24\-0\.60\\times 1\.4\\times 24\)/0\.40=9\.6hours\. Thus the exception partition and baseline remain coherent\.

Table 6:Synthetic route\-specific labor requirements on the same platform\. The final row changes only Integrate’s visit volume; it is an alternative scale calculation, not a third route added to the 20\-FTE population\.For Integrate at five visits, Equation \([1](https://arxiv.org/html/2609.29345#S4.E1)\) givesLA=5​\{0\.60×33\.6\+0\.40×2\.4\+0\.5\}\+66=174\.10L\_\{A\}=5\\\{0\.60\\times 33\.6\+0\.40\\times 2\.4\+0\.5\\\}\+66=174\.10hours against 120 baseline hours\. Build requiresLA=95​\{0\.14×38\.4\+0\.86×2\.4\+0\.5\}\+66=820\.30L\_\{A\}=95\\\{0\.14\\times 38\.4\+0\.86\\times 2\.4\+0\.5\\\}\+66=820\.30hours against 2,280\. Their combined 994\.40 hours equal 8\.29 FTE and a ratio of 0\.414\. The combined reduction therefore coexists with an increase on the low\-volume route\. At 95 Integrate visits, the same case effort and 66 support hours give a ratio of 0\.930: the larger denominator spreads the fixed support term over more accepted review work\.

This calculation identifies a concrete FDE implementation choice\. Reusing maintained connectors, policy tests, and evidence interfaces can distribute recurring work across a larger review population, while specialized exceptions still require their own effort\. The operating ledger must record that allocation once and retain route\-level results alongside the total\. This lets an organization identify where task substitution already reduces required work and where a different operating design is needed\. Quality and service remain separate acceptance conditions; the table evaluates the labor consequences of the stated assumptions\.

#### From required work to staffing\.

At fixed useful capacityK\>0K\>0, required workload\-equivalent FTE equalL/KL/K\. Under the additional assumptions of interchangeable workers, target utilization0<u≤10<u\\leq 1, no separate coverage constraint, and staffing chosen to minimize labor cost, required headcount is⌈L/\(u​K\)⌉\\lceil L/\(uK\)\\rceil\. Reducing required hours then removes posts when this integer crosses a staffing threshold\. Redeployment or increased demand can absorb the released capacity; they do not make execution of the old tasks indispensable again\. For a finite collection of gates with bounded visit counts, vanishing human case effort leaves a support floorBA/KB\_\{A\}/K; zero total human labor further requires that this support work be eliminated or automated\. These are explicit conditions for displacement, not a claim that current benchmark performance has already satisfied them\.

## 5The FDE implementation: engineering the whole workflow

Forward deployed engineers \(FDEs\) work alongside organizations to turn software capabilities into deployed systems; embedded implementation is explicit in the role described by[Palantir Technologies \(2026\)](https://arxiv.org/html/2609.29345#bib.bib12)\. Here the role has a concrete purpose: construct the information, policy, evidence, and authorization interfaces that let an accepted review be completed without requiring a person to reconstruct it\. The job title itself does not establish an advantage\. The engineering contribution is an operating arrangement: which tasks transfer to software, which commitments that software may make, and who handles the work it cannot complete\.

Figure[3](https://arxiv.org/html/2609.29345#S5.F3)separates responsibilities\. Agents can investigate a dossier, extract candidate facts, interpret narrative material, and propose findings\. Where policies are executable, a deterministic service evaluates them\. Evidence services attach copied source values and locations rather than asking a model to reproduce quotations\. Mandate checks govern commitments\. The system escalates cases for which its evidence or delegated scope is inadequate\. These are proposed deployment components, not a claim that this complete architecture was evaluated by the current benchmark\.

Source accessDocumentsand recordsAgent reviewRead, investigate,proposeContract checksPolicy, evidence,mandateDecision recordEvidenceand conditionsHuman exception handlingMissing facts, disputed policy,or undelegated authorityFigure 3:Proposed gate implementation\. Every human contribution, including support of these services, belongs in the labor account\. Passing a technical check alone is not a certificate of complete substantive correctness\.### 5\.1Specify the transfer before building the agent

The first deliverable is a named task boundary agreed with the process owner\. It identifies the input population, accessible systems, output record, service requirements, and decisions that remain outside the mandate\. “Review an architecture” is too broad to assess a transfer\. “Evaluate this submitted design against these network and recovery requirements, preserve unresolved conditions, and return a supported disposition” identifies observable work\. Implementing the requested design changes is a separate task unless the contract includes it\.

An acceptance set should cover approved, deficient, incomplete, conflicting, and out\-of\-scope inputs\. Changing a material fact should change the required finding or disposition; changing only field order should not alter its meaning\. Missing information must trigger the declared request or abstention behavior\. These proposed tests expose contract defects before a model score is interpreted as substitution\. The policy owner resolves disputed obligations; the engineer records that resolution rather than allowing a model to silently invent policy\.

### 5\.2Make evidence usable without reconstructing the dossier

Source access requires more than a directory of documents\. For every material premise, the implementation identifies its authoritative source, accessible representation, applicable version, and treatment of conflicting observations\. The source counterexample in Section[3](https://arxiv.org/html/2609.29345#S3)gives a direct acceptance test: the permitted interface must distinguish cases whose required outputs differ, or permit an explicit request for the missing information\. Preparing a snapshot manually for every project belongs in the human work account; it cannot be treated as free model input in a deployment comparison\.

The evidence service should preserve the observation used by the reviewer and attach its source location to the finding\. A returned record can contain the case identifier, source version, field path, copied value, and observation time\. This addresses the observed serialization failures without requiring a model to reproduce source text exactly\. However, a copied value can still be irrelevant or incomplete\. Checking that an excerpt was observed and checking that it supports every required premise remain distinct acceptance criteria\.

There is a tradeoff between a uniform evidence interface and the cost of maintaining it\. Normalization may reduce repeated interpretation downstream, while connectors, changing schemas, and access controls add upkeep\. Both effects need measurement\. The interface should report inaccessible or stale sources explicitly; substituting a plausible value would hide the information failure from the next gate\.

### 5\.3Separate policy execution, commitments, and failure handling

When policy is executable, the deterministic control supplies a reason to implement that kernel directly\. Agents can propose findings and gather inputs around it\. This division does not transfer responsibility for choosing the policy: responsible owners must approve its version and exceptions\. Acceptance tests should include threshold cases, conflicts between rules, and cases requiring a refusal\. The released benchmark establishes performance under its supplied policies, not the correctness of an organization’s policy conversion\.

Authority enforcement needs a separate check of who may commit, what scope is covered, and which conditions remain open\. A model asking for approval is not evidence that approval is permitted\. The rejected conditional\-approval requests in the experiment show the practical importance of that distinction\. A denied request must remain denied in the final record; an executed conditional approval must retain the underlying finding until separate evidence establishes closure\. Repeated calls must not create duplicate commitments\.

Failure behavior is part of the same contract\. A timeout, exhausted tool budget, unavailable source, or malformed final record must produce the specified failure state\. In particular, finalization must not silently supply a default approval, as the observed placeholder error illustrates\. More retries may improve completion but consume time and resources; retries cannot resolve a missing mandate or make an unsupported premise true\.

### 5\.4Preserve obligations across gate interfaces

Common interfaces matter even when rollout is incremental\. Consider an Architecture review accepting a design only if a private endpoint is added\. Security needs the condition, its owner, and its fulfillment status; an unqualified approval would change the meaning of the upstream review\. A handoff should therefore preserve the disposition, unresolved findings, actions, evidence references, policy version, and effective authorization\. General must consolidate that state rather than infer closure from the presence of an approval label\.

A useful acceptance test follows one unresolved condition through the entire route\. Its status must change only when the declared closure evidence is supplied\. Another deliberately replays an earlier record after its source or mandate changes: the system should follow the predeclared revalidation rule rather than silently treat an old decision as current\. These are proposed integration tests, not additional experiments reported here\. Their purpose is to prevent local convenience from creating verification work for downstream teams\.

Table 7:Proposed engineering deliverables and acceptance checks\. Human hours are allocated once to the account in Section[4](https://arxiv.org/html/2609.29345#S4); these are deployment requirements, not measured savings\.
### 5\.5Roll out against quality and labor criteria

A proposed rollout starts with a frozen contract and representative operating cases, then tests the interfaces without allowing unapproved commitments\. Shadow operation can reveal incorrect decisions and missing evidence, but it adds an agent beside existing work; it does not by itself demonstrate substitution\. Transfer of a bounded task should begin only under a declared mandate, with the required quality and service criteria fixed beforehand\. The retained human path needs the information necessary to resolve the exception, not merely an error message that forces the specialist to start again\.

Stopping criteria belong in the operating agreement\. Unauthorized commitments, unsupported material findings, loss of open conditions, or failure of a required source trigger the specified containment and escalation response\. Persistent deterioration in quality or service stops expansion even if more cases appear automated\. A change in policy, source interface, or model configuration requires the relevant acceptance checks before expanding its use\. A validator that escalates everything can satisfy a conservative commitment rule while transferring no execution; both acceptance and escalation volumes must be reported\.

The economic check uses the same population and boundary as the baseline\. Record ordinary review, exception handling, additional correction, and recurring engineering separately, including project\-team and supplier effort\. Initial integration is a transition investment; continued adaptation belongs inBAB\_\{A\}\. A reduction in inference cost does not offset an unrecorded increase in specialist hours when the claim concerns human\-work substitution\. If a task no longer needs case\-by\-case human execution, its released hours count even when the organization redeploys the affected staff\. If every output needs a lengthy signature or reconstruction, that work remains inhRh\_\{R\}orhEh\_\{E\}\.

These deliverables explain the proposed DGF\-first strategy\. An FDE implementing an enterprise agent encounters governance during deployment; the interfaces built to navigate its gates can also support execution of their reviews\. Recurring evidence, policies, and decision formats create opportunities for reuse\. High\-volume business operations may nevertheless justify earlier automation\. The claim is a plausible engineering sequence, not an observed adoption ranking\. What ultimately distinguishes substitution is an accepted task delivered with less total human work, rather than the number of reports generated or the engineer’s job title\.

## 6Evidence: executing governance contracts

### 6\.1Design, dossiers, and information conditions

DGF\-Bench tests the execution of a specified review task: inspect permitted evidence, choose a disposition, identify findings and required actions, cite the supporting observations, and respect the authorization contract\. A seeded generator constructs 300 fictional projects, 100 each on Buy, Integrate, and Build routes \(Figure[1](https://arxiv.org/html/2609.29345#S1.F1)\)\. Buy and Integrate each contain six gates; Build contains five, giving 1,700 gate occurrences per model\. The dossiers include project charters and review requests, architecture diagrams, technical designs, supplier and legal records, and operational test evidence\. Decision\-coverage sampling balances applicable outcomes\. Difficulty setting 4 controls generator parameters; it is not a validated scale of reasoning difficulty\. The 300 projects have distinct architecture and complete decision\-fact signatures, although some gate\-level patterns recur\.

Each project begins with canonical facts: an owner, a business context, requested budget, users, data classification, architecture, and operational or contractual constraints\. Templates derive the dossier from those facts\. A Buy case may expose supplier offers, due\-diligence records, and contract status; a Build case may expose readiness tests, network arrangements, and a runbook\. The environment can mark evidence missing, stale, or inconsistent\. The same program defines the public policy and evaluator reference, so successful execution measures conformity to that declared policy rather than independently validated professional judgment\.

Decision balancing broadens coverage of approval, refusal, and intermediate outcomes\. It does not make projects independent samples of enterprise demand\. The released diversity audit finds 267 distinct whole\-case finding patterns among the 300 projects; gate\-specific relevant\-fact signatures include 142 of 200 Compliance cases and 241 of 300 Security cases\. Phase\-adjusted normalized decision entropy ranges from 0\.9971 to 1\.0000\. These statistics describe diversity under the generator’s representation; they do not certify equivalent diversity of organizational contexts or difficulty\. Difficulty 4, for example, sets the pre\-balancing architecture IP\-overlap probability to 0\.20 and shared\-service\-principal probability to 0\.22\. The accepted distribution also depends on decision\-balancing rejection sampling\.

The tested information condition supplies both executable policies and an authoritative structuredREVIEW\_FACTSsnapshot\. Models can read allowed evidence and use simulated enterprise tools; evaluator\-only reference files are inaccessible\. The model is the reviewer, not the generator of the project\. Every gate returns one ofGO,GO\_WITH\_RESERVATIONS,REWORK,SUSPENSION, orNO\_GO\. Correctly refusing a deficient proposal counts as success\. Later gates receive the model’s actual upstream reviews, and General consolidates the route\.

The policy supplies objectives, permitted dispositions, finding identifiers, required actions, and executable rule definitions\. A gate prompt gives the relevant project context and output schema\. The agent chooses which allowed sources to inspect, can query simulated system records or request evidence, and can inspect an authorization mandate\. A final structured submission records its decision, findings, actions, evidence references and excerpts, authorization flag, and rationale\. Simulated actions change only the test environment\. A schema\-valid submission can still be substantively wrong, and requesting an action does not establish its completion\.

Figure 4:Implemented experimental workflow\. A program generates the case and evidence; the tested model investigates and submits reviews; a deterministic evaluator scores the retained trace\. Public authoritative facts are available in addition to documents\.
### 6\.2Execution and scoring protocol

Three exact OpenRouter endpoint identifiers were evaluated on 22–23 September 2026:google/gemini\-3\.8\-flash,openai/gpt\-5\.6\-luna, anddeepseek/deepseek\-v4\.1\-flash\. Temperature was zero, vision wasauto, and each gate permitted at most 20 turns, 40 tool calls, and 8,192 output tokens per turn\. Of 900 planned model–project runs, 899 and their 5,094 gates are evaluable\. One Gemini Integrate run failed at its first gate because of a provider generation error; its six gates are excluded\. Recorded failed attempts remain in the cost accounting and released traces\.

The models are deployed endpoints, without training or fine\-tuning in this study\. Gemini was recorded through Google AI Studio and Luna through OpenAI; DeepSeek used multiple OpenRouter providers\. The identifiers are provider\-reported, not independent audits of model weights\. Gates run sequentially within each dossier, while dossiers can run concurrently\. Interrupted collection resumes completed work and valid gate checkpoints rather than selecting the best answer from competing trajectories\. No final model\-identifier mismatch or agent\-protocol failure is recorded among the evaluable original runs\. Recorded truncated responses number 14 for Gemini, zero for Luna, and two for DeepSeek; they are not equivalent to incomplete dossiers\.

The frozen deterministic evaluator requires a correct disposition, exact finding and action sets, observed evidence references and exact observed field/value excerpts, and the correct authorization indicator\. A*strict gate success*passes every component; a*complete route*passes every gate\. Disposition accuracy alone therefore does not measure a complete review\. Validated conditional approvals can change the effective reference outcome\. A false approval proceeds when that effective reference requires rework, suspension, or refusal; a critical miss omits a finding classified as critical by the policy\.

For a model, strict gate success divides successful gates by all gates in its evaluable dossiers; complete\-route success divides dossiers whose every gate succeeds by the evaluable dossier count\. A six\-gate route therefore contributes six observations to the gate rate, while a five\-gate route contributes five\. Passing four of five gates yields 80% gate success within that case and zero complete\-route success\. Finding and action sets must each attain F1 equal to one; averaging good components does not compensate for a missing required component\. The frozen protocol isDGF\-decision\-v8\.2\-authorized\-review\. Authorization checks replay validated mandates and actions; General uses effective upstream opinions after permitted conditional approvals\.

This separates the quality of the final record from the behavior leading to it\. A tool may reject an impermissible commitment, after which the model submits a valid refusal\. Conversely, a model can write an appropriate explanation but submit the wrong disposition field\. Both the structured outcome and preceding tool events are retained, allowing these mechanisms to be examined instead of inferring them from a single aggregate score\.

### 6\.3Deterministic control and aggregate results

A deterministic control reads the same public snapshots and executes the public policy functions, then writes its predictions before a separate process invokes the frozen scorer\. It does not read hidden references during generation, request optional conditional approvals, or extract facts from documents\. It can quote full snapshots without the models’ per\-turn output\-token limit\. Its perfect score establishes that the formalized review kernel is software\-executable\. The agent comparison therefore measures execution of that supplied kernel and its evidence contract\. An incremental contribution to fact recovery requires the matched\-information comparison specified in Section[7](https://arxiv.org/html/2609.29345#S7)\.

The control constructs findings and aggregates dispositions from the public interface\. It propagates its own preceding decisions to General\. A read guard blocks evaluator\-only files, and generation asserts that the scorer was not imported; a second process then scores the saved outputs\. Retaining the base disposition without requesting optional risk acceptance is permitted, so conforming systems need not submit identical labels when one uses a valid mandate\. The control’s 1,700 strict successes and 300 complete routes demonstrate sufficiency of the prepared policy/fact interface\. Its zero model API expenditure excludes programming and local computation, and it supplies no evidence about the cost of producing those inputs\.

Table 8:Task execution on the original population and repeated trajectories\. Counts preserve the original strict endpoint\. Sensitivity accepts specified structural evidence matches; it is post\-hoc and is not a semantic adjudication\. The deterministic control was not repeated\.#### Overall performance and uncertainty\.

Gemini reaches the correct effective disposition on every evaluable gate and satisfies all non\-evidence components; its 85 strict failures concern evidence conformity\. Its strict gate rate is 94\.98% \(95% interval 93\.86–96\.04\), but only 76\.92% of complete routes pass \(71\.82–81\.34\)\. Luna and DeepSeek also exhibit a large gate–route gap, alongside substantive errors: Luna approves one Legal review despite a missing data\-processing agreement, and DeepSeek submits a placeholderGOat forced finalization when address overlap requiresNO\_GO\. The model comparison therefore distinguishes successful disposition, complete documented review, and dependable execution of a whole route\.

Gate intervals resample whole cases within routes \(2,000 draws, seed 81931\); route intervals use Wilson bounds\. They describe the generated population, retaining within\-project dependence\. They do not treat 5,094 gates as independent organizations\. The common 299\-case comparison preserves the ranking; its paired intervals and complete component tables are released\.

Luna’s strict gate interval is 81\.29–85\.24%, and DeepSeek’s is 71\.88–76\.47%; their route intervals are 36\.87–47\.99% and 20\.13–29\.84%\. Pairwise comparisons resample the same 299 common dossiers together within routes using 10,000 draws and NumPy seed 81931\. Gemini’s gate advantage is 20\.90 percentage points over DeepSeek \(95% interval 18\.30–23\.44\) and 11\.75 over Luna \(9\.62–13\.93\); Luna exceeds DeepSeek by 9\.15 points \(6\.67–11\.63\)\. These comparisons control the case mix shared by the models\. They do not establish a stable ranking over new organizations, later endpoint versions, or different information conditions\.

#### Where performance changes\.

Gate families expose different demands \(Table[9](https://arxiv.org/html/2609.29345#S6.T9)\)\. Gemini passes all IT and Compliance reviews strictly but 85\.43% of Architecture and 87\.96% of General reviews\. Luna exceeds Gemini in Architecture and Tech Readiness while falling behind at Procurement and General\. Thus the overall ordering does not imply dominance on every component of the workflow\. DeepSeek’s Procurement decision accuracy is 97%, while its strict Procurement success is 43%; Luna’s corresponding rates are 96% and 33%\. Evidence handling, rather than disposition alone, accounts for much of this contrast\.

Table 9:Strict gate success by review family \(percent\)\. Columns retain the original generated table order\. Gemini has one fewer Integrate dossier, affecting six of its gate families\.At route level, Gemini completes 87 of 100 Buy, 75 of 99 Integrate, and 68 of 100 Build cases\. Luna completes 20, 52, and 55; DeepSeek completes 13, 32, and 29, each out of 100\. Route length alone cannot explain these differences, because route composition and project contents also change\. Sequential handoffs make an upstream error available to General, but this single handoff condition cannot isolate a causal propagation effect\. Luna’s missed upstreamNO\_GOin General illustrates why a downstream omission may repeat an earlier problem rather than constitute an independent safety event\.

### 6\.4Authorized conditional decisions

The review contract permits an agent to consult a standing mandate and request conditional approval for eligible findings\. Eligibility requires open findings, permission to accept each finding under the public policy, and an active mandate for the particular gate and phase\. The environment checks the request and records its effective authorization state\. The final review retains the finding and the required action even when conditional approval is used\. This operation represents bounded delegated decision\-making within the synthetic workflow\.

Table[10](https://arxiv.org/html/2609.29345#S6.T10)summarizes the released audit of the original retained checkpoints\. Calls and gates are different units: one gate can contain several requests\. An approval is counted as used when a replay\-validated final approval accompanies the model’sGO\_WITH\_RESERVATIONSsubmission\. The all\-gate eligibility denominator can differ between models because authorized upstream decisions affect General’s consolidation\.

Table 10:Conditional\-approval behavior in the original runs\. The final row restricts the comparison to the same 391 eligible non\-General gates in the 299 shared dossiers\. Calls rejected by the environment are recorded separately from final review outcomes\.On the matched opportunities, the corresponding use rates are 100\.00%, 88\.75%, and 51\.41%\. The public contract permits retaining the base decision as well as requesting an eligible approval; use frequency is therefore a behavioral measurement\. Some approvals preserve a disposition that was already conditional\. Subtracting base\-decision agreement from effective agreement would consequently measure a different quantity\. Luna also has one validated approval followed by a finalREWORK, which explains why its 354 validated approval states yield 353 used conditional decisions\.

The recorded outcome belongs to the agent operating with its authority\-enforcement tool\. A rejected request is contained by that tool; a successful request remains subject to its recorded conditions\. The synthetic contract checks that condition strings are nonempty; their operational adequacy has no separate adjudication in this experiment\. These explicit semantics make it possible to examine decision quality, delegated action, and retained obligations separately in a deployment\. The Falcon example below shows one such conditional decision together with its supporting evidence and open action\.

### 6\.5Evidence failures and two inspectable traces

An audit of all 690 gates with a failed evidence component leaves the primary scores unchanged and applies one declared sensitivity rule: accept exact relevant field/value subsets from one observed object despite field order or equivalent numeric serialization\. No quote is repaired, no tool observation invented, and no join across different objects promoted\. This recovers 69 Gemini, 38 Luna, and 52 DeepSeek gates \(Table[8](https://arxiv.org/html/2609.29345#S6.T8)\)\. Gemini’s rate becomes 99\.06% at gate level and 94\.98% at route level\. The interpretation is specific: much of this model’s measured route failure depends on the evidence representation contract\. The audit does not establish full premise coverage or independently validated semantic support\.

The distinction between provenance and support also appears in Procurement\. Across 127 evidence\-failed Procurement reviews, all 205 submitted support entries cite sources actually read and included in the submission\. DeepSeek provides 26 failed support entries citing CSV sources; 25 are literal rows in observed tool output\. The snapshot\-only source\-ID requirement rejects those entries before checking their contents\. Other authentic excerpts omit a decisive field, and some combine values from different objects\. An observed quotation can therefore be contract\-excluded, relevant but incomplete, or structurally nonliteral\. None of these labels alone is a semantic truth judgment\. The released audit preserves these distinctions without adding another recovered\-success rate\.

#### Trace 1: a delegated readiness review\.

InDGF\-BLD\-035200\_build, a generated vendor\-portal project, Gemini’s Tech Readiness review finds a draft runbook\. It namesTR\-OPS\-001, proposesCOMPLETE\_OPERATIONAL\_HANDOVER, and cites the observed value"runbook\_status": "draft"\. After consulting an active mandate, it invokes the conditional\-approval tool with a requirement to approve the runbook before production cutover\. The tool executes the authorization but explicitly leaves the finding unresolved\. The model submitsGO\_WITH\_RESERVATIONSwith the finding and action retained, satisfying the strict contract\. This post\-hoc example demonstrates a performed review and authorized workflow transition, with the runbook condition still open\. Table[10](https://arxiv.org/html/2609.29345#S6.T10)places this event within the complete set of recorded approval requests and final decisions\.

The dossier is Project Falcon, a fictional HR vendor portal for 1,000 users, with a requested budget of EUR 500,000 and confidential data\. Its architecture artifact is reproduced in Figure[5](https://arxiv.org/html/2609.29345#S6.F5)\. All three models strictly pass its five gates, with dispositionsGO,GO,GO,GO\_WITH\_RESERVATIONS, andGOin route order\. This selected case shows a complete successful route; it was not selected to estimate a population rate\. Image availability does not show that image interpretation was necessary, since the models could consult structured facts\.

![Refer to caption](https://arxiv.org/html/2609.29345v1/figures/fig_benchmark_architecture.png)Figure 5:The generated architecture document in Project Falcon’s actual dossier\. The diagram is review evidence, not an independently validated production design\. Identity, application, data, monitoring, backup, and recovery elements contextualize the readiness example\.
#### Trace 2: correct architecture judgment, failed literal proof\.

InDGF\-BLD\-035201\_build, Project Meridian, Gemini reads that an API gateway is required but absent, and that measured latency is 55 ms against a 20 ms target\. It correctly identifiesARCH\-API\-001andARCH\-PERF\-001, proposes adding the gateway and remediating latency, and submitsREWORK\. Two attempted conditional approvals fail: one omits an open finding and the other includes a finding ineligible for risk acceptance\. The final submission complies with the required refusal to proceed\.

Its evidence excerpt putsapi\_gateway\_presentbeforeapi\_gateway\_required; the observed record contains the reverse order\. Both values are correct, but their concatenation is not an exact observed sequence\. Evidence fidelity is 0\.5 across the two findings, while disposition, findings, actions, and authorization all score one\. Strict success is consequently zero, despite a weighted component score of 0\.95\. This trace illustrates why a complete\-review metric must make its representation requirements explicit\. Both examples were chosen after evaluation for explanation; their original paths, outputs, and tool events are released, and unsuccessful cases remain in every aggregate\.

### 6\.6Repeated trajectories, expenditure, and interpretation

The follow\-up fixes 15 existing dossiers, five per route, before collecting three new trajectories for every model–dossier pair: 135 completed runs and 765 gates\. No best\-of\-three selection is used\. Gemini, Luna, and DeepSeek pass respectively 35, 19, and 11 of 45 routes; only nine, three, and zero dossiers pass on all three trajectories\. All follow\-up false\-approval and critical\-miss counts are zero\. Provider routing is not fixed, so these observations measure repeatability of the recorded system rather than intrinsic model randomness\. Original and follow\-up recorded API costs are USD 87\.015829172 and USD 12\.5598870228, totaling USD 99\.58; development, local computation, human review, and deployment are not costed\.

The selection uses sorted dossier identifiers and a fixed random seed, 23092026, before the new outcomes are collected\. Each repetition contains 85 gates per model\. Gemini’s strict success counts are 82, 82, and 81; Luna’s are 73, 71, and 67; DeepSeek’s are 63, 64, and 60\. The corresponding complete\-route counts are 12, 12, and 11; 8, 7, and 4; and 3, 4, and 4\. Pooling the trajectories retains all three runs rather than selecting a successful attempt\. Complete\-route pass/fail varies across repetitions on five Gemini, six Luna, and eight DeepSeek dossiers\. Zero observed all\-three success for DeepSeek is not proof of zero population probability; the follow\-up contains only 15 distinct synthetic projects\.

The follow\-up retains the original endpoints, temperature, vision setting, agent handoffs, and gate resource limits, with three workers and one concurrent dossier per model\. Its archive contains 48 error checkpoints: 46 API\-key\-limit refusals and two provider\-finish errors\. These are not counted as additional completed runs\. Two Gemini trajectories resume seven previously completed gates, retained once in the final outcomes\. Resumption preserves the planned sample; it does not turn failed attempts into independent observations\.

Exploratory intervals resample five whole dossiers within each route, retaining all three trajectories and all gates together \(10,000 draws, seed 24092026\)\. Pooled strict gate success is 96\.08% for Gemini \(95% interval 93\.33–98\.43\), 82\.75% for Luna \(75\.29–89\.80\), and 73\.33% for DeepSeek \(66\.67–79\.61\)\. These rates resemble the original ordering, while the all\-three endpoint exposes dossier\-level repeatability\. Under the same structural sensitivity rule, repeated gate counts rise to 249, 217, and 195 out of 255; only four of Gemini’s ten evidence failures are recovered, compared with 69 of 85 in the original study\. The original recovery proportion is therefore not assumed to generalize unchanged\.

Original recorded expenditure is USD 71\.88 for Gemini, USD 5\.05 for Luna, and USD 10\.09 for DeepSeek; the follow\-up adds approximately USD 10\.39, USD 0\.75, and USD 1\.42, respectively\. Costs include recorded failed attempts and depend on provider routing, caching, and retry history\. They are reproducible accounting observations for these runs, not permanent prices or estimates of cost per employee replaced\. The repeated\-run archive retains key\-limit and provider failures, including resumed prefixes counted once in their completed trajectory\.

The information counterexample in Section[3](https://arxiv.org/html/2609.29345#S3)identifies a different failure boundary: some proposed document\-only inputs cannot determine the required decision\. Together, the observed executions and the source check show both an automatable formalized task and a specific obstruction that must be resolved before extending its scope\. The experiments also separate three engineering objectives: producing the required decision, preserving an accepted evidence record, and delivering the entire route repeatedly\. Improving one does not automatically improve the others\. This decomposition gives an FDE implementation concrete targets for policy execution, evidence services, and exception handling, while the labor account determines whether their combined operation substitutes for human work\.

## 7From task substitution to a workforce hypothesis

The observations support a positive, bounded conclusion: software can execute the specified governance\-review operations in this engineered environment\. The deterministic control makes the case for an executable decision kernel especially clear\. The agents demonstrate another implementation of many of these operations, with measurable differences in evidence handling, reliability, and cost\. These components can be combined in the proposed deployment architecture\. Its operating evaluation measures the effort required to construct and maintain the interfaces when facts and policies arrive in less prepared forms\.

This is also where the claim about human replacement becomes testable\. If a deployed system performs accepted tasks previously executed by people and satisfies the labor inequality at unchanged output and quality, it has substituted for part of their work\. Calling the remaining people supervisors does not restore the eliminated execution hours\. At fixed demand, fewer required hours can support fewer posts; actual headcount also depends on allocation, utilization, redeployment, and new work\. The argument therefore permits substantial workforce displacement without treating it as a measured consequence of this synthetic experiment\.

### 7\.1The 2033 hypothesis and a falsifiable deployment test

The author’s original hypothesis is that the DGF ecosystem will require at least 80% fewer workload\-equivalent FTE by 20 September 2033 than during the reference year ending on 20 September 2026, at comparable governed output, quality, and service\. The boundary includes preparation, exceptions, verification, remediation of review errors, maintenance, supervision, and supplier support\. On an illustrative 140\-FTE baseline, the target is at most 28 FTE\. This is an author\-selected forecast, not an extrapolation fitted to benchmark scores\.

The baseline window has already closed and no enterprise cohort has been enrolled\. Testing this exact dated hypothesis requires auditable historical activity records and a declared population and aggregation rule before observing its endpoint\. Otherwise it cannot be scored as confirmed\. A newly registered baseline can support a separate seven\-year prospective test, but cannot move the date of the original prediction\. A credible test fixes the accounting boundary, useful\-hours conversion, output mix, quality tolerances, and service levels\. It reports the completeLA/LHL\_\{A\}/L\_\{H\}account rather than headcount in a renamed department\. A ratio above 0\.20 at the deadline fails the proposed 80% target; achieving that ratio while degrading the fixed quality or service requirements also fails the substitution claim\. Missing records make the result unassessable, not successful\.

Full elimination of human DGF execution is a stronger, undated conjecture\. It would require both case\-level human effort and the recurring support floor to disappear\. No finite benchmark here establishes that endpoint\. The scientifically actionable question is how much accepted task execution can already be transferred and what prevents further transfer\.

### 7\.2Observing substitution without losing the work boundary

A deployment study needs to observe both accepted output and the effort that produces it\. Begin with a defined population of review obligations, not a list of job titles\. A project may trigger several gates, return for revision, or draw on a shared specialist\. Activity records should preserve those relationships so that the same hour is not counted at every gate and a returned dossier does not disappear from the denominator\. The endpoint is the delivery of the governed work, including obligations left open by conditional decisions\.

The baseline can combine case records, activity logs, timesheets, and supplier records under a common coding scheme\. Evidence preparation, ordinary review, exception work, correction, handoffs, and support need distinct codes\. Shared infrastructure work is allocated once using a declared rule, with an unallocated category when the attribution is unknown\. Unobserved supplier hours are missing observations; a low internal headcount cannot stand in for them\. Initial integration is reported separately from recurring operations, then included in any investment or payback calculation\. A deployment with low steady\-state effort can still have a substantial transition cost\.

There are two different comparisons\. Actual total hours answer how much work the organization performed during the period\. Standardized hours answer how much work comparable output would require\. If case volume falls, simply comparing payroll totals can mistake reduced demand for automation\. Conversely, rising project volume can conceal a reduction in effort per comparable case\. A study should report both quantities, standardize the variable work for route and case mix, and retain a separately measured support term\. Multiplying a fixed support burden by a case\-volume adjustment would erase the very floor the accounting model is intended to expose\.

Quality and service are assessed alongside hours\. Appropriate measures depend on the declared contract, but include missed mandatory findings, invalid commitments, uncompleted obligations, correction after acceptance, and time to a usable decision\. The deployment must predeclare which errors invalidate an output and which service changes are tolerable\. Faster approvals are not an efficiency improvement if blocking defects go undetected\. Equally, a system that escalates every dossier may preserve final decision quality while adding an extra processing layer; the labor account exposes that outcome rather than rewarding abstention alone\.

For an enrolled population, uncertainty in the final workload ratio should include between\-case variation, organizational clustering, and uncertainty in reconstructed baseline hours\. An upper bound at or below 0\.20, with the quality and service conditions met, supports the target for that population\. A lower bound above 0\.20 contradicts it; an interval crossing the threshold is inconclusive\. Missing material work cannot be silently assigned zero\. Attrition, failed deployments, and changes in the suppliers included in the account need explicit reporting\.

Observing a reduction and attributing it to agents are separate steps\. Staged or randomized adoption, when feasible, supplies a comparison for changes that would have occurred anyway\. Otherwise, a study must document contemporaneous process redesign, outsourcing, demand shifts, and other automation\. An organization can meet the workload threshold while the causal share attributable to language models remains unresolved\. Finally, a convenience sample of successful implementations does not establish an ecosystem\-wide forecast\. Such inference requires a declared sampling frame, weights, and coverage of organizations where integration fails or does not occur\. No enterprise observations of this kind are claimed in the present paper\.

### 7\.3The next discriminating experiment

The most useful extension varies information preparation while preserving answerability\. Compare agents receiving structured snapshots with agents receiving the source documents and operational records from which the same facts can be recovered\. Separately vary executable versus natural\-language policy\. Fix source access, mandate, time and tool budgets, and the evidence contract before testing on held\-out cases\. Include the rule engine and any required extraction pipeline in the comparison\. Report decision quality, supported findings, complete routes, abstention, and all engineering and operating costs\.

Table 11:Proposed matched\-information design\. These conditions describe an unexecuted extension, not four completed experiment arms\.Table[11](https://arxiv.org/html/2609.29345#S7.T11)separates policy application from fact recovery\. A versus B changes policy representation while holding information fixed\. A versus C changes information presentation while retaining executable policy\. The fourth condition checks the combined burden\. Access to code execution must be held constant; otherwise a representation comparison also changes tool capability\. Prose policies must preserve thresholds, priority rules, and exceptions, and finding catalogs must not reintroduce the executable predicates in an arm intended to omit them\. These are controls on the experiment, not assumptions that the two representations have already been made equivalent\.

This extension does not require claiming human\-level accuracy\. It asks which parts of a review the system can perform when the required facts are no longer supplied as a ready\-to\-use snapshot\. Our counterexample means that simply deleting snapshots is not a valid design\. The released source audit also identifies runtime tools that can return snapshots, so changing file visibility alone would not isolate the intended condition\. The existing extraction ablation and General\-only intervention are preparations, not additional measured results in this paper\.

The evidence endpoint must also be common across the new conditions\. The frozen benchmark requires some support to name a structured snapshot\. Removing that source while retaining the same identifier requirement would penalize a source\-reading agent even when it found the right fact\. A new contract can instead require an observed source identifier, a field or document span, and a faithfully copied value\. It must separately check whether those values support the finding’s premises\. Applying that contract prospectively creates a new endpoint; it does not retroactively change the original strict scores\.

For the handoff question, replay the General gate under saved model history and a reference history while preserving the same validated upstream conditional approvals\. Replacing a lawful conditional decision with an unconditional blocking reference would change authority as well as information quality\. The intervention should isolate the accuracy and completeness of the handoff, retain identical dossier access and budgets, and use paired repeated trajectories\. Such a design could distinguish propagation of an earlier error from a fresh General\-gate error; the observed whole\-route scores alone cannot identify that causal effect\.

### 7\.4Scope of the observations

The policy, generator, and evaluator use the same declared rule system, so the measured endpoint is conformity to that system\. The 300 synthetic cases are sampled for decision coverage\. The original collection contains one trajectory per model and case across three endpoints; the follow\-up repeats 15 of those dossiers\. The evidence sensitivity analysis applies a specified structural matching criterion\. These choices define the population, information condition, and acceptance rule attached to the reported scores\.

The observed comparison concerns agent and deterministic implementations of review contracts\. Human\-review performance, enterprise operating effort, staffing changes, and the relative adoption speed of different business functions are outside the measured variables\. The deployment protocol specifies how to observe the labor account and evaluate the dated workforce hypothesis\. Review performance and workforce requirements thus have explicit, different measurement procedures\.

## 8Conclusion

Agents can replace human execution of governance\-review tasks when they produce the required decision, findings, evidence, actions, and authorization record under the accepted contract\. DGF\-Bench provides a concrete demonstration of this capability in a controlled environment: the tested agents complete specialist reviews and entire project routes, and the deterministic control executes the formalized policy kernel\. Governance obligations can therefore remain in force while their execution transfers from people to software\.

The DGF is a credible candidate for extending that transfer\. Its recurring dossiers, named review responsibilities, explicit policies, and recorded handoffs give forward deployed engineers identifiable work to implement\. The proposed architecture connects agent investigation to evidence services, policy execution, authority enforcement, and exception handling\. As these components cover more accepted tasks, the share requiring case\-by\-case human execution can decrease across the workflow\. The same reasoning applies to preparation, verification, and support when their own contracts can be fulfilled in software\.

The consequence for work is direct\. At comparable output, quality, and service, a system that satisfies the substitution frontier requires fewer human hours to perform the governed work\. Under the staffing conditions stated in this paper, sufficiently large reductions remove the need for some posts\. Organizations may absorb the released capacity through new demand or redeployment; the execution of the transferred tasks has still been replaced\. The relevant quantity is the complete human\-work account, including the people who operate, maintain, and resolve exceptions around the system\.

The long\-term implication is that agents, integrated with executable policies and delegated authority, can progressively replace human execution across DGF workflows\. The measurements here concern review performance; the magnitude and timing of workforce displacement are specified as deployment hypotheses\. The author’s target of 80% fewer required DGF FTE by 2033 is evaluated against the fixed baseline, output, quality, and accounting boundary defined in this paper\. Complete replacement would additionally require the remaining exception and support work to be executed in software\.

The contribution is a testable path from successful agent reviews to human task substitution: define the contract, establish dependable execution, measure the work that remains, and expand the scope where accepted output requires less human effort\. Human review is an implementation of governance that can change as these conditions are met\.

## Data, code, and attribution

Jeremy Canale is the author:contact@jeremycanale\.com,[https://www\.jeremycanale\.com](https://www.jeremycanale.com/),[https://www\.linkedin\.com/in/jcanale13](https://www.linkedin.com/in/jcanale13)\. The public repository is[https://github\.com/jeremy1392/dgf\-agentic\-bench](https://github.com/jeremy1392/dgf-agentic-bench)\. Its[dgf\-bench\-300\-20260923](https://github.com/jeremy1392/dgf-agentic-bench/releases/tag/dgf-bench-300-20260923)release contains the source snapshot, complete generated dossiers including Word documents and architectures, model traces, failed attempts, scores, and cost ledgers\. Results and reproduction are inresearch/2026\-09\-dgf\-bench/; controls, evidence audits, repetitions, and source checks are inresearch/2026\-09\-followup/\. Reproduce the original runs with the frozen source\. Workforce parameters are inpaper/anc/parameters\.json; this manuscript and its verifier are inpaper2/, and the extended manuscript inpaper/\. Earlier versions remain in repository history\. The author is responsible for the claims and interpretation\.

## Appendix AReproducing the claims from the released artifacts

The public release separates the experimental record from the current development checkout\. Use the frozen benchmark source for the original run; later code changes need not implement the same scoring protocol\. The dataset archive contains every generated dossier, including Word documents, architecture diagrams, policies, mandates, and evaluator references\. The run archive contains model outputs and tool events as well as scores, failures, and cost records\. Per\-file inventories and archive SHA\-256 values identify the inputs before recomputation\.

Table 12:Repository records for the principal claims\. Paths are relative to the public repository; the release linked in the data statement contains the larger underlying archives\.The original offline reproduction script verifies downloads against the inventories, checks the source and dataset identities, and recalculates aggregates and paired comparisons\. The expected denominators are 899 evaluable trajectories and 5,094 gates, with 299 dossiers in the common comparison\. Within the run archive, useanalysis\_20260923\_final; earlier partial exports are retained as historical records\. No new API calls are needed to reproduce these summaries\. Recomputing saved\-score aggregates verifies arithmetic and exclusions; rescoring saved submissions with the frozen evaluator is a separate check of implementation\. Neither operation independently establishes the professional validity of the policy\.

For the repeated runs, keep every planned trajectory and its retained gate prefix once\. Infrastructure errors remain in the archive and cost ledger but do not become extra completed trials\. Reproduce the pooled rates by summing successful gates over 255 gates per model, and complete routes over 45\. For the all\-three endpoint, first group trajectories by dossier and require success in every repetition, then divide by 15\. Resampling must retain this grouping; treating the 45 trajectories as 45 distinct projects would change the uncertainty calculation\.

For the labor figure, the parameter file supplies population FTE, visit counts, exception fractions, conditional effort assumptions, and operating scenarios\. Evaluate the dimensional account separately for each population, sum hours, and divide by the declared 120\-hour monthly FTE convention\. This recovers 43\.52, 85\.32, 89\.07, and 168\.92 FTE\. The computation validates the consequences of the specified assumptions; it does not estimate those assumptions from the benchmark\. The manuscript verifier checks the printed numerical records and citations, while source\-archive compilation checks that the document is self\-contained\.

## References

- Acemoglu and Restrepo \(2019\)Daron Acemoglu and Pascual Restrepo\.Automation and new tasks: How technology displaces and reinstates labor\.*Journal of Economic Perspectives*, 33\(2\):3–30, 2019\.[https://doi\.org/10\.1257/jep\.33\.2\.3](https://doi.org/10.1257/jep.33.2.3)\.
- Bainbridge \(1983\)Lisanne Bainbridge\.Ironies of automation\.*Automatica*, 19\(6\):775–779, 1983\.[https://doi\.org/10\.1016/0005\-1098\(83\)90046\-8](https://doi.org/10.1016/0005-1098(83)90046-8)\.
- Calvanese et al\. \(2026\)Diego Calvanese, Angelo Casciani, Giuseppe De Giacomo, Marlon Dumas, Fabiana Fournier, Timotheus Kampik, Emanuele La Malfa, Lior Limonad, Andrea Marrella, Andreas Metzger, Marco Montali, Daniel Amyot, Peter Fettke, Artem Polyvyanyy, Stefanie Rinderle\-Ma, Sebastian Sardiña, Niek Tax, and Barbara Weber\.Agentic business process management: A research manifesto\.*Information Systems*, 140:102738, 2026\.[https://doi\.org/10\.1016/j\.is\.2026\.102738](https://doi.org/10.1016/j.is.2026.102738)\.
- Cooper \(1990\)Robert G\. Cooper\.Stage\-gate systems: A new tool for managing new products\.*Business Horizons*, 33\(3\):44–54, 1990\.[https://doi\.org/10\.1016/0007\-6813\(90\)90040\-I](https://doi.org/10.1016/0007-6813(90)90040-I)\.
- Demirer et al\. \(2026\)Mert Demirer, John J\. Horton, Nicole Immorlica, Brendan Lucier, and Peyman Shahidi\.Chaining tasks, redefining work: A theory of AI automation\.NBER Working Paper 34859, 2026\.[https://arxiv\.org/abs/2606\.15960](https://arxiv.org/abs/2606.15960)\.
- Drouin et al\. \(2024\)Alexandre Drouin, Maxime Gasse, Massimo Caccia, Issam H\. Laradji, Manuel Del Verme, Tom Marty, David Vazquez, Nicolas Chapados, and Alexandre Lacoste\.WorkArena: How capable are web agents at solving common knowledge work tasks?In*Proceedings of the 41st International Conference on Machine Learning*, PMLR 235:11642–11662, 2024\.[https://proceedings\.mlr\.press/v235/drouin24a\.html](https://proceedings.mlr.press/v235/drouin24a.html)\.
- Gans and Goldfarb \(2026\)Joshua S\. Gans and Avi Goldfarb\.O\-Ring automation\.NBER Working Paper 34639, 2026\.[https://doi\.org/10\.3386/w34639](https://doi.org/10.3386/w34639)\.
- Gao et al\. \(2023\)Tianyu Gao, Howard Yen, Jiatong Yu, and Danqi Chen\.Enabling large language models to generate text with citations\.EMNLP, 2023\.[https://arxiv\.org/abs/2305\.14627](https://arxiv.org/abs/2305.14627)\.
- Jha et al\. \(2025\)Saurabh Jha, Rohan Arora, Yuji Watanabe, Takumi Yanagawa, Yinfang Chen, et al\.ITBench: Evaluating AI agents across diverse real\-world IT automation tasks\.arXiv:2502\.05352, 2025\.[https://arxiv\.org/abs/2502\.05352](https://arxiv.org/abs/2502.05352)\.
- Kapoor et al\. \(2024\)Sayash Kapoor, Benedikt Stroebl, Zachary S\. Siegel, Nitya Nadgir, and Arvind Narayanan\.AI agents that matter\.arXiv:2407\.01502, 2024\.[https://arxiv\.org/abs/2407\.01502](https://arxiv.org/abs/2407.01502)\.
- Ly et al\. \(2015\)Linh Thao Ly, Fabrizio Maria Maggi, Marco Montali, Stefanie Rinderle\-Ma, and Wil M\. P\. van der Aalst\.Compliance monitoring in business processes: Functionalities, application, and tool\-support\.*Information Systems*, 54:209–234, 2015\.[https://doi\.org/10\.1016/j\.is\.2015\.02\.007](https://doi.org/10.1016/j.is.2015.02.007)\.
- Palantir Technologies \(2026\)Palantir Technologies\.Forward Deployed Software Engineer\.Official role description, accessed 24 September 2026\.[https://jobs\.lever\.co/palantir/dab396d4\-2f14\-4796\-aac0\-0d82883dccf0](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0)\.
- Rashkin et al\. \(2023\)Hannah Rashkin, Vitaly Nikolaev, Matthew Lamm, Lora Aroyo, Michael Collins, Dipanjan Das, Slav Petrov, Gaurav Singh Tomar, Iulia Turc, and David Reitter\.Measuring attribution in natural language generation models\.*Computational Linguistics*, 49\(4\):777–840, 2023\.[https://aclanthology\.org/2023\.cl\-4\.2/](https://aclanthology.org/2023.cl-4.2/)\.
- Yao et al\. \(2024\)Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan\.τ\\tau\-bench: A benchmark for tool\-agent\-user interaction in real\-world domains\.arXiv:2406\.12045, 2024\.[https://arxiv\.org/abs/2406\.12045](https://arxiv.org/abs/2406.12045)\.