Part of this page describes design that is settled but not yet running. The last section says exactly which parts are stored today and which are in design — the distinction is stated here rather than left for you to discover.
One lifecycle, one record
Every lifecycle in your instance — a shipped template like Retention & Expansion, or one you define yourself — is one record. The record carries what kind of lifecycle it is, what it tracks (accounts, deals, requisitions, a funding round), which of your systems feed it, its bindings to forecasts, targets and cadences, and its state: Draft, Active, Degraded, Paused or Retired. A lifecycle that has not activated its sources does not silently pretend — its state says so. A program is a lifecycle composed of other lifecycles: the record lists its members, and the members keep their own records. Nothing is copied.Stages become records
In design: each stage of each lifecycle is stored as its own record — its position in the order, which part of the journey it belongs to (marketing, sales or customer, with finance and capacity running as bands underneath rather than as stages), what kind of connected data lights it, and whether you run that stage at all. Two facts sit on every stage record and they are decided by different parties: whether a stage is lit is decided by what sources you have connected — Beacon decides this and you cannot; whether a stage is relevant is your declaration that you run it — you decide this and Beacon cannot. The standard stages ship read-only — the surfaces you see render from these records, and nothing you configure can rename or reorder them. Stages of lifecycles you author are added through the builder, never drawn freehand.Exactly one system fills each stage
A design rule with one job: for every stage, exactly one system is responsible for saying who is in it. Where billing can see the fact — a first payment, a renewal, an expansion, a contraction, a churn — the answer comes from billing records, because an invoice is an observation and a CRM field is an assertion. Where only your CRM can see the fact — every stage before revenue exists — the answer comes from your CRM, through the mapping described below. No stage ever has two writers, so no stage can ever have two answers.Movement is history, not an overwrite
When something moves between stages, the movement is recorded as history — when it entered, when it left, in what order — rather than overwriting a single field. The current stage is simply the history row that has not closed. This is what stage-level reads like days in stage and the transition rates on the lifecycle surfaces are struck from, and it is why they can be traced back to real events rather than to a value someone typed. Deal-stage history is specified first; it records each stage transition of each deal as its own row.Your CRM’s ladder is mapped, never guessed
Your CRM has its own pipelines and stage names, and a company often runs several pipelines whose stage labels collide. Beacon stores your ladder as delivered — pipeline, stage, display order, which stages are terminal — and at setup you map it onto Beacon’s stage model once. The mapping is stored; nothing downstream pattern-matches stage names, and a stage id is never interpreted without the pipeline it belongs to.Signals attach to stages
In design: the signal dictionary — the catalogue of things Beacon watches, from an overdue invoice to a usage drop — binds to stage records. A binding says what a signal does at that stage: lights it, feeds its reads, or gates a transition. This is what makes “signal intelligence along the lifecycle” a stored fact you can inspect rather than a description.Scores that span the whole lifecycle
Some measures are deliberately not stage-bound. Deal probability is one: it collects evidence from across the journey, not from a single stage, and forcing it into one would misstate what it is. These lifecycle-spanning scores are stored on the record they describe — the account or the deal — and the question which stages contributed to this score is answered by walking from the score to its input signals to those signals’ stage bindings. It is derived, on purpose: storing a separate list of contributing stages would create a second answer that could drift from the first.What is stored today
No lifecycle object is published on any door or MCP tool yet, and nothing on this page is a payload shape you can call. When the lifecycle object publishes, it joins How the objects relate alongside the objects that already have pages.
Related
How the objects relate
The published objects and the links between them.
The lifecycles you define
Authoring a lifecycle, and the rules that keep it governed.
What changes when a stage changes
Transitions, durations and stall detection.