> ## 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.

# Data integrity

> How Beacon scores the data behind one record — five weighted dimensions, the tiers, the completeness penalty, and the floor below which a record is treated as absent.

<Note>
  This page describes a designed model, not shipped behaviour. The dimensions, weights and thresholds below are fixed; the published names and door availability are being authored into the field catalogue and may change before these values are callable.
</Note>

## What it is

`dic_score` is a 0-100 measure of how sound the data behind one record is, where higher means sounder. It is produced for every account, deal and subscription Beacon holds, and it governs whether the figures built on that record are published, downgraded or withheld.

Alongside it Beacon produces `entity_confidence_score` — the same measure expressed for the record as a whole, and the value every other module reads — and `confidence_tier`, its band.

## How it is calculated

Measured. Five dimensions are scored and combined at fixed weights.

| Dimension                | Weight | What it reads                                                                                |
| ------------------------ | ------ | -------------------------------------------------------------------------------------------- |
| Field completeness       | 0.28   | How much of the required field set is populated, against the critical-field thresholds below |
| Field accuracy           | 0.25   | Whether values fall inside their expected type, range and format                             |
| Entity confidence        | 0.22   | How firmly the record resolves to one real company or deal                                   |
| Field reliability        | 0.15   | How stable a field is over time, capped at five updates in sixty days                        |
| Cross-system consistency | 0.10   | Whether the same fact agrees across the systems that hold it                                 |

One rule overrides the weighted total: where field completeness falls below 80%, the composite is multiplied by 0.80.

| Tier   | Range    |
| ------ | -------- |
| High   | 80-100   |
| Medium | 60-79    |
| Low    | Below 60 |

**Below 80**, figures depending on the record are downgraded and flagged. **Below 60**, the record is treated as data-absent: no score is published for it, nothing is estimated in its place, and the floor cannot be overridden.

Critical fields carry their own completeness thresholds. Subscription end date, deal stage and product identifier must be 100%. Renewal date and contract end date must reach 95%. Contract value and usage feature identifier, 90%. Next step, expected close date and ticket account, 85%.

## Where it comes from

| Source         | What it supplies                                                                     |
| -------------- | ------------------------------------------------------------------------------------ |
| Billing        | Required. Contract, subscription and revenue fields, and the reconciliation baseline |
| CRM            | Required. Deal, account and activity fields                                          |
| Product usage  | Usage-integrity scoring, where connected                                             |
| Finance or ERP | The revenue reconciliation Beacon checks the CRM against                             |

Scoring across billing and CRM is never suspended — it is the measure everything else depends on. Where usage or finance is absent, the dimensions reading them are reported as unavailable rather than estimated.

Beacon also reconciles recurring revenue across your CRM, your billing system and its own model. A 3% company-level gap raises an alert. A 5% gap on one account makes billing the answer. Above 15% at company level, revenue forecasting pauses until it is resolved.

## How fresh it is

Recalculated on each cycle, and on a schema change at source. A breaking change in a connected system is classified and surfaced within twenty-four hours.

Every response carries two timestamps. **`as_of` is the moment the value describes. `computed_at` is when Beacon last worked it out.**

## Currency and rounding

Neither applies to the score. The reconciliation figures behind cross-system consistency are money values, stated in your single reporting currency.

## What changes it

A field being populated or emptied at source. A value moving outside its expected range. A record resolving — or ceasing to resolve — to one company. A field changing more than five times in sixty days, which lowers its reliability rather than raising it. A schema change in a connected system. A widening gap between what your CRM and your billing system say about the same revenue.

## What it is not

* **Not a measure of whether a figure is right.** It measures whether the data behind it is present, current, consistent and reconciled. A complete record can still describe a business decision that turned out badly.
* **Not a data-quality report for your team.** Beacon publishes it to govern its own behaviour. What it surfaces is fixed in your systems, not in Beacon.
* **Not [forecast confidence](/forecast-confidence).** That measures a forecast period and is reasoned; this measures one record and is calculated.
* **Not something you can set.** No configuration raises it and no plan changes a floor.
