> ## 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.

# Glossary

> The core terms used across Polycore architecture and integrations.

<ResponseField name="Organization">
  The customer and membership boundary in the Polycore control plane. Projects,
  users, runner registrations, interfaces, and audit records are scoped through
  an organization.
</ResponseField>

<ResponseField name="Project">
  A product or operational system inside an organization. A project has its own
  capability namespace, agent context, dashboard pages, and environments.
</ResponseField>

<ResponseField name="Environment">
  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.
</ResponseField>

<ResponseField name="Control plane">
  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.
</ResponseField>

<ResponseField name="Runner">
  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").
</ResponseField>

<ResponseField name="Runner SDK">
  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.
</ResponseField>

<ResponseField name="Front door">
  An interface that initiates governed work. Current front doors include Slack,
  MCP clients, and admin dashboards.
</ResponseField>

<ResponseField name="Catalog">
  The capability metadata currently advertised by connected runners: names,
  descriptions, kinds, hazards, and input and output schemas.
</ResponseField>

<ResponseField name="Capability">
  One typed operation a runner can execute. A capability has a kind and hazard;
  callers can request it without receiving its implementation credentials.
</ResponseField>

<ResponseField name="Kind">
  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.
</ResponseField>

<ResponseField name="Hazard">
  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.
</ResponseField>

<ResponseField name="Access policy">
  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.
</ResponseField>

<ResponseField name="Effect">
  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.
</ResponseField>

<ResponseField name="Query">
  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.
</ResponseField>

<ResponseField name="Action">
  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.
</ResponseField>

<ResponseField name="Delegated workload">
  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.
</ResponseField>

<ResponseField name="Project context">
  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.
</ResponseField>

<ResponseField name="Execution credential">
  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.
</ResponseField>

<ResponseField name="Caller credential">
  A Slack identity, web session, or MCP token that authorizes requests to
  Polycore. It does not grant direct downstream access.
</ResponseField>

<ResponseField name="Runner enrollment">
  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.
</ResponseField>

<ResponseField name="Signed dispatch">
  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.
</ResponseField>

<ResponseField name="Request">
  One user-facing ask through Slack, MCP, the web app, or another configured
  interface. One request may cause several capability invocations.
</ResponseField>

<ResponseField name="Capability invocation">
  One governed attempt to run a capability against a specific project,
  environment, and runner. It records arguments, timing, outcome, result, and
  any linked approval.
</ResponseField>

<ResponseField name="Approval request">
  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.
</ResponseField>

<ResponseField name="Audit trail">
  The persistent control-plane records that connect callers and user-facing
  requests to capability invocations, outcomes, and approval decisions.
</ResponseField>

<ResponseField name="Dashboard page">
  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.
</ResponseField>

<ResponseField name="Two-layer read safety">
  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.
</ResponseField>

## Related pages

<Columns cols={3}>
  <Card title="Architecture" icon="waypoints" href="/concepts/architecture">
    See where these terms sit across the trust boundary.
  </Card>

  <Card title="Capabilities" icon="blocks" href="/concepts/capabilities">
    Understand kind, hazard, queries, actions, and catalog changes.
  </Card>

  <Card title="Integrations" icon="plug" href="/integrations/overview">
    See how the model maps onto specific platforms and interfaces.
  </Card>
</Columns>