Source identity is part of the claim
A source may describe a company, a subsidiary, a headquarters, or a person with a similar name. Even a precise number is weak evidence if the record identity is unresolved. For example, one source reports 120 employees and another 900. The conflict could reflect different observation dates or organizational boundaries, rather than one source being wrong. Retaining only the latest number makes that question impossible to investigate.Time has several meanings
The time a source observed a fact, the time a workflow retrieved it, and the time the CRM accepted it are different. Fetching an old observation today does not make the underlying fact fresh. A provenance record can preserve those distinctions when the source exposes and the workflow retains them. Missing observation time should remain unknown. It should not silently become the request timestamp. This matters for policy: a company domain may be stable enough for one task, while a person’s employment needs more recent evidence for another. There is no universal freshness interval that makes every field reliable.Validation and transformation also affect meaning
Normalization can turn a URL into a domain or map a source value into a CRM property. Those transformations need to preserve the relationship between the original evidence and the accepted value. A validation flag also needs its rule. An email accepted by a Play’s configured gate is not the same as proof of ownership, current employment, or delivery. The workflow version helps identify which acceptance logic was applied.Runtime evidence and business provenance overlap only partly
Deepline records run and tool evidence under their retention and result contracts. That can explain which action ran and what retained response it produced. It does not automatically create a complete field-level lineage record in your CRM. The authored workflow decides what evidence to persist with an accepted field. Its record might connect the destination ID, old and proposed values, source, observation time, validation outcome, and run identity. Where a source omits a fact, the record should reflect that limit. Observability helps diagnose the execution. Provenance helps judge the business value it produced.More history is useful only if it preserves uncertainty
A conflict can remain two observations until a precedence rule justifies one accepted value. Automatically replacing the older CRM value can conceal both the conflict and the reason for the replacement. Evidence also has a lifetime. Retained run data is not an indefinite archive, and provider contracts can constrain the team’s storage policy. Durable customer records should retain the evidence the process actually needs rather than assume every historical response will always be retrievable.Apply this understanding
- CRM repair guide.
- Query Database: store and query permitted customer working data.
- Run logs and events: execution evidence and retention limits.
- Field ownership: who may promote evidence into an operating fact.