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

# Core concepts

> Understand LaneSync's five-stage pipeline, three-layer enforcement, and how sdlc.yaml drives every gate.

LaneSync turns your GitHub workflow into a **provable release pipeline**. These concepts apply whether you use the hosted SaaS or a self-hosted deployment.

## The release pipeline

Every milestone moves sequentially through six stages. The backend state machine computes the current stage from **live GitHub data** — issues, PRs, workflow runs, evidence, and deployments.

```mermaid theme={null}
flowchart LR
  planning[PLANNING]
  development[DEVELOPMENT]
  testing[TESTING]
  evidencing[EVIDENCING]
  deployment[DEPLOYMENT]
  deployed[DEPLOYED]

  planning --> development
  development --> testing
  testing --> evidencing
  evidencing --> deployment
  deployment --> deployed
```

<Note>
  Stages **cannot be skipped**. Deploy readiness is only computed when all prior gates pass.
</Note>

<Snippet file="snippets/stage-table.mdx" />

See [Release pipeline](/concepts/release-pipeline) for entry and exit conditions per stage.

## Three-layer enforcement

LaneSync does not rely on policy documents alone. Enforcement happens at three layers:

```mermaid theme={null}
flowchart TB
  subgraph github [Layer 1 — GitHub]
    rulesets[Rulesets]
    requiredChecks[Required status checks]
  end

  subgraph backend [Layer 2 — LaneSync backend]
    stateMachine[State machine]
    deployGate[Deploy gate API]
  end

  subgraph ci [Layer 3 — CI]
    enforceAction["SDLC Enforce action"]
  end

  rulesets --> stateMachine
  stateMachine --> deployGate
  enforceAction --> requiredChecks
```

| Layer                     | Role                                                                                             |
| ------------------------- | ------------------------------------------------------------------------------------------------ |
| **GitHub Rulesets**       | Block merges without approvals and required checks; prevent force-push on `main` and `release/*` |
| **Backend state machine** | Compute stage from GitHub events; expose deploy readiness only when gates pass                   |
| **CI Action**             | Post `SDLC Enforce` status check; reject PRs that violate SDLC rules                             |

## Configuration: one file per repo

Each repository owns its SDLC policy in **`sdlc.yaml`** at the repo root. LaneSync reads this file **live from GitHub** on stage-detail requests (60-second cache). The database `required_checks` column is a cache that may lag until a push webhook fires.

<Warning>
  Never hardcode check names in application code. Check names in `required_checks` must match your GitHub Actions job names exactly — and they must come from `sdlc.yaml`.
</Warning>

<Snippet file="snippets/sdlc-yaml-example.mdx" />

## Data flow

```mermaid theme={null}
sequenceDiagram
  participant Dev as Developer
  participant GH as GitHub
  participant LS as LaneSync
  participant CI as GitHub Actions

  Dev->>GH: Push sdlc.yaml / merge PR
  GH->>LS: Webhook event
  LS->>GH: Fetch live sdlc.yaml
  LS->>LS: Update rulesets and re-sync milestones
  CI->>LS: POST /api/evidence/upload
  LS->>LS: Parse reports and update stage
  Dev->>LS: View dashboard at lanesync.dev
```

## Multi-tenant isolation

Each GitHub organization is a **tenant**. PostgreSQL row-level security (RLS) ensures data isolation. Users sign in with GitHub OAuth and pick a workspace when they belong to multiple orgs.

## Where to go next

<CardGroup cols={3}>
  <Card title="Release pipeline" icon="route" href="/concepts/release-pipeline">
    Gate conditions for every stage.
  </Card>

  <Card title="Enforcement" icon="shield" href="/concepts/enforcement">
    Rulesets, state machine, and CI action.
  </Card>

  <Card title="sdlc.yaml" icon="file-code" href="/concepts/sdlc-yaml">
    How config propagates through the system.
  </Card>
</CardGroup>