For operators
Purpose-built views, search flows, account pages, and action buttons for the
people who run day-to-day operations.
On the same catalog
Every read and write calls a runner capability through the normal
control-plane policy, approval, routing, and audit path.
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:
Runner
Lives in your repository. Defines standing capabilities, secret
declarations, and project context. Changes are committed and deployed.
Dashboard page
Lives in the Polycore project. Defines a presentation over the existing
catalog. It cannot add runner authority or change runner configuration.
The only production bridge
Page code receives an injected client: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.
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.
Instant and gated behavior
- Instant component
- Gated control
- Failure state
A table, statistic, or detail view calls a capability your policy clears.
The result returns immediately when the runner and downstream system
succeed.
Page lifecycle
1
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.
2
Confirm the catalog
Reuse existing query and action schemas. If the workflow needs new standing
authority, review and deploy that runner change first.
3
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.
4
Review and save
A human reviews the source and live preview before saving it to the project.
The page cannot modify runner configuration.
5
Operate and audit
Operators use the saved page. Each capability call remains visible in the
shared request and invocation history.
When dashboards are a good fit
Recurring operational workflows
Recurring operational workflows
Use a dashboard when people repeatedly combine a few reads and governed
actions around one entity or decision.
Structured, reviewable inputs
Structured, reviewable inputs
Forms and typed controls help operators construct valid action arguments
without memorizing commands.