Data-flow diagram

Use the controls to enlarge the diagram. Pan horizontally and vertically when zoomed.

Flow semantics

Arrows represent logical movement or derivation of business information, not unrestricted direct database access. A transition is implemented as a policy-controlled data request, a trusted transaction, an object-storage operation, a scheduled job, or a verified provider callback. Each persistent transition retains enough attribution to associate the result with the authenticated actor or trusted workload, tenant context, business object, source event, and processing time.

Data lifecycle

Stage	Processing and control	Persistent output
Lead intake	Format and required-field checks, tenant-scoped duplicate detection, and relationship validation	Customer, lead, vehicle, and source evidence
Workflow	Authorised task creation and tenant/hierarchy checks	Task state and append-oriented operational history
Quote generation	Controlled premium calculation and document generation	Quote records and generated documents
Document handling	Authenticated upload, file validation, purpose-specific storage, and metadata association	Stored object plus integrity and ownership metadata
Policy verification	Required-document, policy-state, actor, tenant, and accounting checks	Verified policy state and versioned audit evidence
Finance processing	Authorised matching, settlement, allocation, and aggregation	Reconciliation, receipt, earning, adjustment, and audit records

Record relationships and integrity

Relationship	Cardinality and ownership	Integrity treatment
Customer to contact and address evidence	One customer supports multiple contact or address observations; one current value is designated for operational use	Tenant ownership, normalized identifiers, and duplicate checks prevent unrelated records from being silently merged
Customer to vehicle	A customer supports multiple vehicles and a vehicle participates in multiple task or policy lifecycles	Stable relationship records preserve historical task and policy associations when current ownership data changes
Lead to task	An admitted lead produces or reuses an authorised workflow task according to duplicate and lifecycle rules	Creation and reuse decisions retain source, actor, tenant, and deduplication evidence
Task to activity	A task has an ordered history of state changes, notes, calls, communications, and assignments	Append-oriented events preserve prior state and attribution instead of overwriting the operational history
Task to quote	A task supports multiple quote attempts and generated artefacts	Each quote is a point-in-time calculation with product, vehicle, premium, and generation provenance
Policy to documents	A policy links to purpose-specific evidence objects and their ownership metadata	Verification checks required evidence and prevents an unrelated or stale object from satisfying the policy gate
Policy to finance evidence	A verified policy participates in statements, receipts, allocations, earnings, and adjustments	Financial values are versioned and reconciled; changes retain the prior evidence and adjustment reason

Data transformation controls

1. Admission: parse external input into typed fields; reject rows that fail required, format, or relationship rules before persistence.
2. Normalization: standardize dates, phone values, registration data, insurer/product classifications, and other comparison fields while preserving the submitted source value when audit or dispute handling requires it.
3. Deduplication: compare within the authorised tenant and workflow scope; distinguish exact identity matches from possible matches requiring operator review.
4. Derivation: calculate workflow status, premium components, policy state, ageing, and reporting metrics from controlled source fields; retain the effective calculation context.
5. Document processing: validate content type and purpose, extract or generate structured information, associate the object with its business record, and preserve provenance.
6. Financial reconciliation: match external statement evidence to verified policy records, record unmatched or conflicting rows as exceptions, and post versioned adjustments rather than silently replacing settled evidence.

Security transitions

1. Imported files are validated before accepted rows are submitted.
2. Browser requests carry the authenticated session and tenant context; backend controls are authoritative.
3. Uploads use purpose-specific storage with ownership and integrity metadata.
4. Historical policy and finance evidence is appended or versioned rather than silently rewritten.
5. Sensitive reporting and finance actions use authorised server-side operations instead of unrestricted direct table access.

Data classifications

Data class	Examples	Destination
Identity and contact data	Name, phone, address, email, relationship owner	Managed operational database
Vehicle and policy data	Registration, insurer, premium, coverage dates	Managed operational and policy records
KYC and policy evidence	Identity documents, vehicle evidence, policy documents	Managed object storage plus ownership metadata
Workflow evidence	Transitions, notes, dispositions, calls, messages, verification events	Activity and audit records
Finance evidence	Commission versions, statements, matches, receipts, allocations	Protected finance records
Observability	Errors, traces, and configured diagnostic events	Monitoring provider under configured controls

Evidence basis and limitations

The flow was derived from application behavior, internal business and engineering documentation, and a read-only backend inventory reviewed on 18 August 2026. It is a logical assurance view rather than a column-level data dictionary or packet capture. Detailed retention periods, every provider field, and contractual processor obligations are addressed in later checklist items.