Skip to main content
Each rule below states what Beacon does, the mechanism that enforces it, and how to verify it. Where a limit is a policy choice rather than a structural one, it says so.

Reads are read-only on systems of record

Beacon reads billing, ledger and bank. It never writes to them. Mechanism: read scopes only on those connectors. Verify: inspect the granted scopes in the source tool. Beacon may write in two places, both opt-in: a namespaced set of fields on your own CRM records, and actions a person approved individually. Today it writes nothing back to your CRM. It does not move money, issue invoices, alter workflows, or delete records.

Beacon never holds a credential

Authentication happens in the source tool’s own login screen. Beacon does not request, store, or complete a login on your behalf — not at setup, not later, not for support. Mechanism: OAuth or equivalent, initiated by you in the source tool. Verify: revoke Beacon in Stripe, Salesforce or Xero; access ends at the source immediately, without notifying Beacon.

Beacon never grants itself access

Roles and access are set by your administrators in your own permission screens. Beacon can recommend a configuration and guide you through it; it cannot apply one. Mechanism: no write path to permission state. Agent access requests go to a human queue. A request exceeding the ceiling any agent may hold is declined automatically and logged, without reaching that queue. Verify: the access log lists every request and its disposition.

Figures are never computed on request

When anything reads a figure — a person, a spreadsheet, an AI assistant, another vendor’s software — Beacon serves the value it already computed on schedule. It does not calculate a new one to satisfy the request. Mechanism: retrieval reads stored values; there is no compute path at read time. Verify: the same question returns the same value to every reader at every hour. A figure in a board pack and the same figure in a sales tool come from one calculation. This holds for currency as well. An amount is converted when the figure is stored, not when it is read, and both amounts are kept. Where a screen offers a view in a currency you do not report in, it converts at the same fixed rate the figure itself carries — never at today’s rate, which would move the number between two readings with nothing underneath it having changed.

Every figure carries its context

No value is served bare, in the product, in a report, or over any connection. This matters most when the reader is a machine: a bare number handed to an AI assistant is used with full confidence and no context.

Unavailable figures are named, not estimated

There is no empty cell, no zero standing in for a missing value, and no plausible estimate.

A missing source degrades in a declared way

Billing is the only required source. Without it Beacon produces no figure at all — not a reduced one, not a provisional one. Every other source behaves differently. When one stops answering, the module does not switch off. It keeps publishing what it can still compute, stops publishing what it cannot, and which is which is declared in advance rather than worked out at the time. A figure published on a reduced basis is labelled, and the label travels with the value rather than sitting on the page. A figure with no basis left is withheld and named — never smoothed, never carried forward from last period. Mechanism: each module declares, source by source, what stays available and what becomes unavailable without it. Verify: disconnect one optional source. The figures depending on it change together and say so; nothing else moves. When a source is missing sets this out in full.

Outside readers read a separate copy

Beacon distinguishes three reader classes. The difference is not a filter applied per request — each class reads from its own separately built copy of the data. Mechanism: restricted information is absent from the copy an external reader reads, so there is no per-request rule to misconfigure and no request that can be crafted around one.

Grants are written in plain language and revoke immediately

Anything reading Beacon from outside — a spreadsheet, a warehouse, an AI assistant, a partner’s software — connects through a reader grant stating what it is, which families of information it may read, which accounts, sealed or live figures, a staleness limit, the destination, and an expiry. Mechanism: every read is logged, including reads of financial figures, whether or not that field was individually enabled. Revoking a grant fails the next request, with no propagation delay and nothing cached on the far side that Beacon still treats as valid.

Financial figures and person-level data have their own handling

Financial figures. The grant sets how sensitive a reader may go, stated in plain words on the form itself. The two paths differ: financial figures are available to systems you connect directly, and off by default for writing into your CRM. A value written onto a CRM record is visible to everyone with a seat in that tool, and Beacon can neither re-scope it afterwards nor record who read it. You can enable it; the prompt states this before you do. Product usage. Usage arrives at the level of individual people and events. It leaves at the level of the account, as three figures: direction of usage, count of active people, and last active date. Individual event data never leaves Beacon, on any connection, to any reader. This is structural, not a default.

CRM fields are additive and removable in one sweep

Beacon’s writing to your CRM is limited to a small set of its own fields — segment, lifecycle position, health. Today it writes none of them: the Connections page reads Writes nothing back yet on your CRM. Each is prefixed, carries its last-updated time, and links to its definition.
  1. Additive only. Beacon never edits or removes a field your team created.
  2. Approved as a set. You review the whole list at setup rather than approving writes individually.
  3. Removable in one sweep. Every field shares a prefix, so removing Beacon from a tool means deleting one namespace.
Modelled figures write as bands, not decimals. A judgement such as customer fit lands as high, medium or low. A CRM field strips the definition, confidence, version and freshness that make a modelled value safe to read, and a bare score reads as a measurement. Figures Beacon calculates outright — health, churn risk, expansion readiness — write as numbers, because they are reproducible from your data.

Two refusals

Beacon will not score a company it has never seen. With no history in your systems there is nothing to calculate from. Instead it exports the model — dimensions, weights, thresholds, which segments fall above the line — as a portable, versioned object your own tools can apply to their own data. There is no open query interface. Beacon serves a defined, published set of retrievals. A query language would let a caller assemble a total Beacon never calculated, arriving with no definition, source or version attached. The published set grows by versioned, documented additions.

Where Beacon stops

  • No money movement, invoice issuance, or changes in billing or accounting systems.
  • No permission changes, in Beacon or anywhere else.
  • No action without approval. Recommendations wait for a person.
  • Above roughly $100M in recurring revenue, the standard setup is the wrong shape; Beacon runs on your warehouse instead. This is stated during evaluation, not after signature.