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

# Integration onboarding

> Sequenced onboarding for a partner team evaluating Path as a strategy intelligence layer on top of a modular rail.

This page is for the technical team on the other side of a
partnership conversation. The goal is to let a PM or DeFi lead
navigate from "what is Path" to "how would Path slot into our
existing rail" in a single read.

## At a glance

<CardGroup cols={2}>
  <Card title="What Path is" icon="brain">
    A prediction engine plus an embeddable surface. Signal Mesh
    combines on-chain protocol health, prediction-market data, and
    macro signals and emits confidence-scored, multi-horizon
    predictions per pool.
  </Card>

  <Card title="Where Path slots in" icon="puzzle-piece">
    Modular rail layers as a strategy-manager component. Path runs
    the allocation strategy; the rail handles custody, execution,
    NAV reporting, KYC, and distribution.
  </Card>

  <Card title="How partners consume Path" icon="code">
    Two surfaces: a private institutional access channel for
    headless integration, or a drop-in widget that embeds the
    prediction and allocation surface inside an existing earn
    product.
  </Card>
</CardGroup>

## Step-by-step evaluation path

<Steps>
  <Step title="Read the engine">
    Start with [Signal Mesh](/core-concepts/signal-mesh) for the
    signal inputs, capability surface, and confidence calibration.
    The answer to "what happens to APY if I deposit at size" lives at
    [Liquidity impact](/core-concepts/liquidity-impact).
  </Step>

  <Step title="Read the partner-access shape">
    [Partner access](/integrations/partner-access) describes the
    integration patterns (strategy intelligence feed, embedded
    widget, custodian integration, DON-signed signals) and the
    deployment options.
  </Step>

  <Step title="Read the trust posture">
    [Trust and compliance](/compliance) covers address screening,
    smart-contract risk scoring, pre-allocation gating, and
    post-trade monitoring.
  </Step>

  <Step title="Ask the question we have not answered here">
    The fastest channel for an integration deep-dive is direct
    contact at
    [path@pathprotocol.finance](mailto:path@pathprotocol.finance).
    We can schedule a call covering the specific bits this page
    does not.
  </Step>
</Steps>

## Strategy-manager framing

Path's wedge into a modular rail is the **strategy-manager slot**,
not a yield-source slot.

<AccordionGroup>
  <Accordion title="What Path contributes">
    A signal-driven allocation policy: which yield sources to
    weight, when to rebalance, with what conviction. Every
    recommendation carries a calibrated confidence score and
    per-signal attribution.
  </Accordion>

  <Accordion title="What the rail contributes">
    Custody, on-chain execution, NAV computation, KYC and
    jurisdictional wrapping, distribution to end-clients. Path does
    not aspire to replicate this layer; it is a strict separation
    of concerns and it is what makes the strategy-manager pattern
    work.
  </Accordion>

  <Accordion title="Why this works">
    The pattern matches the curator-strategy-manager shape that has
    driven institutional curator growth on-chain. The rail focuses
    on what it is good at (security, custody, regulatory wrapping);
    the strategy provider focuses on intelligence and allocation.
  </Accordion>
</AccordionGroup>

## Concrete integration questions

<AccordionGroup>
  <Accordion title="Where do allocation decisions originate?">
    Today, Path publishes signal and the user decides. Later
    capabilities include Path crafting the rebalance transaction
    for an authorised signer to submit, and ultimately a policy
    engine signing against a user-defined risk profile within
    partner-set guardrails. The surface a given integration sits
    in is a contract decision per partner.
  </Accordion>

  <Accordion title="Can we drive allocation from a programmatic feed instead of from your UI?">
    Yes. Partner access exposes the prediction stream, the
    liquidity-impact context, the historical accuracy registry,
    and the rebalance-cost estimator. Endpoint detail, schema,
    and access tokens are handled inside the partnership
    conversation.
  </Accordion>

  <Accordion title="Can we embed your UI instead of building our own?">
    Yes. The widget reads the connected wallet, renders the
    allocation breakdown, the recommended rebalance with
    confidence and break-even, and the liquidity-impact context.
    The widget is design-system aware: pass colour tokens,
    typography tokens, and a layout container, and the widget
    styles itself to match.
  </Accordion>

  <Accordion title="Do you support on-chain verifiable signal output?">
    Yes. Path's prediction stream runs through a Chainlink
    Runtime Environment workflow that signs the prediction tuple
    on-chain. Any vault contract on any supported chain can read
    the signed signal with cryptographic guarantees. This
    converts off-chain compute trust into on-chain verifiability
    without requiring Path to operate its own validator set.
  </Accordion>

  <Accordion title="What happens to predicted APY if I deposit at size?">
    The liquidity-impact context block on every prediction
    answers this directly. For a hypothetical deposit, Path
    computes pool-share representation, post-deposit APY via the
    protocol's actual rate mechanism (utilisation curve for
    lending, swap-fee math for AMM-style yield, governance-set
    rate for stability rails), expected slippage band where
    applicable, and a break-even horizon combining direction
    confidence, post-deposit APY, and gas cost. See
    [Liquidity impact](/core-concepts/liquidity-impact) for the
    full surface.
  </Accordion>

  <Accordion title="What is your risk model?">
    Address screening runs against Chainalysis at both pool side
    (treasury, oracle, governance multisig, audit-history
    contributors) and allocator side (the wallet about to receive
    the recommendation). Smart-contract risk scoring runs through
    GoPlus. Both feed a pre-allocation gate, and post-trade
    monitoring re-checks both layers on a continuous cadence.
    See [Trust and compliance](/compliance) for the full surface.
  </Accordion>

  <Accordion title="What is the regulatory shape?">
    Today's surface is read-only information: no custody, no
    managed-product framing. Any capability that involves Path
    crafting or signing transactions introduces a regulatory
    dependency we structure against per-partner, because the
    licensing obligation depends on the embedding partner's
    jurisdiction. We engage the regulatory framework inside each
    integration conversation, not by committing to one global
    structure.
  </Accordion>

  <Accordion title="How do you handle calibration drift?">
    A live calibration verifier monitors drift between the
    confidence score and observed forward outcomes. Drift past
    the configured tolerance pages the on-call and auto-files a
    ticket. Calibration is the class of silent bug a model
    pipeline is most exposed to, and the verifier keeps that
    loop closed.
  </Accordion>
</AccordionGroup>

## Live surfaces for hands-on review

<CardGroup cols={2}>
  <Card title="Web app" icon="window" href="https://app.pathprotocol.finance">
    The live read-only surface where allocators consume Path's
    predictions and liquidity-impact context. A PM evaluating the
    product surface should connect a wallet and walk through the
    opportunity page and a per-pool detail panel.
  </Card>

  <Card title="Website" icon="globe" href="https://www.pathprotocol.finance">
    Product positioning and use-cases.
  </Card>

  <Card title="Partner access" icon="key" href="/integrations/partner-access">
    Integration patterns, deployment options, and the partnership
    contact channel.
  </Card>

  <Card title="This documentation" icon="book" href="https://docs.pathprotocol.finance">
    The doc surface a PM should read end-to-end before the first
    call.
  </Card>
</CardGroup>