as_of and computed_at.
The names, types and availability below are fixed. No read interface or MCP tool serves them yet — this page publishes the shape ahead of the doors.
Example payload
Attributes
Enumerated verdicts reach every door lowercase with underscores; the display labels are Invest, Maintain, Optimise and Deprioritise.
Availability
✓ available by default · ⊕ available after an opt-in that states who becomes able to see the value · — not available.
The events door is listed and not yet served. A value marked on it has a named event —
segment.segment_health_tier.changed, segment.segment_economic_verdict.changed — sent once per recalculation when the published value differs from the last one, carrying the new value, the previous value and both timestamps. Nothing sends an event today and there is nothing to subscribe to yet. as_of and computed_at have no event of their own; they travel inside every event. segment_total_arr is available on this door behind the opt-in, because an event carries what a figure needs alongside it the way a read-interface response does. A CRM property cannot, which is why the note below on your CRM records says the rendering there is still being worked out.
Every value on this object is operational. Nothing at segment grain sits above that ceiling.
pipeline_velocity is scored per segment here, and it takes an opt-in on every door. Beacon scores the health of a pipeline at the level of the group whose deals it holds, so the score you read on a segment is that segment’s own open pipeline against that segment’s own historical pace. The same measure for your pipeline as a whole is catalogued on the company and period object and is not yet served; the two are one figure at two levels, not two figures. The score carries no currency — it is a pace measure on a 0 to 100 scale — and the opt-in it takes does not follow from money. It follows from how sensitive the record behind the score is: a pipeline’s pace reveals the position of the business, and that puts every door behind a recorded choice. It is declared here ahead of the API, which carries it from its next version.
Where the choice is made for pipeline_velocity. This value is not open by default on any door. The choice happens when a reader grant that reaches it is issued or widened, when you subscribe to events, or when you turn the CRM property on. Whoever makes it is shown who becomes able to see the value, and their yes is recorded — holding a grant is no longer enough on its own.
segment_total_arr on your CRM records, and the part that is not yet settled. Writing this figure onto your CRM records is off by default; turning it on takes an opt-in that states who becomes able to see it. That is a rule about where the value may travel, not about who inside your company may look at it.
What accompanies it there is not settled. It is an aggregate, assembled from many accounts each converted where it was recorded, so it travels with your reporting currency and the kinds of anchor its parts were pinned under — and it carries no single anchor date and no single billing currency, because it does not have one. Through the read interface and through MCP all of that travels with the figure automatically, in the same response. A CRM property holds one value. The mark above says the door is open behind an opt-in; it does not say the rendering is finished. That is being worked out and will be stated here when it is.
Nothing on this object is reduced to a band on the way into your CRM. segment_health_score lands on a CRM record as a number, segment_health_tier as its label, and pipeline_velocity as a number. Two of them take an opt-in on those doors — segment_total_arr and pipeline_velocity — and none of the five is a modelled value, so none is banded for the reason a modelled value is. A value is banded on a door only where that door cannot carry what the value needs to be read alongside it.
segment_health_tier also appears on an account record, and it is misread there. On an account it is the tier of the segment that account belongs to — one value about the group, shown beside the account for context. It is not a tier for that account, and every account in the segment carries the same one whatever each of them is doing. To read one account, use that account’s own health score.
segment_total_arr is a money value. It is stated in your single reporting currency, and it inherits that currency rather than converting into it — the account revenue behind it was already converted where it was recorded. Every read of it through Beacon is recorded in the access log; once it is written into your CRM, that tool’s own permissions govern who reads it from then on and Beacon can no longer record who did. That is what the opt-in exists to state.
Enumerated values are lowercase with underscores — developing, at_risk, maintain — on every door. The display labels are Growing, Healthy, Developing, Declining, At Risk for the tier, and Invest, Maintain, Optimise, Deprioritise for the verdict.
Freshness
Every figure on this object moves for two different reasons, and they are easy to confuse. The segment’s business changes — revenue turns, retention firms or softens, a customer churns. Or the segment’s membership changes — an account crossing a boundary moves its revenue and its contribution with it, altering two segments at once without any customer doing anything differently. Where more than 5% of a segment’s accounts move within 30 days, that movement is raised for review rather than absorbed quietly.
An approved merge, split or rename re-cuts the whole set and re-runs every value on every affected segment.
Both timestamps travel with every value. Compare against
as_of rather than the time of the request, and read computed_at when you want to know how recently Beacon looked. How current a number is covers both.