01
Boundary
Begin with the decision the insight should improve
A business-insight request should name the customer decision, such as reviewing territory coverage or identifying incomplete company records. It should not begin with collecting every profile or page available. DewEngine will not provide scraping, reverse-engineering, bypass, or anti-detection guidance. LinkedIn access remains decision-gated, so the architecture must accept customer-owned or otherwise authorized evidence and stay useful without a LinkedIn connector.
- Write one accountable business question per dataset
- Reject open-ended collection without a retention and deletion purpose
02
Observation model
Separate facts, labels, and inferences
A displayed company name or role is an observation at a point in time. A segment label, likely territory, or growth signal is a derived interpretation. Store these separately with source, timestamp, transformation version, and confidence where appropriate. This prevents an analyst's rule from becoming an attributed provider fact and allows recalculation or removal when the underlying evidence changes.
- Keep raw observation provenance beside every derived feature
- Never present an inference as a statement made by the person
03
Minimization
Collect the smallest dataset that answers the question
If territory analysis needs company location and customer ownership, personal biographies and message content do not belong in the pipeline. If duplicate review needs a source identifier and company domain, copying posts adds risk without value. Field-level purpose mapping reduces security exposure and makes privacy requests feasible. It also disciplines product teams to measure insight quality rather than raw record count.
- Remove fields that do not change the decision
- Set retention by observation class instead of one indefinite archive
04
CRM integration
Publish proposals, not silent truth replacements
Analytical output should arrive as a suggestion, score explanation, or review task. The CRM remains authoritative for account owner, customer stage, consent, and workflow. For example, a model might flag that two companies share a domain, but a person should decide whether they are duplicates, parent and subsidiary, or unrelated tenants. Preserve both the evidence and the resolution.
- Make derived updates reversible and attributable
- Do not let an insight bypass normal CRM authorization
05
Privacy and security
Design for access, correction, and deletion
Professional context can still be personal data or commercially sensitive. Tenant isolation, least-privilege workers, encrypted authorization, redacted logs, purpose-limited access, export, correction, retention expiry, and deletion belong in the first design. Support tools should diagnose a pipeline through identifiers and state without exposing copied messages or profile text. Model training or secondary enrichment needs a separate explicit decision.
- Audit who viewed or changed sensitive observations
- Keep personal content out of traces, analytics, and error messages
06
Go/no-go evidence
Make authorized access a prerequisite
Before any LinkedIn-backed insight ships, qualified counsel and provider or partner authorization must cover the exact product and jurisdiction. Engineering proof would include capability negotiation, field accuracy, partial results, throttling, revoked access, tenant isolation, retention, deletion, and a kill switch. If that gate fails, use first-party CRM records, licensed datasets, customer uploads, or other approved sources rather than attempting to evade the restriction.
- Document the lawful source for every production field
- Maintain a non-LinkedIn fallback for the customer outcome