Technical Data Sheet

Technical overview of the current data-driven REST contract. This sheet documents the available CRUD core and separates it from possible future automation targets.

Implementation Status

Component	Status	Scope
Relational metamodel	Implemented	Structured databases, schemas, tables, columns, and relationships
Visual modeling	Implemented	Artificial Interface Studio
OpenAPI generation	Implemented	OpenAPI/Swagger documentation from the data model
Swagger UI and Mermaid ERD	Implemented	Visualizes the contract and relational structure
Contract export	Implemented	Download and handoff to your own Git/CI/CD processes
REST runtime	In development	Separate project for executing the data-driven contract
GraphQL facade	In development	Separate facade over a Swagger/OpenAPI-based REST interface
MCP integration	In development	Structured access for AI agents
Contract diff, policies, SDKs, mock servers, and contract tests	Planned / not presented as finished	No completed product promises

Validation Scope

Current Studio validation checks, among other things:

missing and duplicate names for databases, schemas, tables, and columns,
empty tables and missing or invalid data types,
invalid length and numeric ranges,
complete and existing references to a schema, table, and column,
different reference types as a warning and missing id columns as a warning.

This does not currently mean automatic breaking-change analysis, organization-specific policies, security governance, or a general guarantee of production readiness.

Boundary Between Data Model and API

The current implementation is deliberately data-driven: relational schemas, tables, and columns are mapped closely to CRUD resources. The OpenAPI extensions x-database-schema and x-database-table make that mapping explicit.

Relational model
        ↓ current mapping
OpenAPI CRUD contract
        ↓
REST runtime / GraphQL facade

Artificial Interface should therefore be understood today as a controlled Database-to-CRUD Contract layer. Independent domain resources, composed API resources, computed fields, and commands are possible extensions, but are not current promises of this specification.

API Specifications

Name	Data-Driven REST API
API Type	RESTful CRUD API
Project Status	Actively evolving; specific production environments require their own security, operations, and performance review
Specification Standard	OpenAPI 2.0 / Swagger 2.0, OpenAPI 3.0
Data Format	JSON
Authentication	Flexibly configurable; for example, API key, bearer auth, or custom authentication methods
Example Authentication Headers	`x-api-key`, `Authorization: Bearer <token>`
Content-Type	`application/json`
Endpoint Pattern	`/schema_name/entity`
Single Resource	`/schema_name/entity/{id}`
Supported HTTP Methods	`GET`, `POST`, `PATCH`, `DELETE`
GET Function	Retrieve, filter, sort, and paginate entities
POST Function	Create one or more entities
PATCH Function	Partially update one or more entities
DELETE Function	Delete one or more entities by ID
Batch Processing	Supported for `POST` and `PATCH` through JSON arrays
Transactional Processing	Supported for bundled data operations
Filtering	Exact filters, multiple values, date ranges, LIKE searches, and combined filters
Horizontal Filtering	Through `$select`
Sorting	Through `$orderBy`
Pagination	Through `$limit` and `$offsetId`
Multiple Query Parameter Values	Pipe-delimited, for example `id=1\|2\|3`
Date Format	ZULU/ISO time format, for example `2023-01-01T00:00:00Z`
LIKE Wildcards	`%` for any character sequence, `_` for a single character
Database Mapping	Relational database structures with schemas, tables, fields, and relationships
OpenAPI Extensions	`x-swagger-router-controller`, `x-database-schema`, `x-database-table`
Controller Model	Generic controller, for example, `GenericController`
Default Success Status	`200 OK`
Error Status Codes	`400 Bad Request`, `401 Unauthorized`, `500 Internal Server Error`
Schema Support	Data types, required fields, constraints, unique values, and relationships
Client Compatibility	Suitable for OpenAPI/Swagger-based client generation
Documentation Compatibility	Suitable for Swagger UI and OpenAPI-compatible tools
Primary Purpose	Standardized API layer for managing relational data through CRUD operations
Typical Use Cases	CRUD backends, data-driven applications, internal enterprise APIs, and API-first development
Current Building Blocks	Visual data modeling, OpenAPI generation, Swagger UI, Mermaid ERD, data-driven REST runtime, GraphQL facade, and MCP access
Automation Options	OpenAPI contract export and CI/CD integration; further targets such as clients, SDKs, mock servers, and contract tests are not presented as completed product features
Technical Focus	Reproducible model-to-contract transformation with explicit mapping to relational structures and standardized CRUD operations

Source

This sheet refers to the current Artificial Interface building blocks: the data and API model, the Studio, OpenAPI generation, the REST/GraphQL runtime, and MCP access. Detailed endpoint semantics are described in the API documentation.