All six systems

Procurement & supply chain

ProcureOS

A buyer must decide, under a shortage, which supplier to award: the cheapest, the fastest, or the most reliable. A black-box recommendation is not auditable. The maths, the quotes, and the written rationale have to be visible.

Product thesis: Explainable procurement decisions. Shortage maths shown, quotes compared on landed cost, lead time, and reliability, award rationale forced in writing.

Cabberefwenf/ProcureOS · main @ 094be9a6 (2026-10-26)

Interactive demo in development
Conceptual interface illustration, not a screenshot of a live application.

Primary workflow

An intelligent procurement workbench. Light, tabular, and maths-first.

  1. Command Center: KPIs, top alerts, supplier on-time delivery, spend by category.
  2. Workbench: ranked exceptions with trigger, evidence, impact, options, and approver.
  3. Guided demo: 10 steps on live app state, from shortage maths to RFQ, quotes, award, approval, purchase order, receipt, and audit trail.
  4. Supplier scorecards with adjustable weights and side-by-side comparison.
  5. Forecast holdout backtest (naive, moving average, weighted moving average, single exponential smoothing) with MAE, MAPE, and bias.
  6. Monte Carlo stockout simulation with seeded trials, and saved scenarios.

Architecture

  • Next.js 15 App Router, static export (output: export), React 19, TypeScript, Tailwind. No server, no database, no runtime network calls.
  • Pure calculation library with no React imports. Deterministic dataset generator, seed 4408, reference date 2026-10-01.
  • Rule-based alert engine. Alerts are deterministic rules, not ML. Thresholds are hard-coded.
  • Pure reducer and state machine: illegal transitions throw a domain error and append an audit entry with a logical timestamp.
  • Money in integer cents with assertion guards. CSV export escapes formula injection.

Engineering decisions

  • Show the formulas. Safety stock, reorder point, and economic order quantity are displayed per SKU, not hidden behind a score.
  • Role-based approval with a typed confirmation for high-value purchase orders, and an over-receipt tolerance on receiving.
  • The guided demo runs on live app state, not a scripted slideshow: the same reducer, the same audit trail.

Technical challenges

  • Seeded-random supplier profiles made trade-offs unreadable. Deterministic trade-off archetypes exist only in a local snapshot, not in the repo.
  • Two open, unmerged PRs split the deployable lineage: release-hardening and a Phoenix draft describing capabilities that are not on main. Case-study copy must not describe Phoenix-only work as main capability.
  • No public deployment URL is claimed anywhere on main. Worth must not invent one.

Demonstration scenario

  1. MOT-4408: a critical servo motor for a spindle drive, about to stock out, its only order slipped.
  2. Read the shortage maths, then the Monte Carlo result: Arden 49 days, Marlow 30 days, Bracken 14 days (seeded simulation, doc-claimed).
  3. Create an RFQ, issue it, compare synthetic quotes on landed cost and date, and write the award rationale.
  4. Plant Controller approval (buyer role-gated), purchase order, Operations Director approval with typed confirmation over $100k, issue, receive, and watch inventory and the audit trail update.

Engineering evidence

  • 10 URL routes plus a landing page, with query-param detail panes. All 10 routes render with the synthetic banner in end-to-end tests. [OBSERVED, route inventory and e2e spec]
  • Test files: 3 unit files and 1 end-to-end spec in the repo. Pass counts were not re-run in VW-100 recon. [OBSERVED, file inventory only; UNVERIFIED pass count]
  • End-to-end tests cover desktop, tablet, and mobile viewports with a no-horizontal-overflow assertion. [OBSERVED, Playwright config]
  • Synthetic-data banner on every screen: fictional company, suppliers, and figures. No real purchase orders or RFQs are ever sent. [OBSERVED]

OBSERVED means read from repository evidence at the stated commit. DOC-CLAIMED means a repository document states it but it was not re-run during reconnaissance. UNVERIFIED means no supporting evidence was obtained. See the engineering inventory.

Known limitations

  • No verified public demo URL on main. Deployment doc states: no deployment URL is claimed here.
  • Supplier archetype polish and plain-English demo copy exist only in a local snapshot, not in the repo.
  • Croston / SBA forecasting for intermittent-demand SKUs is honestly disclosed as not implemented.
  • No CI workflow exists. No automated axe audit; keyboard and focus handling were only spot-checked. End-to-end tests are Chromium-only.
  • Workbench alerts have no snooze or assign workflow.
  • The landing page links to the private GitHub repo, which 404s for visitors without access.

Sandbox readiness

Indefinite localStorage state (procureos:state:v3, plus a simulated role selector that is explicitly not security). Reset restores the deterministic seeded dataset. No registration, no expiry. The guided demo is documented at about 5 minutes; breadth after it is the 10 free-exploration routes. A designed 60-minute path was not evidenced.

Current portfolio status: Demo unavailable in this harness: no deployment verified, demoUrl null, allowlist empty.