Fern

Automated financial impact assessments for every engineering change happening in R&D

Comment

Inspiration

At an aircraft maker, every design change moves what each aircraft costs to build, when the change reaches the production line, and how exposed the supply chain is. Before the Change Control Board can decide, a cost engineer, a buyer, a planner and a cost accountant each work that out by hand, usually in spreadsheets. One study at Ascom measured 2.5 hours of value-adding work inside a 144-day average lead time for a change request. Most of the cost is the waiting.

Hyphenate asked for autonomous systems that fill finance seats. Fern fills three of them, the cost engineer, the cost accountant and the supply-chain analyst who write the impact assessment for the board.

What it does

Fern reads an engineering change request (ECR) from the company's PLM, and the costs, suppliers, stock and history from its ERP. Code computes the unit cost, one-time cost, cut-in date and supply risk as ranges, and Fern posts the impact statement back on the ECR, where engineers and the board already work.

We show it at Bowman Aviation, a fictional electric aircraft maker modelled on public data about Archer. Bowman builds the Vesper V4 eVTOL air taxi and is developing the Meridian M6. Its engineers use a PLM that stands in for Teamcenter, and its finance team uses ERPNext, standing in for SAP.

In our demo an engineer files ECR-0417, which moves a motor-controller bracket from Rev B to Rev C after it cracked in a vibration test. Fern picks it up, runs its checks against live ERPNext, and a Claude Haiku agent writes the impact statement. On our final test run it landed back on the ECR about a minute later. It showed about +$415 per Vesper ($407 to $432) and +$277 per Meridian, a one-time cost of $142k to $156k, and a 12-month net of about $157k. The biggest driver was whether to use up or scrap the old brackets, a $60.6k swing. Six cost lines with no estimate yet were flagged, and the recommendation was Approve with conditions, from a written rule that names those gaps. Because the p90 cost of about $164.6k is above Bowman's $150k limit, it went to the Change Control Board with a Technical Review Committee review.

The timeline check puts the bracket's cut-in at 2027-02-16 at the median, 13 weeks later than the date on the request, because the supplier quotes 14 weeks. The supply check reads every other open ECR. ECR-0419 and ECR-0421 need the same supplier, so ECR-0421 waits 13 weeks behind ECR-0419, and qualifying both together saves about $180k at the median.

Every write Fern's agents make goes through a policy gate built from the company's configuration. On Bowman's settings, Fern approves ECR-0423, a $622 change, on the fast track, and sends the bracket change to the board. When the board approves an ECR in the PLM, Fern records the decision with the approver's name and attaches the ERP change package, the new standard costs, BOM lines and journal entries a person needs to enter, each traced to the change order. In our rehearsal the package showed up 17 seconds after the release.

Fern never writes to the ERP. Its code has no ERP write path and its ERPNext account is read-only, so the cost accountant and the manufacturing engineer still enter every change themselves. In the PLM it writes only its own seven impact fields and comments.

Anyone looking at an ECR can also ask Fern a question in plain words. A read-only Claude session answers it and marks any number it could not find in what it cited.

Bowman, its people and its history are fictional, and the dataset marks each value as sourced or invented. ERPNext and the PLM are real software seeded from that dataset. The numbers above come from one live run on October 25 with real Claude sessions for every open ECR.

How we built it

  • Fern's state lives in SpacetimeDB, including the ECRs, every check run, the impact statements, the approvals and an append-only action log. The policy gate lives in the module, so every write goes through it.
  • The checks are TypeScript code (BOM delta, cost, timeline and supply) with seeded Monte Carlo draws and a trace behind every number. Agents read the request, propose assumptions and write the narration, but they never compute a headline number. Any number an agent marks as a computation has to match a stored check result exactly.
  • Fern's agents are Claude Code sessions run through the Claude Agent SDK. Each job runs isolated with only Fern's MCP tools, and every step streams into the action log.
  • The agents reach Fern only through one MCP server. Each request carries a signed, short-lived token naming the job, the actor and the ECRs it may write to. A write outside that scope is refused and logged.
  • A research agent can look up a missing cost input on the web, with Claude's own web search first and Bright Data as the fallback. Code decides whether to use what it finds.
  • One config file makes it Bowman's, covering vocabulary, the ECR form, change classes, the approval matrix, roles and agent limits.
  • Connectors read the PLM (built on Frappe) and ERPNext over their REST APIs. Both run in Docker on a home server, seeded from one dataset so they agree.
  • Fern's own screens are built with React and Primer, GitHub's open-source design system.

Challenges we ran into

  • The same facts gave two different recommendations on two runs. The recommendation is now a rule computed from the checks, and it is applied again before anything reaches the PLM.
  • Two publishers wrote the same statement twice, because reading and then writing to the PLM is not atomic. A write now takes a 60-second lease first.
  • Stopping an agent did not actually stop it. Aborting through the SDK only interrupted the tool call in flight, so the runner now closes the session.
  • SpacetimeDB's runtime has no structuredClone, so validating the configuration inside the module crashed on the first real call.
  • A multipart quote priced the wrong part. A propeller blade took the hub's $3,950 price instead of its own $930, which moved one ECR's year-one spend by $3M.

Accomplishments that we're proud of

  • An ECR filed in the PLM gets a ranged, sourced impact statement back in about a minute, and a restart never writes anything twice.
  • Every number on the statement traces back to the request revision and the ERP data it came from.
  • The agents run under limits a finance team could accept, with named seats, scoped tokens, a read-only ERP account and a log the platform writes instead of the agent.
  • Hundreds of offline tests, plus live checks against scratch databases.

What we learned

  • Agents are good at reading a messy change request and explaining a forecast, but code should compute every number they report.
  • A recommendation people act on has to follow a rule they can read, or it drifts between runs.
  • Taking away Fern's ability to write to the ERP made the trust story simple enough to check in the code.

What's next for Fern

  • The full assessment on demand, with research agents, an adversarial reviewer and a blind checker.
  • Letting a person's own agent, like Claude Code on an engineer's laptop, connect over MCP and act within that person's limits and the company's.
  • Comparing each forecast with what actually happened once the change reaches the line.

Built With

Share this project:

Updates

Submission history