The customer and membership boundary in the Polycore control plane. Projects,
users, runner registrations, interfaces, and audit records are scoped through
an organization.
A product or operational system inside an organization. A project has its own
capability namespace, agent context, dashboard pages, and environments.
A concrete call target within a project, such as
dev, staging, or prod.
An environment selects a runner and its downstream identity. Dashboard and
agent content does not need to fork with every environment.Polycore’s cloud service. It authenticates and routes callers, holds
governance state, creates approvals, records requests and invocations, runs
the agent loop, and serves the web, Slack, and MCP interfaces. It does not
store customer execution credentials or execute customer operations.
The customer-owned execution half of Polycore: source (
polycore.json,
actions, project context) and the long-running process deployed from it. A
deployed runner belongs to one project and environment, opens an outbound
connection to the control plane, advertises capabilities, resolves local
credentials, and executes signed dispatches. Named by product in conversation
(for example, “the alpha runner”).The per-language library used to build a runner. Today that is the Node
package
@polycore/runner. It supplies built-in query families, action
authoring (defineAction), config loading, and the control-plane connection.
Bare “runner” never means this package.An interface that initiates governed work. Current front doors include Slack,
MCP clients, and admin dashboards.
The capability metadata currently advertised by connected runners: names,
descriptions, kinds, hazards, and input and output schemas.
One typed operation a runner can execute. A capability has a kind and hazard;
callers can request it without receiving its implementation credentials.
The implementation shape of a capability. A
query is a generic read surface
supplied by the runner. An action is a named, customer-authored operation. A
code capability is an opt-in delegated workload. Kind does not decide
whether approval is required.A declared property of a capability and one input your access policy weighs
when governing an invocation.
read marks a side-effect-free operation,
write an operation that changes state, and unknown is reserved for
delegated code, which always remains pending for human review.Code in your runner repository that decides whether an invocation dispatches,
waits for an admin, or is refused. An action carries its own
policy; the
capabilities Polycore ships are covered by policy.ts at the runner package
root. With no policy, the hazard decides.What an invocation would do, computed before it does it: for a Postgres write,
the exact rows it would change, the columns it would assign, and the tables a
foreign key would carry it into. Counts and names only, so it is safe to keep
on the audit trail. Policy reads it instead of the statement text.
A generic, read-only capability family built into the runner SDK. Current
integrations include Postgres schema discovery and SQL reads plus Firestore
document, query, aggregation, and schema-grounding operations.
A named TypeScript capability loaded from the customer’s runner. It declares
title, description, hazard, Zod input and output schemas, local secret names,
and a
run implementation. Actions are authored against the runner SDK.An opt-in
code.execute capability that runs one approved workload in a
disposable runner-side container. It has kind code, hazard unknown, and is
absent unless the runner has a reviewed sandbox configuration.A concise customer-authored document that explains project-specific terms and
data conventions to the agent. The runner advertises it at connection time. It
must not contain secrets.
A database password, service-account identity, or API key used to call a
downstream system. It is resolved by the runner in customer infrastructure and
is not sent to the control plane or caller.
A Slack identity, web session, or MCP token that authorizes requests to
Polycore. It does not grant direct downstream access.
The binding between a deployed runner process and one Polycore organization,
project, and environment. Enrollment provisions the runner id, join token, and
signing material used by the control-plane connection.
The control-plane message that authorizes one runner invocation. It carries
the capability and arguments and is signed with runner-specific material that
the runner verifies before execution.
One user-facing ask through Slack, MCP, the web app, or another configured
interface. One request may cause several capability invocations.
One governed attempt to run a capability against a specific project,
environment, and runner. It records arguments, timing, outcome, result, and
any linked approval.
The decision record created for one invocation your policy holds for approval.
It can remain pending for a human, or a direct web action may be self-approved
inline for an authenticated owner or admin.
unknown code always remains
pending.The persistent control-plane records that connect callers and user-facing
requests to capability invocations, outcomes, and approval decisions.
A project-scoped React view stored by the Polycore control plane. It runs in a
sandboxed iframe and reaches customer systems only through the injected
polycore.run governed dispatch bridge.Read-only enforcement from the downstream identity and the runner’s
constrained query implementation. Examples include a Postgres
SELECT role
plus a read-only transaction, or Firestore viewer IAM plus read-only SDK
methods.Related pages
Architecture
See where these terms sit across the trust boundary.
Capabilities
Understand kind, hazard, queries, actions, and catalog changes.
Integrations
See how the model maps onto specific platforms and interfaces.