> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Understanding revenue data quality > Why completeness, correctness, freshness, and business authority produce different kinds of trust. Revenue data quality is the fitness of a record for a particular business decision. A contact can be adequate for account research and unsuitable for routing. An opportunity can contain every required field yet still give a misleading forecast. The useful question is what the next process needs to know, and which evidence supports that knowledge. ## Completeness is a limited measure A nonempty owner field establishes that an owner is stored. It does not prove that the person owns the current territory. A close date can be correctly formatted while no longer reflecting the deal's plan. Completeness is still useful: a missing required field can block a process. But combining it with correctness, freshness, and authority into one score can conceal the reason a record is unsuitable. For example, a routing process may need a resolved company identity and a current territory rule. A forecasting process may need evidence that a stage change was accepted by the commercial owner. They have different critical fields even when they read the same CRM. ## Errors spread through dependent decisions A mistaken company match can supply the wrong employee count, change the qualification segment, and route the lead to the wrong team. Fixing the final owner without addressing the identity rule leaves the upstream cause active. This is why field quality is not purely a formatting problem. Normalization can remove inconsistent casing or URL shapes, but it cannot decide whether two organizations are the same business entity. ## Freshness follows the decision's timing A useful observation can become inadequate as circumstances change. A job title, account owner, or deal stage may need different freshness rules from a company domain. A recent retrieval does not necessarily mean recent evidence. The workflow needs to preserve what is known about observation time and which rule interprets it. A universal refresh interval is unlikely to represent every field's business consequences. ## Repair can require authority rather than more data A missing domain may be resolvable from supported sources. A disputed owner or commercial stage may require a policy decision. Adding more enrichment calls to the second problem does not grant the workflow authority to choose. In Deepline, a Play can implement a team-defined acceptance rule and produce explicit accepted, unresolved, or rejected outputs. It does not automatically know the ground truth or create a customer review process for every ambiguity. An unresolved result can therefore be the correct output. It preserves the boundary between evidence the workflow established and a decision it cannot justify. ## A trustworthy update needs an explainable chain Identity, observation, validation, authorized change, and destination state form separate links. Provenance records explain the observation. Governance explains authority. Execution evidence explains what the automation attempted. A successful run is helpful evidence for the last part, but cannot stand in for every earlier link. Quality measures should reflect the decision-critical fields and unresolved causes, not just how often automation completed. ## Apply this understanding * [Repair CRM data](https://deepline.com/docs/guides/crm-data-quality-automation.md). * [Validate incoming files](https://deepline.com/docs/guides/validate-incoming-csv-files.md). * [CRM provenance](https://deepline.com/docs/guides/data-provenance-in-crm.md). * [Field ownership](https://deepline.com/docs/guides/crm-data-governance.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.