VolkerERP

See the risk before making the promise: deterministic ERP truth, bounded GPT‑5.6 explanations, and explicit human authority for small manufacturers.

Comment

VolkerERP — OpenAI Build Week submission

Submission metadata

  • Category: Work and Productivity
  • Repository: https://github.com/bab-ptp/volker-erp
  • Codex /feedback Session ID: 019f7c4a-75ee-7b31-9e3f-25314aab16ac
  • Demo video: final 1080p, captioned, under-three-minute master prepared for the owner-supplied public YouTube URL

The repository-access option and public YouTube URL must match the values entered in the final Devpost form. No production deployment is required or claimed.

Final external artifact names

Submission-production files are intentionally excluded from Git. The owner-facing final package uses these unambiguous names:

  • VolkerERP_Can_Four_Units_Ship_July_24_OpenAI_Build_Week.mp4
  • VolkerERP_English_Captions.srt
  • VolkerERP_YouTube_Thumbnail.png
  • VolkerERP_YouTube_Title_and_Description.md

The YouTube title is VolkerERP — Can Four Units Ship July 24? | OpenAI Build Week. Historical draft and internal scoring filenames are not submission artifacts.

Tagline

See the risk before making the promise.

Deterministic truth. Bounded AI. Humans authorize.

One-line description

VolkerERP helps an underserved manufacturer understand why a complex order cannot ship—without allowing AI to change the records that decide the answer.

Inspiration

Small manufacturing teams often make high-consequence delivery decisions from disconnected spreadsheets, notes, supplier records, quality evidence, and capacity calendars. The hard problem is not generating a confident paragraph. It is knowing which facts are authoritative, what remains unknown, and who is allowed to act.

VolkerERP's wider mission is to give smaller manufacturers a controlled decision layer across planning, purchasing, engineering, quality, production, and customer promises. The July 24 order is one intentionally bounded starting point, not a claim that a general-purpose ERP is complete.

VolkerERP asks a practical question: Why can this order not ship on July 24?

What it does

VolkerERP is a bounded, synthetic VX-4 prototype-chassis mission thread. Its deterministic engine calculates order readiness across material, engineering revision, quality, and capacity. For the demonstration order, it identifies five power supplies short, four held backplanes excluded from ATP, a controller supplier/required-MPN conflict, a 240-minute functional-test deficit, and the absence of a responsible shipment forecast.

The bounded GPT-5.6 Sol provider path gathered those five evidence domains through strict read-only tools and turned them into one operator-ready explanation: what blocks the promise, which evidence supports each finding, what is still unknown, and which human review should happen next. The separately captured response passed every acceptance condition: schema, returned-evidence references, deterministic-status agreement, uncertainty, and the human-authority boundary.

The model cannot approve, commit, purchase, substitute, release, ship, or mutate records. A human-controlled transition still requires authentication, role authorization, explicit confirmation, server validation, optimistic version checking, idempotency, conflict detection, atomic persistence, and an append-only audit event.

In this prototype, VolkerERP eliminates AI mutation-authority risk by keeping the deterministic data engine isolated from language-model output. The bounded AI layer may explain scenarios and flag supplier identity conflicts, while all core database actions remain tenant-scoped, explicitly human-authorized, and append-only-audited.

How we built it

  • TypeScript and Node.js with Fastify
  • React and Vite command center
  • built-in SQLite with normalized migrations and synthetic seed data
  • deterministic BOM, ATP, revision, quality, capacity, and forecast calculations
  • OpenAI Responses API with gpt-5.6-sol
  • exactly five tenant-scoped read-only evidence tools for the competition interaction
  • strict structured output plus evidence, status, and authority validation
  • server-only credentials, store: false, privacy-preserving safety_identifier, zero retries, and hard execution limits
  • deterministic fallback when the provider is disabled or unavailable
  • Vitest, compiled browser proofs, secret scanning, static analysis, type checking, build verification, backup/recovery, concurrency, and rollback tests

Why the AI is bounded

Deterministic truth means results calculated from controlled ERP records. Bounded AI means AI may explain that evidence but cannot change business data or authorize action.

The model is deliberately outside the transaction boundary. It receives only approved tool results—not raw database access—and its response is rejected unless it matches the schema, cites returned evidence, agrees with deterministic status, and preserves human authority. Provider failure cannot remove the operator’s deterministic view.

This is not “AI decides, human rubber-stamps.” The operator sees the risk, reviews the evidence, and remains the only path to a controlled decision.

Live software proof

The persisted event log, server-side revalidation, and idempotent commit pipeline are implemented and exercised end to end for this bounded mission thread. The demonstration does not substitute a fixed JSON response or mocked success state for the controlled transition. The authenticated API rechecks the person, role, intent, expected version, evidence, and conflicts; one SQLite transaction persists the correction, idempotency result, append-only audit evidence, and durable event; only after that commit does the independent second view refresh from authoritative state.

The interface is intentionally clean and bounded to reduce cognitive load for shop-floor operators. This is a design objective and a tested prototype behavior—not completed real-user validation, production usability certification, or a claim that every traditional ERP fails.

The project addresses two specific risk classes without promising to eliminate every model or human error: GPT-5.6 cannot establish business truth or cross the transaction boundary, while the server rejects unauthorized, stale, conflicting, unconfirmed, and duplicate controlled changes.

Manufacturing impact

The prototype demonstrates how a smaller manufacturer could reduce the time spent reconciling blockers while avoiding unsupported delivery promises. It puts material, revision identity, quality disposition, and finite capacity in one traceable decision view.

The product value is simple: find the real constraint before a person commits the company to a date.

The commercial value would come from avoiding preventable scrap, emergency expediting, schedule churn, rework, and damaged customer trust. No measured savings, pricing, customer adoption, or production deployment is claimed in this prototype.

The broader direction is to extend the same controlled-evidence pattern into purchasing, supplier qualification, quality disposition, production scheduling, inventory traceability, and customer communication. Every extension must preserve deterministic calculation, authenticated human authority, manual fallback, and auditable persistence.

Challenges

The hardest work was preserving a clean authority boundary while making the AI genuinely useful. We had to prevent broad tool access, bound continuation calls and result sizes, validate citations against returned evidence, keep deterministic status authoritative, verify that AI paths do not mutate business state, and preserve useful fallback behavior.

We also treated failure evidence as part of the engineering result: provider timeouts are classified safely, retries remain zero, and capture finalization hashes only closed evidence bytes.

Accomplishments

  • one readable command center for a multi-domain manufacturing promise decision
  • real persisted deterministic behavior rather than a mocked success path
  • accepted, evidence-cited GPT-5.6 explanation using five read-only tools, zero mutation tools, and zero retries
  • human-controlled, idempotent, atomic transition and append-only audit design
  • persisted live events with replay and restart recovery
  • a second view that updates only after the real server commit
  • repeated requests that cannot create duplicate changes, with committed change and audit history intact after restart
  • adversarial verification of unauthorized, stale-state, replay, rollback, timeout, and disabled-AI paths
  • an honest prototype boundary that does not claim production readiness or certification

What we learned

AI adds the most value here when it reduces cognitive load without becoming the source of truth. A strong manufacturing assistant should make uncertainty more visible, not hide it behind fluent prose. The most important architecture decision was to keep the operator as the hero.

What is next

The next step is not autonomous transaction execution. It is broader synthetic scenario coverage, real-user research with underserved manufacturers, formal threat modeling, production-grade identity and tenancy, operational monitoring, performance qualification, and controlled integrations—each added without weakening deterministic truth or human authorization.

Authorship

  • Owner — Bab Tarapara: manufacturing vision, domain authority, and final decisions
  • ChatGPT: architecture, control boundaries, and implementation task design
  • Codex: implementation, testing, adversarial review, documentation, and evidence
  • GPT-5.6 Sol: accepted bounded runtime explanation of returned evidence; no transaction authority

Honest scope

VolkerERP is an independent Build Week prototype using synthetic data. It is not a general-purpose ERP, not production-ready, not Tier-1 certified, and not connected to real business or manufacturing systems.

See the risk before making the promise.

Deterministic truth. Bounded AI. Humans authorize.

Built With

Share this project:

Updates