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.

The short version. The model decides what to build. The platform decides how it is written: every change is validated, positioned and wired by PIES Studio itself, then recorded. Nothing is saved that the platform has not checked.

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

01

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.

02

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.

03

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.

RequirementDetail
GPUNVIDIA, 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 & runtimeLinux x86_64 with Docker and the NVIDIA Container Toolkit
NetworkOutbound HTTPS once, for the initial weights download. Air-gapped installs import the weights from media instead and need no egress at all.
LicenseA 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.