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

# The integration process

> What an early-access Polycore integration looks like, from scoping through production validation.

Polycore integrations are collaborative. We work with your engineering and
security teams to choose an initial workflow, define the authority it needs,
prepare your runner, and verify the governed path end to end.

<Info>
  Polycore is in early access and is not self-serve. These docs show the
  technical shape so you can evaluate the system before we start. You will not
  be expected to assemble the integration alone.
</Info>

## What we build together

The first integration is intentionally narrow. It should prove the full
operating model without asking you to move an entire internal-tools estate at
once.

<Columns cols={2}>
  <Card title="A useful read" icon="scan-search">
    A real question against production data through a constrained capability
    your policy clears to answer instantly. Examples include a count, an account
    lookup, or an operational summary.
  </Card>

  <Card title="A governed change" icon="shield-check">
    A representative change through a typed action. Polycore holds the request,
    a human approves or denies it, and the runner executes only after approval.
  </Card>
</Columns>

That pair validates credentials, routing, grounding, policy, approval, failure
handling, and audit attribution.

## Who does what

<Columns cols={2}>
  <Card title="Your team" icon="building-2">
    You choose the workflow, approve the trust and IAM design, create scoped
    access in your cloud or datastore, review the integration code, and own the
    deployed runner.
  </Card>

  <Card title="Polycore" icon="orbit">
    We map the capability design, prepare your runner, provision the
    control-plane side, pair the runner, configure the initial interfaces, and
    validate the complete flow with you.
  </Card>
</Columns>

Your production credentials are created and stored on your side. Polycore does
not ask you to paste them into our cloud or send them to us.

## The path to production

<Steps>
  <Step title="1. Scope the first workflow">
    We start from an operation, not a connector checklist. Together we identify:

    * The people or agents that need access.
    * The system and environment they need to reach.
    * One high-value read.
    * One write whose approval behavior is representative.
    * The result shape and audit evidence your team needs.

    This keeps the first catalog small enough to review while exercising the
    important trust boundaries.
  </Step>

  <Step title="2. Design least-privilege access">
    We map each capability to the narrowest authority the downstream system can
    enforce.

    <Tabs>
      <Tab title="Postgres">
        A read-only role or read replica backs generic queries. Actions that
        change state use separate credentials with only the grants they require.
      </Tab>

      <Tab title="Firestore">
        A runtime service account with `roles/datastore.viewer` backs generic
        queries. Actions that change state use a distinct service account and
        explicit IAM grants.
      </Tab>

      <Tab title="Internal API">
        The runner receives an API identity scoped to approved hosts and
        operations. Credentials remain in your secret manager.
      </Tab>
    </Tabs>

    Read and write authority stay separate whenever the platform supports it.
  </Step>

  <Step title="3. Prepare your runner">
    We create or update runner code in a repository your team controls. Its
    typical shape is:

    <Tree>
      <Tree.Folder name="polycore-runner" defaultOpen>
        <Tree.File name="polycore.json" />

        <Tree.Folder name="actions">
          <Tree.Folder name="billing">
            <Tree.Folder name="set-plan">
              <Tree.File name="action.ts" />
            </Tree.Folder>
          </Tree.Folder>
        </Tree.Folder>

        <Tree.Folder name="context">
          <Tree.File name="product.md" />
        </Tree.Folder>

        <Tree.File name="Dockerfile" />

        <Tree.File name="package.json" />
      </Tree.Folder>
    </Tree>

    Structural configuration and standing actions are reviewed as code. Deploy
    configuration supplies runtime identity and secret bindings.
  </Step>

  <Step title="4. Deploy the runner in your infrastructure">
    The runner is deployed near the systems it calls. It needs:

    * Outbound network access to the Polycore control plane.
    * Network access to the selected datastore or APIs.
    * Access to the specific secrets or workload identity it will use.
    * An enrollment identity provisioned for one Polycore project and
      environment.

    The runner opens the control-plane connection itself. No inbound route to
    the runner is required.
  </Step>

  <Step title="5. Connect the interfaces">
    We expose the same governed catalog through the interfaces in scope:

    * [Slack](/integrations/slack) for conversational requests and approval
      cards.
    * [MCP](/integrations/mcp) for coding agents and other MCP clients.
    * [Admin dashboards](/concepts/dashboards) for purpose-built human
      workflows.

    A capability is governed by the same access policy and recorded with the
    same audit behavior whichever interface calls it.
  </Step>

  <Step title="6. Validate and hand off">
    We test the production path together:

    1. A permitted read succeeds and returns a bounded result.
    2. A prohibited read or missing permission fails clearly.
    3. A write creates an approval request and does not execute early.
    4. Approval releases the exact pending invocation.
    5. Denial leaves the downstream system unchanged.
    6. The request, invocation, result, and decision appear in the audit trail.

    We then document ownership, deployment changes, secret rotation, and the
    process for adding future capabilities.
  </Step>
</Steps>

## What we need from your team

You do not need every answer before the first conversation. The following
details let us form a concrete design quickly:

<AccordionGroup>
  <Accordion title="Systems and network boundaries" icon="network">
    Which production system should be connected first? Where does it run? Which
    environment should the first runner serve? Can an outbound worker reach both
    the Polycore control plane and that system?
  </Accordion>

  <Accordion title="Identity and secrets" icon="key-round">
    Which cloud identity, database role, or API credential model is available?
    Which secret manager or workload identity mechanism should the runner use?
  </Accordion>

  <Accordion title="First read and write" icon="list-checks">
    Name one real read and one governed change. Include the expected input,
    output, limits, and who should be able to request or approve them.
  </Accordion>

  <Accordion title="Review and deployment" icon="git-pull-request-arrow">
    Which repository should hold the runner? Who reviews changes? Which CI or
    infrastructure workflow deploys long-running workers in your environment?
  </Accordion>
</AccordionGroup>

## How the integration grows

After the first path is stable, expansion is incremental:

<Columns cols={3}>
  <Card title="Add data sources" icon="database" href="/integrations/overview">
    Connect another datastore or API with its own least-privilege identity.
  </Card>

  <Card title="Add actions" icon="braces" href="/authoring/actions">
    Review and deploy another typed operation from the same runner repository.
  </Card>

  <Card title="Add interfaces" icon="panels-top-left" href="/concepts/dashboards">
    Reuse the governed catalog in more agent and human workflows.
  </Card>
</Columns>

<Check>
  Ready to discuss a first workflow? [Request early
  access](https://www.polycore.ai/early-access) and tell us which system you
  want to connect.
</Check>