RegBridge

AI integration copilot that turns unfamiliar ERP invoice schemas into validated, testable, market-ready engineering handoffs.

Comment

Inspiration

Companies entering a new market often need to connect unfamiliar ERP invoice structures to local integration requirements. This process can be slow and repetitive: engineers must inspect undocumented fields, understand what they mean, create transformation logic, validate the output, and prepare code and tests for review.

AI can help interpret unfamiliar schemas, but financial integration workflows should not rely on an AI model alone. A confident-looking answer is not enough when missing identifiers, incorrect totals, or unsafe mappings can create real operational risks.

I built RegBridge to explore a more trustworthy approach: GPT-5.6 interprets unfamiliar ERP semantics, while deterministic code controls validation, reconstruction, remediation, artifact generation, and verification.

What it does

RegBridge accepts a synthetic ERP invoice payload, including structures it was not explicitly hardcoded to recognize.

The workflow is:

  1. GPT-5.6 analyzes the source structure and proposes a declarative semantic mapping plan.
  2. RegBridge validates every proposed mapping against strict rules for source paths, target fields, transformations, data types, and collections.
  3. Deterministic application code reconstructs a canonical invoice.
  4. Explicit validation rules identify missing or inconsistent information.
  5. Truth-first remediation applies only safe formatting and arithmetic corrections.
  6. Missing identifiers and business facts remain unresolved instead of being invented.
  7. RegBridge generates a source-specific TypeScript adapter and executable tests.
  8. The generated artifacts are compiled, executed, and verified locally.
  9. The engineering handoff is marked ready only when generation, compilation, execution, and testing have genuinely passed.

The central trust boundary is simple:

GPT-5.6 interprets meaning. Deterministic code decides what is valid and what evidence is required.

How I built it

I built RegBridge with Next.js, TypeScript, Node.js, Zod, Vitest, the OpenAI Responses API, GPT-5.6 Structured Outputs, and Codex.

GPT-5.6 returns a declarative mapping plan rather than executable code. RegBridge treats that plan as untrusted input and requires it to pass a deterministic mapping contract before it can be used.

The application then performs canonical reconstruction, validation, truth-first remediation, code generation, compilation, execution, and test verification. The model does not directly decide whether an invoice or engineering handoff is ready.

Generated adapter code comes from application-owned templates and validated source-path segments. It is not unrestricted model-generated code. Local execution uses fixed commands, no shell interpolation, limited output, strict timeouts, and temporary-directory cleanup.

The prototype also includes an explicit deterministic mock mode so the complete workflow can be demonstrated without making an external AI request.

Challenges I ran into

The first prototype appeared stronger than it actually was. It could normalize unfamiliar schemas, but the displayed adapter and tests were still tied to the original sample. It also replaced missing tax identifiers with fabricated demonstration values.

I treated these findings as architecture problems rather than presentation problems.

I rebuilt the workflow so that:

  • generated adapters are specific to the submitted ERP schema;
  • generated tests are compiled and executed;
  • missing business data remains visibly unresolved;
  • invoice readiness and engineering-handoff readiness are evaluated separately;
  • the interface displays only evidence returned by the server;
  • structured-output failures, refusals, incomplete responses, and transport errors are classified safely;
  • no secret, private path, stack trace, or raw process output is exposed to the browser.

Another challenge was preserving the flexibility of GPT-5.6 without allowing probabilistic output to control financial validation. The final architecture addresses this by placing a strict deterministic boundary immediately after semantic mapping.

Accomplishments that I'm proud of

  • Built a working end-to-end vertical slice for multiple synthetic ERP schemas.
  • Validated a real GPT-5.6 transformation of an alternate ERP structure.
  • Generated a source-specific TypeScript adapter and executable validation tests.
  • Successfully generated, compiled, executed, and passed 5 out of 5 generated tests during the controlled real-model verification.
  • Added 66 automated repository tests covering mapping contracts, canonical reconstruction, remediation, artifact generation, API safety, runtime states, and error handling.
  • Prevented automatic invention of identifiers and other missing business facts.
  • Separated invoice readiness from engineering-handoff readiness.
  • Published the project publicly under the MIT License with reproducible setup instructions and clearly labeled synthetic sample data.

How Codex helped

I used Codex throughout the build, not only for the initial scaffolding.

Codex helped me inspect the repository, challenge the product's claims, identify gaps between the interface and the actual implementation, plan the partial rebuild, implement and test the mapping contract, build the artifact-verification pipeline, diagnose Structured Outputs compatibility, improve safety controls, and prepare the repository for public release.

The most valuable contribution from Codex was not simply generating code. It supported an evidence-driven development loop:

Inspect → test → identify contradictions → rebuild → verify → commit.

I made the product decisions, reviewed the resulting behavior, controlled permissions and real API requests, and required test or runtime evidence before accepting each major implementation phase.

What I learned

The main lesson I learned is that the quality of an AI integration depends heavily on where the model's authority ends.

GPT-5.6 is valuable for understanding unfamiliar semantics. It should not silently decide whether financial information is valid, invent missing facts, or claim that generated code works without evidence.

By combining probabilistic interpretation with deterministic contracts and executable verification, RegBridge demonstrates a practical pattern for trustworthy enterprise AI workflows.

I also learned that a visually convincing prototype can still contain architectural contradictions. Honest auditing and rebuilding made the final project stronger than protecting the original implementation would have.

What's next for RegBridge

The current version is a hackathon prototype. It is not a tax, legal, or regulatory certification product, and its controlled local process isolation is not a production-grade operating-system sandbox.

The next steps are:

  • validate the problem with ERP integrators, localization teams, and enterprise implementation consultants;
  • expand the canonical model and rule packs for additional markets;
  • add explicit human approval for remapping candidates;
  • introduce production-grade isolated execution;
  • measure the integration time saved across real ERP schemas;
  • develop an API and collaborative review workflow for engineering teams;
  • test commercial models based on integration projects, usage, or enterprise subscriptions.

Built With

Share this project:

Updates