A designed model. Connections are declared; no surface serves them from your data yet.
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
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. 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
The whole journey, end to end
The one path that is modelled in full.
The lifecycles you define
Building the rails these connect.
One forecast, not two
Why a reverse answer is never a rival forecast.