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

The policy is the decider, not the model picker under AI Settings: where the two disagree the policy wins, which is what makes an air gap hold. And if governance authorises no model — no matching policy, or a deny — the request fails rather than quietly falling back to a cloud default. A request nobody approved does not run.

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

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.

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.

08 · What comes back, and what is recorded

08b · The assistant inside your applications

A deployed application can carry its own assistant, and those conversations are governed on exactly the same terms as a build: each message is evaluated against policy as it arrives — so a policy change applies to the next thing anyone types — then redacted, routed, and written to the same audit log, attributed to the tenant that owns the application and the end user who asked. An air-gapped policy therefore covers your users' conversations, not merely your builders'.

09 · More than one model

The platform is not tied to a single model. PIES Ultra is what this release ships and certifies, and the machinery around it is deliberately model-agnostic: the service reads a model's own capabilities — context window, size, family — directly from its files, so nothing has to be configured when a different model is loaded.

Two protections make that safe rather than merely possible:

Uploading your own model becomes available in the next release; the certification step is what makes it a safe promise.

10 · The AI improves from your own successful builds

Every build produces evidence: a tool call either passed the platform's validation and was written, or it did not. Those verified wins — and only those — are collected as training material on your own infrastructure. Failed attempts, retries and anything a cloud model produced are never included.

Your data, your model, your hardware: the material never leaves the machines you control, and the resulting adapter is yours.

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.

Installation, day-to-day operation and troubleshooting are covered in the PIES Private AI Installation & Operations Manual.