What happens between a chat message and a saved change

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.

PIES Private AI 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.

Your hardware, your choice

NVIDIA GPUs — your own servers, a rented GPU, or a cloud VM in your tenancy — and, for smaller teams, an Apple Silicon Mac running PIES Private AI Lite. The same engine and the same behaviour in every case.

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, a section title that copies planning wording such as “Contacts List Screen (Table)” (saved as “Contacts List”), a page heading that names some other application instead of yours (replaced by the name of your app's main table, such as “Contacts”), or text whose colour would be unreadable on what it actually sits on: a white title placed below a coloured header band is saved dark, while a title inside the band keeps its white. The same applies to subtitles and any other text colour the AI sets on a widget, including colours taken from your theme's text colours. Text is judged against the WCAG AA contrast level of 4.5:1: a muted subtitle that falls just short is saved in a slightly darker grey so it still reads as a subtitle, while text far below it is saved in your main text colour. This check runs on every way the AI saves a screen — a new screen, a whole new app, an inline edit, a style change or a patch to some widgets — and judges each colour against your app's theme, including the page background, so a weaker model cannot save white text on a white page. A generated theme whose sidebar text would be unreadable on its sidebar background gets the theme's darker brand colour behind the sidebar, and is saved as a new theme rather than over a built-in one. A custom widget the AI writes takes its colours from your app's theme, so changing the theme recolours its buttons and borders too; a widget that draws on a canvas, such as a game, keeps the colours it was written with, and a custom widget built earlier picks up the theme once you ask the AI to regenerate it. Dashboards are built from the stock KPI card, chart and table widgets; the AI writes a custom widget only when you ask for a custom widget or component, a game or an interactive component. Landing pages are assembled from ready-made sections in your theme's colours, including a split hero with the copy beside a picture: a media-library image you name, or else an illustration drawn from your theme, so nothing depends on an external image. Ask for a map of a table with latitude and longitude columns and you get a map with a marker for each row, in your theme's primary colour, and a list of the same locations beneath it; a table without coordinates gets the location list only. Ask for picture cards of a table with an image column, such as a photo, logo or thumbnail, and you get a grid of cards three across, each with the picture on top, the record's name beneath it and a second detail line, in your theme's colours; a table without an image column gets the same cards with text only. A dashboard's content spans the full width of the canvas, and KPI cards asked for together share one row of up to four cards. A sign-in, sign-up or password-reset screen is the exception: its form sits in a card about 560 pixels wide, centred on the page, with Email and a masked Password field. An add or edit form for one of your tables sits in a single card about 720 pixels wide, centred on the page, with its title lined up above it and the Cancel and Save buttons inside the card under the last field; four fields or fewer stack in one column, more fields share two columns, and the screen is only as tall as the form plus a small margin. Every screen the AI lays out is as tall as its content plus your app's top bar and a small margin, and when an AI edit adds or removes a section the screen grows or shrinks to match, so the last section is never cut off and no empty band is left at the bottom. Dashboards and landing pages follow one spacing scale: about 24 pixels between side-by-side widgets, about 32 pixels between sections, about 20 pixels of padding inside cards, chart panels titled with about 16 pixels of inner padding, KPI cards in a row at equal height, small uppercase section labels, and hero text no wider than about 720 pixels. A KPI card always shows a number, so a date field such as a due date is not made into one. A save that would leave a screen with no widgets at all is refused unless you asked to clear it, so a build turn cannot empty a screen by accident. When the AI first adds content to the Home Page of a new app and you have not edited that page, the starter welcome content is replaced rather than left above the new widgets; a Home Page you have changed is kept. The AI also cannot end a build while a screen it created holds only a title band: it must add the table, cards, chart or form the screen is for first. If it lists the same table column twice, the table shows that column once. A page title the AI adds without a position goes at the top of the screen, above the content. When you ask to add a form, chart or KPI cards to the screen you have open, the AI adds just that section and leaves the rest of the screen as it was, placing it where you asked: a form asked for above the list goes above the list. A whole-app build always ends with a real landing screen: the starter Home Page is rebuilt in place as a dashboard from your data (or a welcome screen with a call to action when there is no data yet), then renamed to the name the AI planned, with its menu item following the new name. When your request names a screen, such as “a Customer List screen”, the screen is saved under exactly that name: the AI does not swap it for a near variant such as a plural or a different capitalisation. If you ask for a screen with KPI cards, charts, tables, lists, forms or record details in an app that has no tables yet, the screen is not built and nothing is saved; the assistant tells you to create the tables first (in Build > Database, or by asking it to create the data model) and then ask again. If the same request also names a new table with its columns, such as “Add a Sales table (region, month, amount) and a Dashboard with a bar chart”, the assistant builds the whole thing in one go: it creates the table first, then the screens that use it. If your request says not to create tables, such as “compute everything live from the sites and alarms tables, do not create new tables”, and the app already has tables, the AI keeps your data model as it is: it adds no tables, functions or record-detail screens, builds the screens on your existing tables, and tells you it kept them. Asking to design a page with no data, such as a welcome or landing page, still works on an app without tables. If you ask for an empty screen, or one with just a heading, you get exactly that: a single heading section, without the getting-started cards a landing page on an app with no tables would otherwise show. When you ask for a screen and say how its data should be filtered, for example by status or by region, the screen is checked for a filter once it is saved; if it has none, the AI takes one more pass to add a filter dropdown. Ask for a filter bar over a table and you get a bar in your theme's colours with one dropdown per filter column, such as status or category; the choices are the values in the table, picking one narrows the rows to that value, and All shows every row again. This works the same in React and Angular apps. A list screen with filters shows its table once: the filterable table under the filters is the only table for that list, and a short muted line under the list heading tells you how to filter, with no empty box around it. If the AI plans a separate “Filter” form that is not tied to any table, it is turned into filter dropdowns on the table it filters, so you never get a Submit button that does nothing. When you ask for a screen that shows only some rows, for example “only sites where critical is true”, its tables, lists and charts are built with that condition, so they show only the matching rows. A KPI card counts with Count, Sum, Average, Minimum or Maximum; if the AI gives a card any other kind of total, the card is set back to Count and the AI is told to count just the matching rows with the card’s filters, such as sites where is down is true. A detail screen the AI builds for one record, such as a contact or a ticket, loads that record from the id in the page address when it opens and shows its values; a detail screen built with an earlier version shows dashes until you ask the AI to rebuild it. A detail screen opens with a header and a Back to button that returns to its list, then the record card; it does not add tables, KPI cards or charts for the whole table under the record.

Asking for soft or pastel colours, such as “use soft pastel colours for this screen”, switches the app to a readable pastel look (theme “Design: Pastel”) in place of the look the AI picked when it built the app; a theme you chose or made yourself is never replaced. Asking for purple in the same way (“restyle the page in purple”; violet, lilac, lavender and plum work too) switches the app to a readable purple look (theme “Design: Purple”) on the same terms. Asking for a header bar colour, such as “use a dark navy header bar with white text” (navy, black, charcoal, teal and white work too), changes only the app’s header bar: it uses the text colour you name, or otherwise one that reads clearly on the bar, and the rest of the app keeps its look.

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. A row of cards, charts or tables that stops short of the screen's width is widened to the edge, keeping its gaps; a row beside a filter panel is left as built. When the AI places a screen's widgets itself, a large empty band above the first widget or between two widgets is closed up to about 24 pixels, so the content starts near the top and sections follow one another without a blank gap.

Ask for an activity feed or timeline of a table and you get a single column of entries, newest first by the table's date, each showing when it happened, a headline and an optional detail line beside a marker in your theme's primary colour, readable on light and dark pages.

Ask for tabs over a table, for example “tabs by status”, and you get an All tab plus one tab per value of that column, up to four, each showing the table filtered to its value. The tabs are split on the column you name, or else on the table's status, stage, type or category column, and their labels stay readable in light and dark themes.

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. Ask for a function and say what starts it, such as “when the Close button on the Tasks screen is clicked”, and the button is saved with a click event that calls the function; a button or screen that does not exist is reported back rather than guessed. Events that do more than call a function are built the same way: a button that opens another screen (passing the record's id when the button sits on a record), asks “Are you sure?” before it acts, goes back, sets a field's value or shows a message, and a screen that runs a function when it opens. When an event cannot be built as asked, for example opening the selected record from a button on a list that has no selected record, the receipt says what was not applied. When you ask the AI to fix problems in functions you already have, such as “fix every problem in the Problems list”, it edits those functions in place rather than building new ones beside them, and your tables, screens and data are left as they are; the receipt shows the functions as updated, with none added. If it tries to save a fix under a function name your app does not have, the save is refused and the AI is shown the functions that do exist. Working software, not a picture of it.

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. A style request that would change nothing is reported as “no change … nothing was saved”, not as an update.

When a screen was saved, the receipt ends with a design check of its text contrast, read from the saved screen after PIES has repaired what it can: “✓ Design check: text contrast readable on the saved screen(s)”, or “✗ Design check failed: illegible text on screen” with the number of unreadable labels. The check covers text contrast only, not layout.

If the model names a table your application does not have, PIES uses the closest real table instead, for example claims_table becomes claims and payments_table becomes claim_payments. A section that still cannot be matched to your data is left out, and the rest of the screen is saved. The receipt then reads “Saved with N warning(s): …” and lists each table it substituted and each section it left out, so you can ask for the missing part again. A screen fails only when nothing usable is left.

A message meant for when there is nothing to show, such as “No tasks yet — you're all caught up”, becomes the empty message of the screen's table instead of a band that is always visible above it, so the screen never says “no tasks” above a list of tasks. The built application shows it only while the table is empty. On a screen with no table, or when the message comes with an action button such as “Add your first task”, it is shown as a centred card with a dashed border in your theme's colours, with the title, a short explanation and the button.

Which model answered

The receipt and the model chip on each answer name the model that actually produced it, as reported by the server, not the one the policy asked for. When the two differ, the chip shows a ⚠ warning with the reason: the answer was replayed from a saved recording, recorded on a cheaper model, or served by a fallback provider because the first choice failed. A server running in test mode shows a “Test mode” pill on every chip, and Why? lists each call with its model, source, the model the policy chose, and tokens. Models are always shown by their product name, on the chip, in Why?, in error messages and in the AI audit, and an answer served by PIES Private AI is labelled 🔒 Private.

Audit record

Organisation, the model that actually answered, tier, token usage and the governance decision are recorded for every request, whether it ran locally or in the cloud. Both build engines go through the same governance: the same request gets the same model, the same redaction and the same audit fields, and every call's tokens count towards your organisation's budgets, whichever provider answered.

Reversible

Each build is a version. Rewind restores the application to the state before it, and closes anything the rollback removed.

Large edits

Redesigning a whole dense screen can take a few minutes; Studio waits up to five minutes for it. If it still has not answered, Studio tells you the change may still be applied in the background and reloads the screen shortly afterwards, so check the canvas or use Rewind before trying again. If a reply is too long to finish, you are told so and asked to edit one section of the screen at a time.

Every saved screen is checked first, whichever model answered. A redesign that would remove most of a screen without putting anything in its place is not saved: the assistant restyles the existing widgets instead, or asks you to confirm. Text that would be hard to read against its background, such as dark text on a dark band, is recoloured automatically and you are told it was adjusted. When a redesign gives the screen a new header, that header replaces the old title banner rather than sitting above it, so the screen keeps a single header.

A redesign keeps what the screen is for. Sign-in screens (Login, Register, Forgot Password, Set Password) only get a hero, text, calls to action and a sign-in form that is not tied to your data; tables, KPI cards and charts are never added to them. On other screens a redesign restyles, reorders and retitles the sections already there, and adds new kinds of section only when your request names them.

Every screen the AI builds, including a single screen built on its own, starts from one of the design styles, so it matches the rest of your app with every model, PIES Private AI included; a theme you made yourself is always kept. Sections come finished: each KPI card has an icon and a coloured accent bar, and shows the change against the previous 30 days when the table has a date column; charts have axis titles and a legend, and a chart on its own sits in a titled panel; tables have search, filters, column choice and sorting; and the hero of a landing page shows an illustration in your theme's colours beside its text.

The platform's shape, not the model's habit

Every model family has its own way of expressing a tool call. Rather than trusting that, the platform can constrain a model's output to exactly the shape it expects — so a call is valid by construction, whatever the model was trained on.

Certification before trust

A model is asked to complete a small real build, and the result is graded by the server from what was actually saved — never from the model's own account of itself. The verdict is recorded against the model: build-capable, chat-only, or failed.

Honest degradation

Only build-capable models are offered builds. A weaker model still answers questions instead of producing broken applications — the platform tells you what it can do rather than finding out in your app.

Bounded by grants, not by prompt

What an agent may touch is a set of switches and an app scope, enforced by the platform. Its instructions describe the job; they do not widen what it can reach. Creating and deleting applications is never permitted.

The sequence is code

A delivery is driven by the platform, not by one model's judgement: each card walks the steps its playbook defines, one at a time, and is verified against the application itself — tables, functions, screens, the board — rather than against what the model said it did.

Frozen versions

Deploying an agent freezes its instructions, tools and triggers into a numbered version. Runs record the version they executed, so a run that ignored an edit is telling you the edit was never deployed.

Collect

Accepted calls from your builds accumulate alongside a set of canonical examples generated by the platform's own builders — the ground truth for widget shapes, step structures and event wiring.

Train

On demand, the collected material is filtered for quality and used to fine-tune a small adapter — a lightweight layer on top of the model, trained on your GPUs. Serving pauses for the training window and resumes automatically.

Promote only if better

A new adapter must pass the same certification as any model before it is served. Nothing is promoted on its own say-so, and a promotion can be reversed.