---
title: "Page Validation"
id: "1862"
type: "page"
slug: "validation"
published_at: "2026-09-21T00:25:46+00:00"
modified_at: "2026-10-22T16:38:23+00:00"
url: "https://xedant.com/agents/portal/docs/validation/"
markdown_url: "https://xedant.com/agents/portal/docs/validation.md"
excerpt: "Checks are the portal’s “inner voice”: they watch that a page is assembled correctly and…"
---

# Page Validation

[https://xedant.com/agents/portal/docs/validation/.md](https://xedant.com/agents/portal/docs/validation/.md)

Checks are the portal’s “inner voice”: they watch that a page is assembled correctly and tell the agent what to fix. The idea is simple: problems should surface before readers see the page, not after.

## When checks run

Some checks run on every read of a page — invisibly to the reader. The rest the agent starts on request, usually before saving: that is how it makes sure nothing got broken. That check’s result is kept for five minutes, so a repeated request does not recompute everything.

## What gets checked

- **The page title** — is there one at all? A page without a title cannot be found in the tree either.
- **Access** — whether it holds a understandable value: draft, for staff, or public.
- **Block ids and width** — the ids are unique, and the width fits the allowed range.
- **Block types and their fields** — the type is known to the portal, every required field is filled, and a visualisation carries a type the portal recognises.
- **Buttons** — every action has what it needs (an address, a path, a request text or a script), and there are at most three buttons per block; for a step inside the portal, a script and a task to the agent, the new tab and the consequences after acceptance are stated explicitly.
- **Content** — whether there are empty lists and invalid values.
- **Files and scripts** — whether what the blocks reference is in place: pictures, text files, calculation programs.
- **Templates** — whether the variable substitutions hold errors.
- **Data and queries** — whether the source a block takes data from is in place, whether the query itself is filled in, and whether its waiting time and row count fit the allowed limits (see the [Data Sources & Visualisations](/agents/portal/docs/sources) section).
- **Tables** — whether the rows and cells are written correctly: does the portal understand the icon, is the colour not broken.
- **Forms that send to the agent** — whether the request template is filled in, whether it names fields the form does not have, and whether the consequences after acceptance are clear: what to refresh and what to open.

## Two kinds of messages

- **Errors** — what keeps the page from showing in full: no title, an unusable access value, a block without an id.
- **Hints** — what the agent simply forgot: an empty list, a reference to a missing picture, too many buttons. The page still works, but is worth polishing.

## What it looks like

When there are problems, a strip appears above the page: **The agent left {count} issues on this page**, with the number of findings. It expands, and every message says exactly what is wrong and what to do about it. No unpleasant riddles remain: a hint always carries a suggestion, not just a statement.

## Who sees it

Service messages are shown to the portal’s administrator only. Ordinary readers — and all the more visitors of the public site — do not see them: people come for information, not for a page assembly report. Even on a public page where something is wrong, an outsider simply sees the page without technical remarks.

Next: how the agent edits content — in the [Agent Management](/agents/portal/docs/management)
 section; how to talk to the agent about an edit — in [Chat with the AI Agent](/agents/portal/docs/agent)
; a general introduction — in [Getting Started](/agents/portal/docs/getting-started)
.

[← Back to the documentation index](/agents/portal/docs)