← Faraday Research

Faraday Cage
m1 & d1

Improving industrial execution through RL environments and specialized harnesses.

From plausible answers to completed work. Two specialized systems coordinate evidence, memory, and execution across manufacturing and distribution.

m1 / Manufacturing94%strict completion87.8% fewer tokens · 20.3× successful tasks / $
d1 / Distribution96%strict completion89.6% fewer tokens · 16.8× successful tasks / $

Reported results · Matched baseline comparisons · d1 uses the v0.6 scoring contract

01

Industrial work, completed

Industrial AI must do more than produce a plausible answer. It must complete work across systems whose records, constraints, and dependencies change over time.

A manufacturing order requires eligible material, current engineering instructions, qualified resources, completed operations, quality release, and shipment. A distribution order requires accurate inventory, feasible purchasing, correct allocation, warehouse execution, and financial reconciliation.

We converted the execution systems behind OtisBench and the Faraday Industrial Benchmark into reinforcement-learning environments. We then developed two specialized systems:

  • Faraday Cage m1, a manufacturing harness built around Opus 5.
  • Faraday Cage d1, a distribution harness built around Opus 4.7.

The objective was to increase verified completion while reducing inference consumption. m1 achieved 94% strict manufacturing completion, and d1 achieved 96% strict distribution completion. Average token consumption fell by 87.8% and 89.6%, respectively.

02

Selecting the base models

We selected the initial candidates from the highest performers in each benchmark table.

We reproduced the selected headline scores in fresh, matched baseline runs before optimization.

The d1 comparison uses the v0.6 scoring contract. It does not compare that score with the expanded v0.8 suite.

SystemBase modelEnvironment
m1Opus 5OtisBench ↗
d1Opus 4.7Faraday Industrial Benchmark · v0.6 ↗

03

Turning the benchmarks into RL environments

The benchmarks already supplied the core structure of an operational environment: starting business records, available actions, persistent state, time-dependent events, completion checks, and replayable trajectories.

We added an episode interface that initialized a scenario, accepted an action, returned the next observation and reward, and identified whether the episode had completed or exhausted its budget.

Each episode followed an operational sequence:

Observe → decide → act → inspect the consequences → recover or continue → verify completion.

The environments exposed business evidence through permitted tools. Reference answers, evaluator internals, and future event schedules remained outside the policy’s observations.

For manufacturing, actions could reserve material, purchase supply, schedule resources, execute operations, inspect output, perform rework, and ship finished goods.

For distribution, actions could allocate stock, place supplier orders, release warehouse work, coordinate fulfillment, produce invoices, and reconcile exceptions.

This allowed optimization against the consequences of decisions, including failures that only became visible several actions later.

01 / Episode loopPersistent operational state
  1. ObserveRead permitted business evidence
  2. DecideChoose the next action
  3. ActUpdate operational records
  4. InspectCheck consequences and recover
  5. VerifyConfirm completion or continue
Actions change records and advance the episode. Completion checks or the execution budget determine when it ends.

04

What reinforcement learning changed

The underlying Opus models remained fixed. RL trained a separate controller responsible for retrieval, memory, and execution strategies. It did not update Opus model weights.

The controller learned when to retrieve additional evidence, refresh stale records, continue execution, investigate a failed action, or verify the final outcome.

Rewards emphasized verified completion and correct operational execution. Intermediate rewards recognized durable progress. Penalties discouraged invalid actions, repeated investigation, and unnecessary inference.

Critical authorization and quality requirements remained hard constraints. A shorter trajectory that violated those requirements could not receive a successful outcome.

Alongside RL, we hillclimbed the harness through development evaluations. Separate comparisons tested controller training, harness changes, and their combination.

02 / Execution architectureBase-model weights stay fixed
RL trainingCompletion + durable progress − invalid actions − unnecessary inference
↓ learns retrieval, memory, and execution strategies
Trained controllerRetrieve · refresh · sequence · recover · verify
Operational memoryRequirements, dependencies, current evidence, open exceptions
↕ evidence and action selection
Fixed Opus modelm1: Opus 5   /   d1: Opus 4.7
↕ permitted tools
Industrial environmentBusiness records → state transitions → observations and rewards
Hard constraints: authorization + quality requirements
RL updates the separate controller. Harness development is evaluated independently and in combination with controller training.

05

Faraday Cage m1: manufacturing execution

Manufacturing workflows contain dependencies that must remain connected throughout an episode. A drawing revision can invalidate process settings. A material hold can prevent production. A machine interruption can invalidate a schedule. A shipment requires completed operations and a conforming quality release.

The m1 harness maintained compact operational memory covering:

  • Order requirements and completion conditions.
  • Material eligibility, reservations, and availability.
  • Current engineering revisions and process instructions.
  • Machine, operator, fixture, and tooling qualifications.
  • Production progress, inspections, and open recovery actions.
  • Quality release and shipment evidence.

Instead of repeatedly rebuilding the entire situation from conversation history, m1 retrieved relevant records and refreshed assumptions when affected state changed.

Before consequential actions, it checked prerequisites. Before declaring completion, it verified the resulting production, quality, and shipment records.

03 / Manufacturing dependencies
  1. OrderRequirements
  2. MaterialEligible + reserved
  3. ProductionQualified resources
  4. QualityConforming release
  5. ShipmentVerified records
Completion depends on connected production, quality, and shipment evidence.

06

Manufacturing results

Strict completion increased approximately 2.47×. Failed tasks fell from 62 to 6 per 100 attempts, a 90.3% reduction.

The improvement reflects both better execution and less wasted investigation: fewer actions based on outdated evidence, fewer prerequisite failures, and more reliable verification.

m1 / Strict completion100 attempted tasks
0%50%100%
Baseline38%
Faraday Cage m194%
Failed tasks: 62 → 6 per 100 attempts. Baseline completion is derived from the failure counts in the research.

07

Faraday Cage d1: distribution execution

Distribution workflows depend on consistent transactions across customer demand, inventory, suppliers, warehouse execution, and finance.

The d1 harness maintained a transaction map covering:

  • Customer orders, quantities, and delivery commitments.
  • Available inventory, reservations, and inbound supply.
  • Supplier minimums, lead times, capacity, and purchasing constraints.
  • Allocation decisions and warehouse progress.
  • Shipment, invoicing, and reconciliation status.

This helped the system preserve the consequences of earlier decisions. Inventory committed to one order remained unavailable to another. Supplier changes triggered reviews of affected commitments. Shipment and financial records remained linked through completion.

04 / Distribution transactions
  1. DemandOrder commitments
  2. SupplyStock + purchasing
  3. AllocationReservations
  4. FulfillmentWarehouse + shipment
  5. FinanceInvoice + reconcile
Inventory, shipment, and financial records remain linked through completion.

08

Distribution results

Aggregate score and strict completion are separate measures: partial credit does not establish that a workflow finished.

Failed tasks fell from 45 to 4 per 100 attempts, a 91.1% reduction.

d1 / Strict completion100 attempted tasks
0%50%100%
Baseline55%
Faraday Cage d196%
Failed tasks: 45 → 4 per 100 attempts. Baseline completion is derived from the failure counts in the research.

09

Performance per inference dollar

Higher completion and lower token consumption compound. Lower inference spending reduces the cost of every attempt, while higher completion reduces how much spending is absorbed by failures.

The following figures use a blended rate of $30 per million tokens, held constant within each comparison. Token totals include failed attempts, retries, controller inference, and helper-model calls.

Calculations use unrounded values. Cost per successful task includes spending on unsuccessful attempts.

Across both 100-task comparisons, total inference spending falls from $570.06 to $65.40, while completed tasks increase from 93 to 190 out of 200 attempts.

These figures exclude training, engineering, infrastructure, and tool fees. A full cost accounting would separately itemize input, output, reasoning, and cached tokens at actual provider pricing.

SystemToken reductionSuccessful tasks / inference $
m187.8%20.3× baseline
d189.6%16.8× baseline
Total inference spend

$570.06 → $65.40

Completed tasks / 200 attempts

93 → 190

Combined comparisons · $30 per million tokens · Includes unsuccessful attempts · Excludes training, engineering, infrastructure, and tool fees

10

Evaluation methodology

To distinguish optimization from memorization, training and development scenarios were separated from final evaluation by workflow structure wherever possible. Changing only record identifiers or random seeds was not treated as sufficient evidence of generalization.

Each comparison held the base-model snapshot, task selection, scoring contract, and available execution budget constant. The optimized system could consume less than the available budget, but both systems received the same opportunity to complete the work.

Ablations evaluated:

  • The standard harness.
  • Harness improvements without the RL-trained controller.
  • Controller training with the standard harness.
  • The combined Faraday Cage system.

Failed, interrupted, and budget-exhausted attempts remained in the results. Final evaluation used frozen configurations, with task-level outcomes, usage records, and replay receipts retained for inspection.

The central finding is that specialized execution systems produce substantially more completed industrial work from the same base models while consuming less inference. m1 and d1 achieve this through improvements in operational memory, evidence selection, action sequencing, and recovery, yielding 20.3× and 16.8× more successful tasks per inference dollar, respectively.