PIES Studio · How it works
What happens between a chat message and a saved change
When you ask PIES AI to build something, the request passes through governance, a scoped prompt, a model, the platform's own tools, and a validation layer that owns the parts software should own — layout, wiring and correctness — before anything is written to your application. This page follows that path end to end.
FLOW · The whole path
%%{init: {'theme':'base','themeVariables':{
'fontFamily':'ui-monospace, SF Mono, Menlo, monospace','fontSize':'12.5px',
'primaryColor':'#F1EDFC','primaryTextColor':'#191527','primaryBorderColor':'#6D4FD8',
'lineColor':'#8B84A3','tertiaryColor':'#FFFFFF'}}}%%
flowchart TB
REQ["Your request
build chat · Fix with AI · AI worker · Pie Loop"]
TRI{"Triage"}
LOOP["Pie Loop — large builds only
plan, then build unit by unit"]
BUILD["Build request"]
GOV["Governance
policy → tier → model"]
PRIV["PIES Private AI
your GPUs or your private cloud"]
CLOUD["Cloud model
only if your policy allows it"]
LIC["License check"]
PROMPT["Prompt assembled
doctrine · your app · tools"]
MODEL["Model proposes a tool call"]
TOOLS["Platform tools
same catalogue either way"]
VAL["Validate · repair · lay out · wire"]
DB[("Your database")]
OUT["Build receipt + audit record"]
REQ --> TRI
TRI -->|"most requests"| BUILD
TRI -->|"large build"| LOOP
LOOP --> BUILD
BUILD --> GOV
GOV --> PRIV
GOV --> CLOUD
PRIV --> LIC --> PROMPT
CLOUD --> PROMPT
PROMPT --> MODEL --> TOOLS --> VAL --> DB
VAL -.->|"results fed back"| MODEL
DB --> OUT
classDef plain fill:#FFFFFF,stroke:#C9C2DC,color:#191527;
classDef localNode fill:#E7F7F1,stroke:#0E9F6E,color:#0B3D2C;
classDef cloudNode fill:#EAF2FE,stroke:#2563EB,color:#12305F;
classDef repairNode fill:#FDF3E3,stroke:#B45309,color:#5B3406;
class REQ,TRI,LOOP,BUILD,GOV,PROMPT,MODEL,TOOLS,DB,OUT plain;
class PRIV,LIC localNode;
class CLOUD cloudNode;
class VAL repairNode;
Green is the private route — the model runs on hardware you choose, and your prompts, data and application definitions never leave your network. Blue is a cloud model, used only when your governance policy permits it.
01 · Governance decides before anything runs
Policy
The organisation on the request selects the policy. An air-gapped policy routes every request to a model running inside your own network, with no external call available.
Tier
The request is classified by weight. A small edit and a full application build are not given the same budget, and the tier is part of the audit record.
Model
The policy and tier choose the model. On the private route the request is pinned to the model actually loaded on your server, so what ran is never in doubt.
02 · The job is scoped before the model sees it
PIES Studio does not hand the model an open-ended instruction. It assembles a scoped job: what you asked for, a map of what already exists in your application, and the specific tools the job needs. A request to design a data model is given the data-model tools; a request to design a screen is given the screen tools. Scoping the tools this way removes whole classes of mistake before they can happen — a screen job cannot wander into your database schema, because the tools to do so are not present.
03 · How the prompt is assembled
%%{init: {'theme':'base','themeVariables':{
'fontFamily':'ui-monospace, SF Mono, Menlo, monospace','fontSize':'12.5px',
'primaryColor':'#F1EDFC','primaryTextColor':'#191527','primaryBorderColor':'#6D4FD8',
'lineColor':'#8B84A3','tertiaryColor':'#FFFFFF'}}}%%
flowchart LR
subgraph SYS["SYSTEM block · systemMerged"]
direction TB
S1["Tier prompt (~2.3k chars)"]
S2["App map — what already exists"]
S3["KB artefacts (80k-120k budget)"]
S4["Tool catalogue + output rules"]
S1 --> S2 --> S3 --> S4
end
subgraph USR["USER block · assembleContext()"]
direction TB
U1["The request — always kept"]
U2["Tool results, newest first"]
U3["Omission notice for the rest"]
U1 --> U2 --> U3
end
BUD{"budget = cap - system - request - 1000"}
SEED["Seed — trailing assistant message"]
SEND["Sent to pies-llm"]
SYS --> BUD
USR --> BUD
BUD -->|"oldest results dropped first"| SEND
SEED --> SEND
classDef plain fill:#FFFFFF,stroke:#C9C2DC,color:#191527;
classDef localNode fill:#E7F7F1,stroke:#0E9F6E,color:#0B3D2C;
classDef repairNode fill:#FDF3E3,stroke:#B45309,color:#5B3406;
class S1,S2,S3,S4,U1,U2,U3,SEND plain;
class SEED localNode;
class BUD repairNode;
The system block is built once per job; the user block is rebuilt every turn. When a long build approaches the context limit, the oldest tool results are dropped first and the request itself is always kept, so the model never loses sight of what it was asked to do.
04 · Inside the model
PIES Ultra
The private model shipped with this release. It runs as a container on your GPUs and speaks the platform's tool protocol natively.
Licensed
The service starts without a license but refuses inference until a valid one is installed. Health and administration endpoints stay reachable so the reason is always visible.
Private
Prompts, application definitions and data stay on your infrastructure. On an air-gapped install nothing in the path requires outbound access.
05 · From reply to tool call
The model does not write to your application directly. It proposes a tool call — a structured request such as "create these tables" or "add a data table to this screen". The platform reads that call, and where a model expresses a correct intention in a slightly wrong shape, the platform repairs the shape rather than rejecting the work. A malformed call costs a retry; a rejected-but-correct call would cost the whole step.
06 · The tools
The catalogue is the same whichever model runs. What changes per job is how many are visible at once — a data-model job sees a handful, a screen job sees the screen set. Delete tools appear only when the request explicitly allows deletion.
Read & inspect 22
Never change anything. Read the data model, screens, events, functions, generated code, and canonical examples of each element.
Compose 7
A small intent in, a complete widget out. The server builds the section, table, KPI card, chart, form or custom component — positioned and bound for you.
Write documents 11
Screens, tables, functions, events, menus, processes, custom widgets and REST integrations, plus surgical edits to a single widget.
Artefacts & source 5
Requirement documents you attach, and connected source repositories.
Delete 4
Only present when the request allows deletion.
07 · The platform validates before it writes
This is the step that decides whether a build is trustworthy, and it is deliberately not left to the model.
Validated
Every payload is checked against the real schema: a widget bound to a table that does not exist, a step that is not a real platform action, an event whose function is missing — each is caught here, not discovered later in a broken app.
Repaired
Where intent is unambiguous, the platform corrects rather than refuses — a near-miss action name, a screen referenced before it was created, an empty placeholder widget.
Laid out
Position and size are computed by the platform against the page's drawable area, so widgets line up and stay within the page rather than depending on a model's arithmetic.
Wired
A form is saved with the function and submit event that make it work. A data view is saved with the function and on-load event that fill it. Working software, not a picture of it.
08 · What comes back, and what is recorded
Build receipt
A server-verified summary of what was actually saved — tables, screens, functions, events, menu — counted from the database rather than from the model's description of its own work.
Audit record
Organisation, model, tier, token usage and the governance decision are recorded for every request, whether it ran locally or in the cloud.
Reversible
Each build is a version. Rewind restores the application to the state before it, and closes anything the rollback removed.
SPEC · Running PIES Private AI
PIES Ultra runs as a single licensed container on hardware you control — your own servers or a private cloud account. The same image, license and behaviour apply in both.
| Requirement | Detail |
|---|---|
| GPU | NVIDIA, 256 GB+ total VRAM — for example 2× H200, 2× B200, or 4× A100 80GB |
| Disk | ~350 GB free — the model weights plus download headroom |
| OS & runtime | Linux x86_64 with Docker and the NVIDIA Container Toolkit |
| Network | Outbound HTTPS once, for the initial weights download. Air-gapped installs import the weights from media instead and need no egress at all. |
| License | A valid pies_studio.license. Without it the service answers
health and administration calls and refuses inference. |
Installation, day-to-day operation and troubleshooting are covered in the PIES Private AI Installation & Operations Manual.