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

# How your lifecycles connect

> Stage rails are not islands — how a connection between two of them is declared, what it does when something changes, and why the reverse question is always a proposal.

Pipeline affects onboarding load. Onboarding load affects the team you need. The team you need affects what you can spend. Beacon lets you state those relationships rather than leaving them to be re-derived in a meeting each quarter.

<Note>
  A designed model. Connections are declared; no surface serves them from your data yet.
</Note>

## A connection is a mapping, not a number

A connection says *this affects that*, and holds nothing else. No forecast, no cost, no capacity figure lives on one. Both ends keep their own values and their own owner, which is why declaring a connection can never change what either side reports.

## Five kinds

| Kind | Example |
| - | - |
| One rail feeds another's inputs | Qualified demand becomes pipeline |
| One rail consumes what another supplies | Onboarding consumes implementation capacity |
| A group is handed across | A cohort that closed together is picked up together |
| Parts roll into a whole | Regional targets roll into the company target |
| An economic tie | What a segment costs to serve against what it returns |

## When something changes

A change moves forward through the declared connections and stops. The pass is bounded — a single sweep, or a stated number of them — never an open-ended search that runs until it settles.

What it does not do matters more:

* It **never recalculates** a figure another part owns. It reads what that part published.
* Where two connected parts disagree, the difference is **raised**, not quietly reconciled into a number that agrees with itself.
* A connection crossing different levels of detail **says so**. Nothing is silently rolled up or broken down on the way through.

## The question in reverse

The useful version is usually backwards: *we want this outcome — what would each part have to supply?*

Beacon answers it, and the answer is a **proposal**. It is not stored, it is not a figure, and nothing downstream reads it. It states a requirement — the pipeline, the capacity, the spend that target implies — and stops. It is never a second forecast, and it never applies itself. See [Proposals, not actions](/proposals-not-actions).

There is a limit worth stating plainly: this is not a general solver. Beacon will answer a bounded question about declared connections. It does not optimise your whole business at once, and it will say so rather than returning a confident answer to a question it cannot actually settle.

## Related

<Columns cols={3}>
  <Card title="The whole journey, end to end" href="/lifecycles/the-whole-journey">
    The one path that is modelled in full.
  </Card>

  <Card title="The lifecycles you define" href="/lifecycles/defining-your-own">
    Building the rails these connect.
  </Card>

  <Card title="One forecast, not two" href="/one-forecast">
    Why a reverse answer is never a rival forecast.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.