# Built by AI, approved by you > You state what is needed, an AI assistant turns it into a specification you approve, an AI agent builds it through gates. Nothing reaches a live system without a person saying so Source: https://aipril.dev/docs/apps/authoring ## The whole path ```mermaid flowchart TD K["What it already knows:
your catalogues, models and processes,
your other apps, your knowledge base,
and how this is usually done"] --> B A["You state what is needed
in your own words"] --> B["AI assistant
asks back, writes a specification"] B --> C{"You approve it"} C -->|"not yet"| B C -->|"approved"| D["Draft: the app is registered"] D --> E["AI agent writes the artifacts
each validated as it lands"] E --> F["Prototype: it runs
on your own data"] F --> P["Canvas: move blocks yourself
or ask the AI agent to,
pin comments, walk the route"] P --> G{"Ready?"} G -->|"change something"| E G -->|"yes"| H["Published: an immutable version"] H --> I["Installed and running"] ``` Nothing is built before the specification is approved, and nothing goes live before a version is published. Those two gates are the reason this is not "the AI wrote something into our system". ## Stating what you need You do not write requirements. You describe the situation: what the request is, who raises it, who signs it off, what makes it urgent, what happens when it is refused, what the report at the end has to show. The AI assistant asks back. This is the part that decides everything downstream, and it is where a good analyst earns their fee: what happens when the approver is away, what if the amount changes after approval, does a rejected request come back or start again, who may see the price. What the AI assistant produces is a **specification**: the entities and their fields, the processes and their statuses, the roles, the screens, the reports, and the rules on all of it - written down in a form a person can read and argue with. **And you approve it.** What you read is the description of what is about to be built, not a summary of what already was. Change it, cut it, add the thing you forgot; it is cheaper here than anywhere later. ### It starts from what you already have The reason those questions are good ones is that the assistant is not working from your sentence alone. Before it proposes anything it reads what already exists: - **Your catalogues, your data models, your org structure** - so a field it proposes points at your real warehouses and your real positions, not at invented ones. - **Your existing processes, and the ones in your other applications** - a purchase approval starts from how approvals are already built here, so a new app fits the ones beside it instead of introducing a second way of doing the same thing. - **Your knowledge base** - the documents, rules and decisions your company has put there, retrieved by meaning, not by exact wording. See [Knowledge](https://aipril.dev/docs/harness/knowledge.md). - **What the platform can do** - the capabilities available to build with, so the specification describes something buildable instead of something that fails three stages later. - **And how this is usually done.** It has seen a great many purchase approvals, service desks and onboarding flows, so what comes back includes the parts your description did not mention: the rejection path, the escalation, the status everybody forgets until March. That is the difference between an assistant that transcribes what you said and one that gives you a first draft worth arguing with. ## Building, through gates Approval starts the build, and it advances through stages, not in one leap. | Stage | What exists at the end of it | |---|---| | **Draft** | The application is registered and has a place to be built in | | **Specification** | The AI agent writes its artifacts - the data model, processes, workbooks, dashboards, pages, agents - and each is validated as it lands | | **Prototype** | It runs on your own data. You open its pages on a canvas, move the blocks around, file a test request, watch the route, look at the dashboard | | **Published** | A version, sealed and installable | The prototype stage is the one that matters in practice. Reading a specification tells you whether it is right in principle; filing an actual request through it tells you whether it is right. ## The canvas The prototype opens on a **canvas**, and this is where most of the real design happens. If you have used Figma, you already know the feel: the thing itself in front of you, select and drag, comments pinned where the problem is rather than described from memory. Two things differ here. This is the application itself, running on your data, and you are not the only one who can move it: **you can edit by hand, or you can ask the agent.** **You move it yourself.** Select a block, drag it, resize it, snap it to the grid, change what it shows, undo when that turned out worse. Layout is the thing nobody can judge from a description and everybody can judge from a screen - so "the amount should be beside the status, not under it" gets fixed by the person who thinks so, in the ten seconds it takes, instead of becoming a ticket that comes back in a fortnight. **Or you ask for it.** Select a block and say what should change - "put the totals on the right", "make the status a coloured chip", "this list should show the owner as well". The agent edits the same definition you would have edited by hand, and you see the result where you are looking. Point when pointing is faster; describe when describing is faster. Most sessions are both, alternating. **You discuss it on the thing itself.** Pin a comment to a block and the conversation is attached to what it is about, not to a screenshot pasted into a chat where nobody can tell which version it was or whether it was ever addressed. Mention the person who needs to answer and it reaches them through their own channel; resolve the thread when it is done. **And what you moved is a change to the description.** This is what separates it from every drag-and-drop builder: the canvas edits the application's own definition, so the arrangement is part of the version, ships with it, installs with it, and can be diffed against the last one. Nothing is a local tweak that somebody has to remember to redo. So the review that usually costs two weeks of screenshots and comment threads becomes an afternoon around one screen: the people who will use the app push a request through it, say what is missing, and watch it change while they are still in the room. The same canvas is how pages are built and changed afterwards - see [Portals and pages](https://aipril.dev/docs/cms.md). Validation runs throughout, not at the end: the platform refuses an artifact that does not fit its own rules at the moment it is written, with a precise reason, instead of failing later in front of a user. ## Changing an app that is already live The second path gets used far more often, and it is deliberately more formal. ```mermaid flowchart LR R["Somebody asks for
a change"] --> O["A change request
is opened"] O --> W["AI agent writes
into that request"] W --> C["It is classified:
what kind of change,
what it touches"] C --> H{"A person confirms"} H -->|"no"| W H -->|"yes"| M["Merged"] M --> V["A new version"] V --> I["Installed where it is wanted"] ``` The important box is the one that says a person confirms. A change to a live application is not applied because an AI agent believed it was right; it is proposed, described, classified by what it affects, and merged by somebody who accepts it. And because the running version is immutable, none of that disturbs the people using the app today. They keep using the version they have until the new one is installed. ## What you can see at every point - **The description, in readable form** - what this application is, not what it does when you poke it. - **The difference between two versions** - what changed, not a changelog somebody remembered to write. - **Its documentation, generated from the description**, so no document drifts out of date. - **The history**: who changed what and when, on the same footing as any other record. ## Who is allowed to do this Authoring is a permission, not a role everybody gets by accident. Someone with it can author applications their own organisation owns; nobody can grant themselves an app belonging to another one. Publishing to a shared catalogue is a separate step again, and passes moderation before anyone else can install it. ## What you end up owning Two things, and they are what the whole conveyor is for. **A versioned asset, not a system somebody configured.** Every version is kept. What changed between March and now is a question with an answer instead of an archaeology exercise; rolling back is installing the previous one; and the version people are working in today does not move because somebody edited something this afternoon. One department can stay where it is while another tries the next version. And because the application is a description a person can read, the knowledge of how your operation works stops living in the heads of three people and starts living in something the company owns. **And it can travel.** An application is self-contained, so it installs more than once - another division, another legal entity, another country's operation - and it can be published to a catalogue. Your own, for reuse inside the group, or the shared **marketplace**, where somebody else can install it. Publishing there passes moderation instead of going live because its author pressed a button. It works in the other direction too: take an application somebody else built, install it, and make it yours. Your copy is a fork - private to you, changed as far as you like, and none of it touches the original or anyone else's copy. What is already published is catalogued under [Solutions](https://aipril.dev/docs/solutions.md). That is what gives internal work a shelf life. The process you finally got right is a product you can hand to the next division, or to somebody else's company. ## Next [Under the hood](https://aipril.dev/docs/apps/under-the-hood.md) - what an application is as an object, and what makes installing and upgrading one safe. And [Company knowledge base](https://aipril.dev/docs/overview/knowledge-base.md) - what it means that the description *is* the system, and why that is the point and not a side effect.