Data model

Beacon publishes one object per grain. Every value on an object carries a name, a type, a method, an audience ceiling, and an availability mark for each door it can travel through.

​

Objects

An object can hold a value that is written into it but not yet available on any door — the account object holds seventeen and makes sixteen available; the deal object holds eight and makes seven available; the chart-of-accounts object holds seventeen and makes fifteen available, holding back two that are internal to how Beacon splits and traces a category. The company-and-period and ledger-entry objects make everything they hold available, so their two counts are the same number. The count above is the available one. Each object page states both. The last two objects are the accounting pair, and they are read together. A cost figure is a sum of ledger entries, grouped by the category they posted to and the month they posted in. Neither object means much on its own; the chart of accounts is where you say what a category is, and the ledger entries are what lands in it. One thing is true of the accounting pair and not of the objects above them. Both are closed on the CRM door outright rather than behind an opt-in: neither a chart-of-accounts category nor a ledger entry is a fact about a customer, so there is no record to write it onto. And one naming point worth knowing before you read the two pages. The chart-of-accounts object is chart_of_accounts_category and not account_category, because account on this interface already means a customer account. The collections are GET /chart-of-accounts and GET /ledger-entries. One thing the table deliberately does not list: the lifecycle. Beacon also stores the journey these objects move along — one record per lifecycle today, with the stages, movement history and signal attachments settled in design but not yet running. No lifecycle object is published on any door, which is why it has no row above; how that data is stored, and exactly which parts exist today, is on the Lifecycle object page.

​

Doors

A value reaches you through up to four doors. Three carry values today. No value is published on the events door yet. The list of events is fixed — each object page marks which of its values has one — but nothing sends an event today and there is nothing to subscribe to yet. An event, when it arrives, is named for the object and the value that changed, carries the new value and the previous one with the same two timestamps every door carries, and is sent once per recalculation rather than continuously. A value whose only change is the passage of time — a count of days, a most-recent date — has no event of its own; the change it counts from does.

​

Naming

The beacon_ prefix marks a value written into a tool Beacon does not own. Inside Beacon’s own model the name is bare. One value carries both spellings, applied by the door and never stored twice.

​

Method

Three words describe how a value is produced. Each one says which part of Beacon produced the value — not how complicated the value is, and not whether you could arrive at it by hand.

• Measured — produced by Beacon’s calculation layer. The arithmetic is fixed and written down, and the same inputs always return the same value. Most published values are measured, including several composed from many inputs and scored against benchmarks that move as your history builds.
• Modelled — produced by one of the small, fixed set of parts of Beacon that reason rather than calculate. That set is named and closed: a value is modelled if and only if one of them produced it. A modelled value travels with the version of the model that produced it.
• Recorded — a decision made by people and stored. Beacon holds it and publishes it; it does not work it out.

Measured does not mean reproducible by hand. A value can be measured, fixed in its arithmetic, and still impossible for you to re-derive — because it runs against norms refreshed from your own history, or over a window that has not finished happening. Where that is true, the value’s own definition article says so. Reproducibility is a separate question from method, and Beacon answers the two separately rather than letting one word carry both. On the read interface and through MCP, every value is published as it stands, with both timestamps beside it. A value is reduced to a band only on a door that cannot carry what the value needs to be read alongside it — a model version. That is a property of the door rather than of the method: a modelled score with nothing to carry lands as a number. A money figure needs its currency envelope alongside it, and where a door cannot yet render that in full — a CRM property holds one value — the object page says what is still being worked out rather than implying it is settled.

​

Availability

On the account and deal objects, every value takes an opt-in on every door. Those two objects hold facts about your customers and about the deals you are doing with them, so nothing on them is open by default: the choice is made when a grant is issued or widened, when you subscribe to events, or when you turn a CRM property on, and it is recorded either way. On the other objects, financial values are available by default on the read interface and MCP tools under a reader grant, and off by default on the CRM door and the events door. A property written into your CRM leaves Beacon’s access log: the tool’s own permissions govern who reads it from that point, and Beacon can no longer record who read it. An event is the same case — it is delivered to a destination you name, and Beacon records the delivery but not who reads it there — so the opt-in is taken once, when the subscription is set up.

​

Audience ceiling

Every value carries one of three ceilings — operational, leadership-only, board-grade. Above operational the CRM door is off by default and switching it on requires the opt-in above. On the read interface, MCP tools and the events door the ceiling governs which grant may cover the value, not the door itself. The ceiling is not a block.

​

Constraints

• as_of accompanies every value on every door.
• Raw user-event data never leaves Beacon on any door. Usage is published at account grain only, as usage_pattern, active_users and last_active_date.
• A published name is permanent. A rename ships as a redirect, and a value is deprecated in the next version rather than removed from a published one.

​

Related