ARCFORGE

Generation cost and ownership cost

Until 2023 people wrote the code, and headcount and schedule determined the project. From 2024, AI agents write it. The speed problem is solved.

Something else grew instead: the sheer volume of output. Build 300 screens as 300 code files and you also have 300 things to maintain, regression-test, deploy and hand over. The cost of generating code has fallen; the cost of owning it has not.

What ARCFORGE sets out to remove is not generation cost but ownership cost.

Configuration-based composition

ARCFORGE is an enterprise application platform that recasts business systems into a form AI can operate. Three hundred screens are composed not as 300 code files but as 300 configurations.

It rests on three elements.

Action space — screens, fields, search, buttons, permissions and codes are all expressed as machine-readable structured metadata. Free-form code can express the same function in effectively unlimited ways; configuration metadata has a finite schema, so the space of correct answers is narrow and verification is determinate.

Guardrails — separation of read and write paths, server-side permission re-validation, audit records and tenant isolation are enforced in the engine. Whoever does the work, the shape of the result converges. The AI agents built into the platform can only act on that site’s own configuration, code and data; altering the execution engine itself is structurally blocked.

Reward signal — results are confirmed by adjudication, not probability.

The L1–L5 verification layers

ARCFORGE establishes the reliability of a result not from a model’s probability score but from how many of the following layers it has passed.

Layer	What is judged	Method
L1	Does the generated configuration satisfy the standard metadata format?	Format check
L2	Do the tables, fields, codes and procedures it references actually exist?	Live schema lookup
L3	Do the data definitions and storage rules hold in the target database?	Apply and compile
L4	Does the defined screen render, query and save for real?	Automated browser run
L5	Do migrated and aggregated figures match the original?	Reconciliation against source

L1 and L2 run the moment configuration is saved; L3 through L5 run as automated scripts at migration and release. Diagnostic output must state a conclusion, its evidence and the available options — closing on a guess such as “appears to be…” is not permitted.

Adjudication results and incident cases accumulate into guidance documents that are injected as prior input to every subsequent task. The aim is that a failure encountered once does not recur. Because it is the guidance that improves rather than the individual, the standard of output holds whichever model is used.

Compared with coding agents

A coding agent answers “how fast can code be generated?”; ARCFORGE answers “what can AI operate?”

	Coding agent	ARCFORGE
Output	300 files = 300 maintenance items	A single engine; one change applies across all screens
Release path	Code → build → deploy	Save and refresh
Who edits	Developers	Floor staff and business analysts
Judging results	Estimated after the fact	Determinate L1–L5 adjudication
Multi-customer operation	Source or branch per customer	One engine plus configuration

Choose a coding agent for non-standard screens, algorithm development, and one-off projects with few screens.

Choose ARCFORGE for systems with tens to hundreds of repeating standard business screens, products sold to many customers, and enterprise systems that need continuous maintenance.

ARCFORGE itself uses coding agents as a tool for custom development, but only within constraints: it writes after querying the real tables and storage rules, uses only components on an allow list, and records every instruction and execution.

Main components

Screen composition — menu and layout definition, table fields and display formats, detail entry forms, search conditions and auto-query, button actions, Excel upload and download.

Common modules — security and access control, permission matrix, multilingual labels, master codes, print formats, label issuance, scheduler, status widgets, change history, attachments, notifications, backup and restore. None of these are rebuilt per project.

AI operation — screen creation wizard, conversational configuration editing, fault diagnosis, guardrailed coding support.

Build sequence

1. Define and design — The owner describes the functions and data fields they need in natural language; from that, the table structure and menu type (query, entry, popup) are designed.
2. AI generation — ArcEdit interprets the design and produces the DDL and the screen configuration (JSON, a combination of grid G_ and detail D_ components). Refinement is conversational, with no coding. The configuration is interpreted straight away by the rendering engine with no deployment, so field layout and search conditions can be checked on the spot and further instructions given.
3. Review and release — Query, entry and update are exercised against real business scenarios; anything that does not match is re-instructed in natural language and regenerated immediately. Once verified, it reaches the live screen through configuration alone, with no redeployment.
4. Legacy migration — The existing system’s screens and database are analyzed to separate what converts to standard screens from what needs bespoke visualization. Standard screens are rebuilt from ArcSchema configuration, specialist ones as ArcEdit custom pages, and an AI verification harness then compares results against the original screens automatically to confirm the migration holds.

Adoption requirements

Deployment and servers — Both SaaS and on-premise are supported; choose according to your security policy. Air-gapped environments are served on-premise. Standard WAS and database server specifications are sufficient and a GPU is not required.

The natural-language generation features (ArcEdit, ArcAssist) do need an LLM engine, so a fully air-gapped site requires a separate discussion about how to connect one — an on-premise LLM, or an API gateway inside the secure zone.

What to prepare — The screen inventory and database schema of the existing ERP, MES or FEMS, plus business manuals and requirement definitions. For a migration, per-screen functional specifications and user scenarios are also needed to separate standard from specialist screens. Without them, the design stage has to repeat the as-is analysis, which extends the migration schedule (typically around a week).

Integration — REST API is the standard route to ERP, MES, FEMS and heterogeneous databases (Oracle, MSSQL and others). Database credentials and API authentication details for the existing systems must be available up front, and in an air-gapped environment the network path and firewall policy between the server and the target systems must already be open. Legacy systems without an API are handled by direct database integration, agreed case by case.

Permissions and operation — Multi-level RBAC across query, entry and administrator roles, with multi-tenant operation by site or department. Create, update and delete history is written to an audit log. Putting AI-generated DDL and screen configuration into production requires review and approval by an IT owner. Three-language automatic translation and a scheduled backup and restore regime are expected, along with an operating policy that allows immediate rollback on failure.

Implementation schedule

There is no client installation; a web browser is all that is required. Business databases supported are MS SQL Server, MariaDB and PostgreSQL.

The standard schedule runs seven stages from assessment to stabilization over roughly 12 weeks, adjusted for screen count and migration scope.

IMPIX holds ISO/IEC 27001 and GS Certification Grade 1.

Where it is running

Sixteen sites across different industries and functions run on a single engine. 181 business screens are defined as configuration, 221 data tables are connected, and there are zero per-screen program files.

The representative deployment is a legacy FEMS (factory energy management system) migration. Eighteen standard query and management screens were rebuilt from configuration alone, and fifteen specialist visualization screens — energy schematics, charts — were rebuilt as AI-assisted custom pages, migrating the entire system. The migration took about a week, and the same platform now has the structure to extend to six sites as separate tenants.

This is an internal migration reference. There is no external customer pilot site yet; pilots with manufacturers are planned during 2026.

Product name change

ARCFORGE was developed under the name ARCMIND. It was renamed to ARCFORGE for trademark reasons. Material dated before October 2026 may refer to ARCMIND; it is the same product.