Skip to main content
Most of what a system like this can do is interesting. What it cannot do is what makes it safe to connect. Every limit on this page is built into how Beacon works, not written into a policy that someone has to remember. Where a boundary is a choice rather than a technical impossibility, we say so.

Read-only where it counts

Beacon reads your billing system, your ledger and your bank. It never writes to any of them. That is a deliberate stance, not a gap in the integration. These are systems of record. A tool that can read your revenue and also change it is a tool your auditor has to think about; a tool that can only read it is not. Beacon writes in exactly two places, both of which you switch on:
  • Fields it owns, on your own records — a small set of named fields it adds to your CRM and keeps current. It never edits, overwrites or deletes a field your team created.
  • Actions a person approved — a task, a message, a flag. Each one proposed, each one held until a human says yes.
Nothing else. No workflows changed, no records deleted, no money moved.

Beacon never holds a password

Every connection is authenticated by you, inside the source tool’s own login screen. Beacon does not ask for credentials, does not store them, and does not complete a login on your behalf — not during setup, not later, not for support. The practical consequence is the one your security team cares about: the off switch is in your tool, not ours. Revoke Beacon’s access in Stripe, in Salesforce, in Xero, and it is gone at the source, immediately, whether or not anyone tells us.

Beacon never grants itself access

Who can see what is set in your own permission screens, by your own administrators. Beacon can show you what it would recommend and walk you through it. It cannot make the change. The same rule binds the agents that come with Beacon. They can ask for something they don’t have; a person approves or declines it. A request that exceeds what any agent is ever allowed to do is declined automatically and logged — it never reaches a human queue to be waved through on a busy afternoon.

Numbers are never computed on request

This is the least obvious boundary and the most important one. When something reads a figure out of Beacon — a person, a spreadsheet, an AI assistant, another vendor’s software — Beacon serves the number it already worked out, on a schedule, from your data. It does not calculate something new to satisfy the question being asked. So the same question returns the same answer to every reader, at every hour, no matter which way it was asked. Ask twice, get the same answer twice. A figure in a board pack and the same figure inside a sales tool came from one calculation, not two that happen to agree today.

Every figure arrives with its receipts

A number on its own is a claim. Beacon never serves one that way — in the product, in a report, or over any connection to another system, each value travels with four things attached: This matters more, not less, when the reader is a machine. A bare number handed to an AI assistant will be used with total confidence and no context. A number that carries its own definition and its own staleness cannot be quietly misread.

When Beacon cannot answer, it says why

There is no empty cell, no zero standing in for a missing value, and no plausible estimate. A figure Beacon cannot stand behind comes back as a named refusal with the reason and what would fix it:
  • Not calculated yet — the figure exists but this period hasn’t been computed.
  • Source not connected — the system it depends on isn’t connected, and here is which one.
  • Outside what this reader may see — real, but beyond the access you granted.
  • Older than your freshness limit — available, but staler than the threshold you set.
  • Not in your data — the company or account isn’t one Beacon has ever seen.
A refusal you can act on is worth more than a number you’d have to double-check. It is also the only version a downstream system can handle correctly.

A missing source is named, never papered over

If a source is disconnected, unreachable, or has stopped sending data, the things that depend on it switch off and say which source is missing and what would come back. Beacon does not carry on with a narrower calculation and present it as the same number. Billing is the exception that proves the rule: without it, Beacon does not run at all rather than run on a fraction of the truth.

Outside readers see less, by construction

Beacon distinguishes three kinds of reader, and the difference is not a filter applied to each request. Each kind reads from its own separately built copy of the data. What an outside reader cannot see is absent from the copy they are reading, so there is no rule to misconfigure and no request that can be crafted to slip past one.

Grants, and turning them off

Anything that reads Beacon from outside — a spreadsheet, a warehouse, an AI assistant, a partner’s software — connects through a reader grant you write in plain language: what it is, what families of information it may read, which accounts, sealed figures or live ones, how stale is too stale, where the data is going, and until when. Two things follow from that. Every read is logged, including reads of financial figures, whether or not that specific field was individually switched on. And revocation is immediate — turn a grant off and the next request fails, with no propagation delay and nothing cached on the far side that Beacon still considers valid.

Money figures, and data about people

Two categories get their own handling. Financial figures. The grant is where you decide how sensitive a reader may go, and that limit is stated in plain words on the form itself, not buried in an advanced section. There is one deliberate asymmetry: financial figures are available to systems you connect directly, and off by default for writing into your CRM. Writing a value onto a CRM record makes it visible to everyone with a seat in that tool, and Beacon cannot re-scope it afterwards or record who read it. You can switch it on; the prompt tells you exactly that before you do. Product usage. Usage arrives in Beacon at the level of individual people and events. It leaves at the level of the account, as three figures: whether usage is rising, flat or declining; how many people are active; and when the account was last active. Individual event data never leaves Beacon, on any connection, to any reader. That is a hard limit, not a default you could change.

What Beacon adds to your CRM, and how to remove it

Beacon keeps a small set of its own fields current on your records — things like the segment an account belongs to, where it is in its lifecycle, and how healthy it looks. Each is prefixed so it is unmistakably Beacon’s, each carries the time it was last updated, and each links back to its definition. Three rules govern them:
  1. Additive only. Beacon’s fields sit alongside yours. It never edits or removes a field your team created.
  2. Approved once, as a set. You review the whole list at setup rather than approving writes one at a time.
  3. Removable in one sweep. Every field shares a prefix, so removing Beacon from a tool is deleting one namespace — not hunting through a schema for what it touched.
Modelled figures arrive as a band, not a number. A judgement like customer fit lands in your CRM as high, medium or low — never as a decimal. A CRM field strips away everything that makes a modelled value safe to read: no definition, no confidence, no version, no freshness. A rep seeing a bare score will reasonably treat it as a measurement. A band survives that trip honestly. The precise value stays where its full context travels with it. Figures Beacon calculates outright — health, churn risk, expansion readiness — do land as numbers. They are reproducible from your data by construction, so precision means something.

What Beacon refuses to do

Two refusals are worth stating plainly, because both are things a customer has asked for. Beacon will not score a company it has never seen. If a prospect has no history in your systems, Beacon has nothing to calculate from, and inventing a score would put an unsupported number into your outbound machine wearing Beacon’s name. What it will do instead is hand over the model — the dimensions, the weights, the thresholds, which segments end up above the line — as a portable, versioned object your own tools can apply to their own data. You get the judgement. The number stays honest. There is no open query interface. Beacon serves a defined, published set of retrievals. It does not accept free-form queries, because a query language would let a caller assemble a total Beacon never calculated, arriving with no definition, no source and no version attached — a figure with Beacon’s name on it that Beacon cannot defend. The published set grows by additions we version and document. It never becomes a query language.

Where Beacon stops

  • It does not move money, issue invoices, or change anything in your billing or accounting systems.
  • It does not change anyone’s permissions, in Beacon or anywhere else.
  • It does not act without approval. Recommendations wait for a person.
  • Above roughly $100M in recurring revenue, the standard setup is the wrong shape and Beacon runs on your warehouse instead. We say so during evaluation rather than after you have signed.
If a boundary here matters to your review and you want it demonstrated rather than described, ask — most of them can be shown in the product in a few minutes.