> ## 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. # Segment object > The six values Beacon publishes on a segment, the two timestamps that travel with them, and which doors each one is available through. The segment object carries six values at one row per segment, and two timestamps that accompany every one of them on every door: `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. A segment is one of the commercial groups your accounts are divided into. Every account belongs to exactly one, so segments do not overlap, and your set holds between three and twelve of them. A group has to hold at least 10 active accounts, or at least 5% of your recurring revenue, to stand as a segment at all — below that it is merged into the nearest one. [Segment](/definitions/segment) covers how the grouping is formed; this page covers what is published about a segment once it exists. ## Example payload ```json theme={null} { "object": "segment", "id": "seg_1f0a6c34", "as_of": "2026-08-17T06:00:00Z", "computed_at": "2026-08-17T06:04:12Z", "segment_health_score": 71, "segment_health_tier": "developing", "segment_economic_verdict": "maintain", "segment_account_count": 148, "segment_total_arr": 4200000, "pipeline_velocity": 63 } ``` ## Attributes | Value | Type | Method | What it holds | | - | - | - | - | | `as_of` | Timestamp, UTC | System | The moment the value describes — a property of the data, not of Beacon's activity. For a value composed from several sources it is the oldest of them, unless the value names an anchor source and says so. Present on every response and every property. | | `computed_at` | Timestamp, UTC | System | When Beacon last worked the value out. Present on every response and every property. | | `segment_health_score` | Number, 0–100 | Measured | How the segment is doing as a commercial group, across six weighted dimensions. Higher is healthier. A confidence band travels with it, and widens as fewer of the six dimensions have a source behind them. [Definition](/definitions/segment-health-score) | | `segment_health_tier` | String, one of five tiers | Measured | Which band the health score falls in — `growing`, `healthy`, `developing`, `declining`, `at_risk`. Two of the five split on direction rather than level. [Definition](/definitions/segment-health-tier) | | `segment_economic_verdict` | String, one of four verdicts | Recorded | The standing decision about the segment — `invest`, `maintain`, `optimise`, `deprioritise` — taken quarterly. It is a decision people make and Beacon stores, not a figure Beacon works out, and the thresholds behind it come from your finance authority rather than from the segment model. [Definition](/definitions/segment-economic-verdict) | | `segment_account_count` | Integer | Measured | How many active accounts the segment holds. It is the denominator every other segment figure is read against — a health score of 78 across 900 accounts and one across 11 are not the same claim. [Definition](/definitions/segment-account-count) | | `segment_total_arr` | Number, reporting currency | Measured | The recurring revenue held by the segment: the recurring revenue of every account in it, added together. [Definition](/definitions/segment-total-arr) | | `pipeline_velocity` | Number, 0–100 | Measured | How healthily this segment's open pipeline is moving, against the pace typical for its own deals and stages. Higher is healthier. A score for the segment's pipeline as a whole, not for any one deal — the deal-level measure is `deal_velocity_percentile` on the deal object, which runs the opposite way. [Definition](/definitions/pipeline-velocity) | 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. | Value | Read interface | MCP tools | Events | CRM property | CRM name | Audience ceiling | | - | - | - | - | - | - | - | | `as_of` | ✓ | ✓ | in every event | ✓ | `beacon_as_of` | `operational` | | `computed_at` | ✓ | ✓ | in every event | ✓ | `beacon_computed_at` | `operational` | | `segment_health_score` | ✓ | ✓ | ✓ | ✓ | `beacon_segment_health_score` | `operational` | | `segment_health_tier` | ✓ | ✓ | ✓ | ✓ | `beacon_segment_health_tier` | `operational` | | `segment_economic_verdict` | ✓ | ✓ | ✓ | ✓ | `beacon_segment_economic_verdict` | `operational` | | `segment_account_count` | ✓ | ✓ | ✓ | ✓ | `beacon_segment_account_count` | `operational` | | `segment_total_arr` | ✓ | ✓ | ⊕ | ⊕ | `beacon_segment_total_arr` | `operational` | | `pipeline_velocity` | ⊕ | ⊕ | ⊕ | ⊕ | `beacon_pipeline_velocity` | `operational` | **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](/data-model/company-period) 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](/api-reference), 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](/definitions/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 | Value | Recomputed | | - | - | | `segment_health_score` · `segment_health_tier` | Once per segment per recalculation cycle — a daily consolidation. A movement of five points or more between cycles is treated as material. The tier moves only when the score crosses a band boundary | | `segment_economic_verdict` | Quarterly, when the decision is taken. It does not move between quarters | | `segment_account_count` · `segment_total_arr` | Each cycle, over the membership in force at that cycle | | `pipeline_velocity` | Each cycle, over the segment's open deals at that cycle. The pace it is scored against is refreshed quarterly and does not move between refreshes | 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](/how-current-a-number-is) covers both. ## Versioning The published object is versioned separately from Beacon's internal model. A value is never removed from a published version — it is deprecated, and the removal lands in the next version. A published name is permanent; a rename ships as a redirect. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.