> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polycore.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Admin dashboards

> How human-facing operational pages reuse the same governed capability catalog as AI agents.

Polycore admin dashboards are the human-facing interface to the same capability
catalog exposed to agents. A page can present operational data and actions
without receiving direct network access or production credentials.

<Columns cols={2}>
  <Card title="For operators" icon="users">
    Purpose-built views, search flows, account pages, and action buttons for the
    people who run day-to-day operations.
  </Card>

  <Card title="On the same catalog" icon="blocks">
    Every read and write calls a runner capability through the normal
    control-plane policy, approval, routing, and audit path.
  </Card>
</Columns>

## How a page is built

A dashboard page is a project-scoped React view composed from
`@polycore/ui` primitives. Polycore's page-authoring agent can draft and iterate
on the source, and a human can review or edit that source before saving it.

Pages are stored and compiled by the Polycore control plane. They are separate
from your runner:

<Columns cols={2}>
  <Card title="Runner" icon="git-branch">
    Lives in your repository. Defines standing capabilities, secret
    declarations, and project context. Changes are committed and deployed.
  </Card>

  <Card title="Dashboard page" icon="panel-top">
    Lives in the Polycore project. Defines a presentation over the existing
    catalog. It cannot add runner authority or change runner configuration.
  </Card>
</Columns>

## The only production bridge

Page code receives an injected client:

```tsx theme={"system"}
const result = await polycore.run("billing/get_invoice", {
  invoiceId,
});
```

The first segment, `billing`, is the required runner namespace. Polycore never
infers a default runner from the number of connected runners.

`polycore.run` is the page's only path to customer systems. It creates a normal
governed dispatch:

* The project and selected environment are bound by the host. When a project
  has more than one environment, the dashboard URL carries it as `?env=<slug>`
  so a shared link opens the same call target.
* Arguments are validated against the capability schema.
* Reads dispatch to the selected runner.
* Writes enter the approval path. Member requests remain pending; authenticated
  owner or admin direct writes can record inline self-approval.
* The invocation is attributed to the web caller in the same audit model.

The page never receives the action's declared secrets.

## Browser isolation

Saved pages render in a sandboxed iframe with a constrained bridge to the host.
They do not inherit the dashboard's cookies or parent DOM, and page code does
not receive filesystem, `fetch`, XHR, WebSocket, external navigation, or remote
image access. This closes URL-bearing element and image-request data-exfiltration
channels; remote media needs a future governed proxy.

```mermaid theme={"system"}
flowchart LR
  Page["Sandboxed React page"]
  Bridge["polycore.run bridge"]
  CP["Control plane"]
  Runner["Customer-hosted runner"]
  Data[("Production system")]

  Page --> Bridge --> CP --> Runner --> Data
```

<Warning>
  Page isolation reduces browser-side authority. It does not make every
  capability safe. The runner catalog, hazard classification, human gate, and
  downstream IAM remain the security boundary for production operations.
</Warning>

## Instant and gated behavior

<Tabs>
  <Tab title="Instant component">
    A table, statistic, or detail view calls a capability your policy clears.
    The result returns immediately when the runner and downstream system
    succeed.
  </Tab>

  <Tab title="Gated control">
    A button calls a capability your policy holds for approval. A member sees
    pending state while an approver reviews it. An authenticated owner or
    admin's direct button click can be self-approved inline by the web host. In
    both cases, the approval identity and outcome are recorded.
  </Tab>

  <Tab title="Failure state">
    Runner unavailability, validation failures, missing permissions, and
    downstream errors remain failures. The page should render them explicitly
    and preserve enough context for an operator to act.
  </Tab>
</Tabs>

## Page lifecycle

<Steps>
  <Step title="Choose an operator workflow">
    Start from a recurring task, not a collection of metrics. Identify the
    decisions and governed operations the operator needs in one place.
  </Step>

  <Step title="Confirm the catalog">
    Reuse existing query and action schemas. If the workflow needs new standing
    authority, review and deploy that runner change first.
  </Step>

  <Step title="Draft and preview">
    The page-authoring agent writes a React view against the real project
    catalog. Preview compilation and capability calls use explicit loading,
    empty, failure, and pending states.
  </Step>

  <Step title="Review and save">
    A human reviews the source and live preview before saving it to the project.
    The page cannot modify runner configuration.
  </Step>

  <Step title="Operate and audit">
    Operators use the saved page. Each capability call remains visible in the
    shared request and invocation history.
  </Step>
</Steps>

## When dashboards are a good fit

<AccordionGroup>
  <Accordion title="Recurring operational workflows" icon="repeat-2">
    Use a dashboard when people repeatedly combine a few reads and governed
    actions around one entity or decision.
  </Accordion>

  <Accordion title="Structured, reviewable inputs" icon="list-checks">
    Forms and typed controls help operators construct valid action arguments
    without memorizing commands.
  </Accordion>

  <Accordion title="Shared context for a team" icon="users-round">
    A saved page provides a stable operational surface while agents continue to
    use the same underlying capabilities for flexible requests.
  </Accordion>
</AccordionGroup>

<Tip>
  Dashboards do not need a separate integration. Once the runner catalog is
  connected, a page can compose it without gaining another credential path.
</Tip>