Peakview Labs Archive

The archive

Peakview Labs

Working AI systems for supply chain operations, built hands-on. This is what we made, and what you could make now.

The drawing behind the title is a mountain in topographic contour lines, built from public elevation data for Mount Washington, New Hampshire. A path climbs from the base to the summit, marked with what was built along the way: Peakview Insight, Peakview Forge, The five prototypes, The archive.

01The highlight reel

Insight, Forge and the five prototypes, in a minute.

Every screen in the reel is a new drawing of what each product did, with invented sample data. The sound is off; there is none.

55 seconds. Muted. Loops.
What the video shows

A title card reads Peakview Labs, the archive. The Insight dashboard appears: a watch list of suppliers, a world map where a hurricane watch pulses in on the Gulf Coast, the signal's score ticking up, three actions fanning out from a playbook, a comment landing in the response room, and a forecast band dropping to show a shortfall. The Forge screen follows: a typed problem about rekeying invoices, and an estimate assembling itself as modules, a timeline and what the company would own. Then the five prototypes, each for a few seconds: purchase orders passing an approval gate, a trailer temperature drifting toward an alert, a remittance document turning into EDI segments, stock flowing between locations, and a plant's utilization bars reaching a red bottleneck. A closing card reads: Peakview Labs, Inc. was dissolved in 2026.

02Exhibit 1

Peakview Insight

Supplier risk intelligence

Peakview Insight was a platform that watched a company’s suppliers, customers, internal sites and partners. It pulled in signals from news, weather and economic data, scored them, and turned what it found into prioritized actions, following best-practice playbooks or the company’s own procedures. A response room gave the team a shared place to pick up each action, and a separate service forecast demand from history. It was built on a React front end, a Node and Postgres back end with Redis, and a Python forecasting service, and it ran on AWS.

Built as
Three repositories: a Node back end, a React front end and a Python forecasting service
Stack
React, Node, Postgres, Redis, Python, AWS
Ran on
AWS: Amplify, Elastic Beanstalk, RDS Postgres, ElastiCache, S3
Status
A proof of concept. The screens here are new drawings with invented data.
25 seconds. A hurricane watch on the Gulf Coast, from signal to response.
What the video shows

A dark dashboard. On the left, a watch list of suppliers, customers, sites and partners, each with a risk dot. In the centre, a world map where signals pulse in from weather, economic indicators and news, with scored signal cards streaming down its side. On the right, prioritized actions built from a playbook, each with an owner and a due date. Along the bottom, a response room where a teammate picks up an action, and a small forecast chart whose confidence band drops to show the shortfall a signal would cause.

Three signals. Click one to follow its chain.

Each signal shows what Insight did with it: the suppliers it touched, the parts behind them, and the actions the playbook recommended.

The Insight screen playing the chain for Hurricane watch, Gulf Coast.
Signal
Hurricane watch, Gulf Coast. Mobile, AL to Lake Charles, LA. Score 82.
Affected suppliers
Northline Castings, Harbor Point Resins
Affected parts
Valve body casting VB-220, Resin grade R-18
Recommended actions
  1. Confirm inventory on hand for VB-220 and R-18 Planning, due Tue
  2. Pre-ship next week’s order from Northline before the storm Procurement, due Mon
  3. Qualify Oakridge Components as a second source for VB-220 Sourcing, due 2 wks
How Insight worked: signals were scored, matched to the watch list, turned into actions by a playbook, and handled in the response room, with a forecasting service alongside. Signalsnews, weather, economic Scoringthe model reads and scores Watch listsuppliers, sites, partners Playbookprioritized actions Response roomowners and due dates ForecastingPython service Postgres, Redis and the API underneath
How it worked

What it showed

  • That monitoring, prioritization and the team’s response could live in one tool, with the model reading and scoring and people deciding.
  • That the hard part was never the alert. It was the playbook behind it.

03Exhibit 2

Peakview Forge

Custom supply chain software in weeks

Peakview Forge was the offer to build custom supply chain software in weeks. The site asked for a problem at one of three levels of detail and returned an estimate on the spot: the modules, a week-by-week timeline and what the company would own at the end. AI did much of the implementation, the design and the review stayed with a person, and the company kept the code.

Built as
Part of the website: three intake levels and the estimate behind them
Stack
Next.js, OpenAI, Vercel
Estimate
Written by the model from the problem as typed, at one of three levels of detail
Status
Closed. The screens here show the method; no project was delivered this way.
20 seconds. A problem typed in, an estimate assembled, and how Forge was designed to work.
What the video shows

A problem box and an estimate that builds itself. A person types a problem. The estimate assembles like a blueprint: modules, a week-by-week timeline, and what the company would own at the end. A second beat shows how Forge was designed to work: a written spec, the model drafting the code, a person reviewing it, tests running, the system going live, and a key-and-repository handoff.

Three sample problems. Pick one and watch the estimate assemble.

Each estimate comes from saved answers. No model runs on this page.

The Forge screen assembling the estimate for: We rekey 400 supplier invoices a week into the ERP.
Modules
Document intake (PDF, scan and email); Matching rules (PO, receipt, price); Approval queue (exceptions to a person); ERP connector (posts the matched invoice)
Timeline
Week 1: Discovery and sample documents. Weeks 2 to 3: Intake and matching. Week 4: Approval queue. Weeks 5 to 6: ERP connector and testing. Week 7: Go-live.
What the company would own
The code, The documentation, The test suite
How Forge was designed to work: a written spec, the model drafting the code, a person reviewing, tests running, the system going live, and the handoff of the keys and the repository. Written spec in the company’s words AI drafts the code modules, tests, docs A person reviews design, data, edge cases Tests run sample and live data The system goes live with the team watching Handoff keys and repository you own the code
How it was designed to work

What it showed

  • That an estimate could be assembled by a model from a plain description of the problem.
  • That the parts which never got faster were deciding what to build and checking it.

04Exhibit 3

The five prototypes

Five working systems, each taken from a problem to running code and exercised against synthetic data. Each one plays as you reach it. Open one for what it did and what it was built with.

  • What the video shows

    Purchase orders flow in. Small routine ones pass straight through and are placed. Larger ones stop at an approval gate. Every action writes a line to a running log.

    01 · Manufacturing

    Inventory Orchestration Agent

    Routine C-items were cheap enough to ignore and expensive enough to stop a line.

  • What the video shows

    A refrigerated trailer’s temperature line drifts. A shaded prediction runs ahead of it, and an alert fires before the line crosses the limit.

    02 · Grocery

    Cold-Chain Prediction

    A refrigeration failure was usually discovered after the load was already lost.

  • What the video shows

    A remittance document is read. Its fields highlight and fly into EDI 835 segments. The validator ticks each segment green and flags one for a person.

    03 · Healthcare

    Document-to-EDI Pipeline

    Healthcare remittance arrived as unstructured documents and had to become valid EDI.

  • What the video shows

    A network of locations. As demand shifts, stock dots flow from the overstocked sites to the ones running short, where fixed reorder points would have waited.

    04 · Retail

    Dynamic Inventory Rebalancing

    Fixed minimum and maximum levels stopped reflecting reality the moment demand shifted.

  • What the video shows

    A plant schematic. A demand slider moves through scenarios. Utilization bars fill. The bottleneck turns amber, then red.

    05 · Manufacturing S&OP

    Capacity Digital Twin

    Sales and operations argued about capacity from two different spreadsheets.

Built on synthetic data. The stacks named are the ones that were used.

Prototype 1 · Manufacturing · built on synthetic data

Inventory Orchestration Agent

The problem
Routine C-items were cheap enough to ignore and expensive enough to stop a line.
What it did
It watched inventory against the production schedule and placed routine purchase orders on its own below a set spend threshold, holding anything above it for a person. Every action was written to an audit log next to the rule that allowed it.
Built with
Python, AWS Lambda, Claude, PostgreSQL, Redis
The screen
Purchase orders flow in. Small routine ones pass straight through and are placed. Larger ones stop at an approval gate. Every action writes a line to a running log.

Prototype 2 · Grocery · built on synthetic data

Cold-Chain Prediction

The problem
A refrigeration failure was usually discovered after the load was already lost.
What it did
It read refrigeration telemetry and flagged temperature drift early enough to act on, so maintenance could move ahead of the failure.
Built with
AWS IoT Core, Kinesis, SageMaker, Python
The screen
A refrigerated trailer’s temperature line drifts. A shaded prediction runs ahead of it, and an alert fires before the line crosses the limit.

Prototype 3 · Healthcare · built on synthetic data

Document-to-EDI Pipeline

The problem
Healthcare remittance arrived as unstructured documents and had to become valid EDI.
What it did
It converted explanation-of-benefits documents into EDI 835 transactions. The model handled the reading; a deterministic rule validator checked every field before anything was emitted, so the model never had the last word on correctness.
Built with
Claude, Python, Rule validator
The screen
A remittance document is read. Its fields highlight and fly into EDI 835 segments. The validator ticks each segment green and flags one for a person.

Prototype 4 · Retail · built on synthetic data

Dynamic Inventory Rebalancing

The problem
Fixed minimum and maximum levels stopped reflecting reality the moment demand shifted.
What it did
It moved stock between locations based on observed velocity instead of static reorder points, so slow sites released inventory that fast sites needed.
Built with
Python, AWS Fargate, Redis
The screen
A network of locations. As demand shifts, stock dots flow from the overstocked sites to the ones running short, where fixed reorder points would have waited.

Prototype 5 · Manufacturing S&OP · built on synthetic data

Capacity Digital Twin

The problem
Sales and operations argued about capacity from two different spreadsheets.
What it did
It simulated plant capacity against demand scenarios so both sides argued from one model. It was built to take the loudest voice out of S&OP.
Built with
Python, AWS Fargate, Node
The screen
A plant schematic. A demand slider moves through scenarios. Utilization bars fill. The bottleneck turns amber, then red.

05How it was built

Two systems, one builder, and the services underneath.

The website ran on Next.js at Vercel with OpenAI behind its chat and estimates, Resend for email, and Neon Postgres and Vercel Blob for its data. Insight ran on AWS: a React app on Amplify, a Node and Express API on Elastic Beanstalk, Postgres on RDS, Redis on ElastiCache, S3 for documents, and the Python forecasting service beside it, with Claude, Gemini and OpenAI models reading the news and scoring the risk.

The stack: the website on Vercel with OpenAI, Resend, Neon Postgres and Vercel Blob; Insight on AWS with a React app, a Node API, Postgres, Redis, S3, the Python forecasting service, and the Claude, Gemini and OpenAI models. The website · Vercel Peakview Insight · AWS Next.js apppages, the Forge estimate, chat, forms OpenAIchat, estimates Resendemail Neon Postgressubmissions Vercel Blobfiles React appAmplify Node and Express APIElastic Beanstalk, Socket.io PostgresRDS RedisElastiCache S3documents Forecasting servicePython, Flask, statsmodels ModelsClaude, Gemini, OpenAI News, weather and economic feeds, geocoding, map tiles
The stack, as it ran

By the numbers

Counted from the commit history of the four repositories on GitHub: the website, Insight’s back end and front end, and the forecasting service. 103 automated commits (a daily update the site ran for itself) are left out. The five prototypes were built outside these repositories and are not in the counts.

Systems built
6

five prototypes and the Insight platform

Repositories
4

plus the prototypes, outside them

Commits
230

made by hand

Lines of code
122,829

in 348 files

Languages, by lines

  • JavaScript 100,465
  • TypeScript 17,402
  • SQL 1,889
  • YAML 1,304
  • Python 774
  • CSS 705
  • PowerShell 194
  • HTML 96

Repositories

NameCommitsLines
peakviewlabs-site
The website, the Forge intake and estimate, the chat and the forms		 123 14,202
supply-chain-ai-backend
Insight’s API: companies, portfolios, risk analysis, the partner portal		 64 59,251
supply-chain-frontend
Insight’s React app: dashboards, the network view, the map		 41 48,602
supply-chain-forecast-service
Insight’s Python forecasting service		 2 774

06What you could build now

The past, set against the present.

Peakview built with the tools of its time. This section asks what the same work would take today, and what a supply chain team could build this month. Every claim below carries its date and its source, and the section is refreshed on a schedule.

Last updated October 15, 2026

1. The frontier, as of October 15, 2026

METR measures how long a task, in the working time a skilled person would need, the best AI systems can finish on their own. The line is the frontier at even odds of success. Peakview’s last commit is marked against it.

METR’s 50% time horizon for frontier models, from 11 min for Claude 3.5 Sonnet (June 2024) to 17 h for Claude Mythos Preview (early) in 2026-04-07, with Peakview’s last commit marked. Measurements above 16 hours are unreliable on METR’s suite. above 16 hours: unreliable on METR’s current suite 10 min 30 min 1 hour 4 hours 1 day (8 h) 1 wk (40 h) Jul 2024Jan 2025Jul 2025Jan 2026Jul 2026 Peakview’s last commit Claude 4 Opus: 1.7 h at 50% Claude 4.1 Opus: 1.7 h at 50% GPT-5.1 Codex Max: 3.7 h at 50% GPT-5.3 Codex: 5.8 h at 50% Gemini 3.1 Pro: 6.4 h at 50% GPT-5.4: 5.7 h at 50% Claude 3.5 Sonnet (June 2024): 11 min at 50%, 2 min at 80% Claude 3.5 Sonnet (June 2024) o1-preview: 20 min at 50%, 4 min at 80% o1-preview Claude 3.5 Sonnet (Oct 2024): 21 min at 50%, 3 min at 80% Claude 3.5 Sonnet (Oct 2024) o1: 39 min at 50%, 7 min at 80% o1 Claude 3.7 Sonnet: 1.0 h at 50%, 12 min at 80% Claude 3.7 Sonnet o3: 2.0 h at 50%, 30 min at 80% o3 GPT-5: 3.4 h at 50%, 38 min at 80% GPT-5 Gemini 3 Pro: 3.7 h at 50%, 54 min at 80% Gemini 3 Pro Claude Opus 4.5: 4.9 h at 50%, 49 min at 80% Claude Opus 4.5 GPT-5.2: 5.9 h at 50%, 1.1 h at 80% GPT-5.2 Claude Opus 4.6: 12 h at 50%, 1.2 h at 80% Claude Opus 4.6 Claude Mythos Preview (early): 17 h at 50%, 3.1 h at 80% Claude Mythos Preview (early) estimate today, 49 h
Source: METR, Time Horizon 1.1 results file, read October 15, 2026. Points are METR’s 50% horizons by release date; the dashed line carries the last frontier measurement forward at METR’s doubling time from 2023 on (129 days) and is an estimate. METR’s page says measurements above 16 hours are unreliable on its current suite, and that it stopped actively updating the page on September 8, 2026.

2. Then and now

What each build took when Peakview built it, from the repositories’ history, against what it would take with today’s tools. The second column is an estimate: METR’s measured task length for the best public model rose from 1.7 hours (Claude 4 Opus) and 3.4 hours (GPT-5) to 17.4 hours (Claude Mythos Preview, April 2026) at even odds of success, and the coding tools of October 2026 work inside a repository on their own for hours at a time. The estimates below take that as five to ten times more unattended work per day, and keep a person’s review in the loop at the earlier rate. The ranges are wide, and these are estimates made for this page, not METR’s figures.

BuildThen, from the recordNow, an estimateWhat the version built now could do
Peakview Insight Three repositories, 107 hand-made commits and about 108,600 lines of JavaScript, SQL and Python, built part-time over ten months alongside everything else the company did. About one to two weeks of a person’s time directing coding agents, with the review as the limit: three days if the design is already written, three weeks if the data model is still being argued. Run as an agent that reads the signals, scores them, drafts the actions and the response-room note, and waits for a person’s yes. Read documents and screens directly instead of through connectors. Hold a multi-hour investigation together instead of one request at a time.
Peakview Forge The three intake levels and the estimate were built in one day inside the website, which took 123 hand-made commits in all. A day again. What changes is what the estimate could do: draft the modules, the tests and a first working version of the simplest module in the same sitting. Hand back a runnable prototype of the smallest module beside the estimate, so the conversation starts from working code.
The five prototypes Built outside the four repositories counted on this page, so their history is not in the record here. A few days each for one person with a coding agent, by the same estimate as Insight, with the time going to the data and the rules rather than the code. The agent version of each: watch the feed, act inside the guardrails, write the log line, and ask a person for the rest. The hard part of each is unchanged: the spend threshold, the temperature limit, the reorder rule, the validator.

3. Five things a supply chain team could build this month

An operator’s view of what is possible with a small team, a model API and someone who owns the result. None of this is an offer. Peakview is closed.

  1. A supplier signal watch

    News, weather and port feeds for the suppliers that matter, read by a model each morning into a one-page brief per planner, with every item owned by a person.

    Needs
    The supplier list with locations, feed access, a model API, one planner who owns the brief.
    Watch
    The model reads and scores. A person decides. Keep the playbook short and written down before the first brief.

  2. Documents to structured data, with a validator

    Invoices, packing lists and remittances read by a model into fields, with a rule validator that checks totals and codes before anything posts to the ERP.

    Needs
    Fifty sample documents, the matching rules in writing, an exception queue a person works daily.
    Watch
    The validator has the last word, never the model. Count the exceptions every week; the rate is the health of the system.

  3. An exception desk for open orders

    The open-order feed compared with promise dates every night. The model drafts the internal action and the customer note; a person approves each one before it goes.

    Needs
    A nightly export of open orders, carrier tracking, the promise dates, one owner per customer group.
    Watch
    Approval stays with a person. Measure how many drafts go out unchanged; that number tells you when to trust it with more.

  4. A demand-against-forecast gap monitor that explains itself

    The gap by product family each week, with the model writing the likely cause from the signals it can see and a planner confirming or correcting it.

    Needs
    Weekly demand and forecast by family, the promotions calendar, the signal watch above.
    Watch
    A plain-language reason is a hypothesis. Log which ones held up, and the monitor gets better at the second one.

  5. A capacity what-if tool fed by the planning spreadsheet

    Sales enters a scenario and sees the bottleneck from the same model Operations plans with, so the argument is about the number and not the spreadsheet.

    Needs
    Station capacities, the current schedule, the demand plan, a half day with the people who own each.
    Watch
    One model, shared. The moment each side keeps its own copy, the tool stops doing its job.

4. Change log

  • 10/15/2026 First version of "What you could build now". The frontier chart from METR’s Time Horizon 1.1 data, the then-and-now comparison, and five things a supply chain team could build this month.

Each update is also in the RSS feed.

Sources

  • METR, Time Horizon 1.1 results file (benchmark_results_1_1.yaml) read 10/15/2026 The models, their 50% and 80% horizons with intervals, and the doubling time from 2023 on: 128.7 days (104 to 158).
  • METR, Time Horizons page read 10/15/2026 Last updated September 8, 2026, when METR said the page is no longer actively updated. Measurements above 16 hours are unreliable on the current suite.
  • METR, "Time Horizon 1.1", January 29, 2026 read 10/15/2026 The larger task suite behind the 1.1 numbers and the shorter doubling time it measured.
  • METR, "Frontier Risk Report", May 19, 2026 read 10/15/2026 For February 16 to March 16, 2026: the public frontier at about 12 hours at 50% (5 to 61 hours) and about 1.5 hours at 80%; the most capable model tested likely at or above 16 hours, with a point estimate between 16 and 20 hours. The report says the suite cannot reliably measure above 16 hours and that the most capable agents essentially saturated it.
  • Claude Code, overview read 10/15/2026 "Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools." Runs in the terminal, an IDE, a desktop app and the browser; can run agents in parallel and on a schedule.
  • OpenAI, Codex documentation read 10/15/2026 Codex in ChatGPT, a CLI, an IDE extension and Codex Cloud; explores code, builds features, reviews changes and fixes failures, with scheduled and long-running work. Release notes dated October 5 to 9, 2026.
  • The four Peakview repositories on GitHub (private) read 10/15/2026 Commit history counted with scripts/count_numbers.py; automated commits left out.

07The close

Peakview Labs, Inc. was dissolved in 2026.

Thank you to the people who looked at these builds along the way and said what they thought. Graham Whittemore’s work and contact details are at grahamwhittemore.com.