Turn validated data models into reproducible API contracts
Artificial Interface is a model-driven development environment for data-driven APIs. A relational data model is captured, validated, and turned into a reproducible OpenAPI contract. That contract can be reused by engineering teams, CI/CD processes, runtime components, and AI agents. The project is actively evolving and is not a finished replacement for domain or security architecture.
The central workflow is deliberately deterministic: the same validated input should produce the same contract. AI can help interpret requirements and fill forms, but it is not the sole source of technical truth.
Through MCP, the builder can also be accessed by AI agents. An agent changes a structured model instead of writing arbitrary YAML or JSON as the final artifact.
| Status | Components |
|---|---|
| Implemented | Relational metamodel, visual modeling, OpenAPI generation, Swagger UI, Mermaid ERD, and contract export |
| In development | REST runtime, GraphQL adapter and composition layer, and MCP integration |
| Planned | Contract diffs, policies, SDKs, mock servers, and contract tests |
The full status matrix describes the scope and classification of each component.
This flow is based on the provided company export. It follows a saved model with three
relationally connected tables through the generated OpenAPI/Swagger specification, the ERD, and the
SQL outputs. An executed runtime request with a real response is not included in this export yet.
Saved model (project archive)
main.address:
ID integer, CITY string, COUNTRY string, HOUSE_NUMBER string, STREET string, ZIP_CODE string
main.customer:
ID integer, ID_ADDRESS integer → main.address.ID, EMAIL string, PHONE string,
FIRST_NAME string, LAST_NAME string
main.contract:
ID integer, ID_CUSTOMER integer → main.customer.ID, DURATION_MONTHS integer,
AMOUNT number, CONTRACT_NUMBER string, CONTRACT_DATE date-time
Generated resources from openapi.json
POST /transaction
GET /main/address POST /main/address PATCH /main/address
GET /main/address/{ID} DELETE /main/address/{ID}
GET /main/customer POST /main/customer PATCH /main/customer
GET /main/customer/{ID} DELETE /main/customer/{ID}
GET /main/contract POST /main/contract PATCH /main/contract
GET /main/contract/{ID} DELETE /main/contract/{ID}The individual artifacts can be inspected directly:
The Studio captures data types, required fields, unique values, constraints, and relationships as reviewable inputs to the model-to-contract workflow. Current output remains deliberately close to relational schemas and tables.
The Artificial Interface Studio is a Progressive Web App (PWA) for data modeling and API generation for architects and engineering teams. It enables you to visually define database schemas and automatically generate consistent OpenAPI documentation. With Swagger UI and Mermaid ERD diagrams, the contract and relationships stay reviewable. The AI assistant helps fill forms but does not replace model review. Teams can use the exported contract in their own engineering and CI/CD processes.
The interface keeps the data model, relationships, and derived API description visible in one workflow. This supports review without removing domain responsibility from the engineering process.
Data types, ranges, required properties, unique values, and references are explicit inputs to the model-to-contract process. They are validated where the current metamodel supports them and become reviewable parts of the generated OpenAPI contract.
The generated OpenAPI document is a contract that teams can review, diff, version, and integrate into Git and CI/CD workflows with their own tooling before connecting a runtime.
Under the "API First" principle, the interface is defined first before software is installed, servers are set up, or code is written. This allows for clear planning and coordination even before technical implementations are undertaken.
The REST runtime interprets the generated API contract and exposes standardized CRUD operations for relational data. On top of it, the GraphQL runtime dynamically creates a typed schema, translates queries into REST calls, and composes their results into a response tailored to the client.
Typed nested POST/PATCH mutations are compiled into one ordered REST
/transaction workflow call, so related writes share one atomic database transaction.
The low-level workflow is deliberately not exposed as a generic GraphQL mutation; clients can use
the REST endpoint directly when that contract is the better fit.
GraphQL client
↓
GraphQL runtime: schema · translation · relationships · batching
↓
REST runtime
↓
DatabaseClients select exactly the fields they need and can request related data as nested objects. The runtime recognizes forward and reverse relationships from contract metadata and batches repeated lookups per request instead of issuing an individual REST call for every foreign key.
REST provides the data. GraphQL shapes it into the response each client needs.
The GraphQL runtime has no data store of its own and does not replace the REST runtime. Authentication headers are forwarded to the downstream interface; security, operations, and performance requirements must be reviewed for each production environment. The technical specification documents further limits.
The generated OpenAPI/Swagger contract makes resources, operations, schemas, and relational mappings explicit for review and downstream automation.
AI agents can use the MCP project to request structured model changes and OpenAPI generation. Formal modeling and validation limit the AI's interpretation space; agent integration supports the workflow but does not replace domain review.
Artificial Interface documents the current data-driven contract based on the OpenAPI Specifications. These documentation includes:
Artificial Interface is currently still in development. This means that some features and functionalities may not yet be fully implemented or optimized. The developers are working to improve the software and add additional features to meet the users' needs.
Artificial Interface is positioned as a controlled layer between a relational data model and a technical API. The current focus is the metamodel, the Studio, deterministic OpenAPI generation, and the connected Runtime and MCP components. Additional targets such as more generators, contract tests, and stronger governance will become product promises only when they are implemented and documented.