The same valid source should compile into the same normalized intent.
CREATOR STORY · SOFTWARE ARCHITECTURE · RAIQL 1.0
I created RAIQL to make software requirements executable.
RAIQL — Requirements AI Query Language — is a declarative software-development language that turns a reviewed application contract into validated architecture and generated software artifacts.
My goal was not to create another prompt wrapper. I wanted a language with a deterministic compiler, an explicit intermediate representation, reproducible generators and a stable contract that developers can inspect, test and version.
WHY I BUILT IT
Software starts as intent, but intent is usually lost between documents, tickets and code.
Traditional projects scatter the same product decision across requirement documents, architecture diagrams, database schemas, API definitions, authorization rules, deployment files and test plans. Those representations drift. AI coding tools can accelerate implementation, but free-form prompting alone does not give a team a stable engineering contract.
RAIQL is my attempt to put that contract in one reviewable source file. The source says what the application is, which entities exist, who can do what, how data is isolated, which APIs and events are required, what environments exist and what deployment intent should be generated. The compiler then turns that declaration into a normalized model that generators can consume consistently.
THE ARCHITECTURE
A deterministic compiler at the center. AI at the edge.
The core architectural choice is deliberate: AI can help propose requirements, but it is not allowed to become the compiler itself.
01RAIQL sourceHuman-reviewable application contract
02Parser + validationSyntax, semantics and diagnostics
03Normalized IROne deterministic application model
04GeneratorsCode, APIs, tests and infrastructure
05Runnable systemInspectable output, not hidden magic
Authentication, ownership, tenancy, events and deployment are declared, not guessed.
Natural language may propose RAIQL; deterministic validation decides what is accepted.
Plugins consume a stable API and add artifacts without silently replacing core output.
WHAT RAIQL 1.0 COVERS
A stable application language, not an endless feature experiment.
RAIQL 1.0 freezes the language grammar, the plugin API and the core output contract. Maintenance releases can fix defects, security issues, documentation and generator correctness without changing the meaning of existing 1.0 source.
Read the 1.0 stability contract →✓Entities and relationships
✓PostgreSQL and Prisma generation
✓Email/password authentication and JWT
✓RBAC, ownership and tenant isolation
✓OpenAPI 3.1 and typed TypeScript SDK generation
✓Events, outbox processing and background jobs
✓Generated tests and dependency auditing
✓Environment and secrets contracts
✓Observability hooks
✓Docker, Kubernetes and AWS ECS/Fargate artifacts
✓Web, API and Expo mobile targets
✓Plugin SDK, registry and compatibility contracts
THE IDEA IN CODE
Describe the system as an engineering contract.
RAIQL is intentionally concise. A source file can describe domain entities, authorization, tenancy, tests, environments and deployment intent without hiding those decisions behind a conversational prompt.
CREATE APPLICATION "ServiceDesk";
TYPE WEB;
USE STACK
FRONTEND NEXTJS,
BACKEND NEXTJS,
DATABASE POSTGRESQL,
CLOUD AWS;
CREATE TENANT ENTITY Tenant;
CREATE USER ENTITY User;
CREATE ENTITY Ticket (
id UUID PRIMARY,
title STRING REQUIRED,
status STRING REQUIRED,
ownerId UUID REQUIRED,
tenantId UUID REQUIRED
);
OWN Ticket BY ownerId;
TENANT Ticket BY tenantId;
ADD AUTHENTICATION EMAIL_PASSWORD, JWT;
ADD ROLE ADMIN, USER;
DEFAULT ROLE USER;
GENERATE OPENAPI;
GENERATE SDK TYPESCRIPT;
GENERATE TESTS;
ENVIRONMENT development, staging, production;
SECRET DATABASE_URL;
SECRET RAIQL_JWT_SECRET;
DEPLOY AWS ECS;THE STORY
RAIQL grew from architecture work, not from a naming exercise.
I have spent years designing application platforms across backend services, web systems, cloud infrastructure, CI/CD and distributed architectures. The recurring problem is that the architectural intent often exists only in people's heads, documents or diagrams, while implementation gradually becomes the real specification.
With modern AI-assisted development, generating code is becoming easier. That makes the specification problem more important, not less important. If code can be produced faster, teams need a stronger way to state what should be generated, what security boundaries are mandatory and which parts of the system must remain stable.
That is the role I want RAIQL to play: a compact, versioned and inspectable layer between product intent and generated implementation.
OFFICIAL LANGUAGE HOME
RAIQL development lives at raiql.dev.
This page documents the creator story and design philosophy. The authoritative language specification, compiler documentation, tutorials, CLI downloads and playground live on the official RAIQL website.