Planned capability

Context and provenance

Enrich records only with source-aware, authorized data

Plan profile and organization context as attributed observations rather than a universal truth layer. DewEngine's intended role is to transport data from an approved connected-account capability, preserve native identifiers and timestamps, and let the customer decide how a candidate match should affect its own record.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Planned boundary

No enrichment or extraction API is implemented

The data and enrichment surface is planned and not callable. The repository has no released profile search, company lookup, extraction job, matching service, or customer-facing enrichment resource.

Current evidence: Current persistence covers control-plane accounts and the narrow Calendar development resource. The architecture proposes attendee identities, profiles, companies, provider payloads, and source lineage, but those target models are not implemented evidence for this route.
Target contract: Accept a source account and authorized query, then return observations with provider, native identifier, retrieval time, and schema version; Represent match confidence and competing candidates without silently overwriting the customer's person or company record; Minimize stored raw payloads while preserving the specific fields needed for audit, refresh, and correction
Known limits: Coverage, freshness, accuracy, field availability, and search semantics vary by provider and can change without notice; DewEngine will not promise universal identity resolution, unrestricted scraping, private-data access, or permission to reuse a provider observation for another purpose
Release gates: Select approved provider contracts and document eligible account types, scopes, quotas, and permitted downstream use; Implement provenance, minimization, retention, deletion, correction, and tenant-isolation tests for every stored observation; Validate matching quality and false-positive handling with consented fixtures before any automated record update is enabled

Product decision

Return observations, not an invented golden record

Two providers may disagree about a title, employer, location, or profile URL, and an old observation may once have been accurate. The planned response should identify each source and retrieval time. A CRM, ATS, or agent can then propose a merge under its own policy instead of receiving an unexplained value labeled as truth.

Keep source observations immutable and append refreshed versions
Let the consuming product own merge and overwrite policy

Implementation design

Bind every lookup to account capability

A request should name the connected account whose provider rights authorize the lookup. The connector verifies that the account exposes the requested resource, applies provider quotas, and stores a sanitized observation with its native key. Cross-account caching requires an explicit data-use basis; a coincidental matching identifier is not sufficient authority.

Reject fields absent from the account's capability contract
Partition cached observations by workspace, source, and permitted purpose

Matching model

Make uncertainty reviewable

Candidate matching can combine exact native IDs, verified URLs, normalized domains, and application-provided hints, but each signal has different strength. The interface should expose candidates and reasons, especially when names collide. An uncertain result belongs in a review queue rather than being attached automatically to a customer or applicant history.

Never treat a display name alone as a durable identity key
Record the evidence used for a suggested association

Freshness limits

Let stale and missing data remain honest

Provider records can disappear, become private, move behind new scopes, or omit fields for a particular account. The resource should carry observed-at and expires-at metadata where appropriate, plus a reason when refresh is blocked. Absence must not be converted into a negative fact about a person or organization.

Distinguish not returned, not permitted, not found, and provider failure
Do not extend cache life merely to make coverage appear higher

Release qualification

Test privacy controls with the lookup path

Connector conformance is only one gate. The release suite also needs tenant-crossing attacks, purpose changes, correction requests, partial deletion, export fidelity, and support access checks. Metrics should report freshness and match review outcomes without exposing searched personal data in logs, traces, or webhook diagnostics.

Use synthetic identities for routine failure and load testing
Require a deletion proof for raw payloads and derived match indexes

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Will DewEngine guarantee that an enriched profile belongs to the right person?+

No. The planned model will preserve exact provider identifiers and explain matching evidence, but ambiguous candidates require the consuming application's review. A confidence score is decision support, not identity proof.

Can a lookup result be reused across every customer workspace?+

Not by default. Provider terms, purpose, consent, retention, and tenant boundaries determine whether reuse is permitted. The safer target is source- and workspace-scoped storage unless an approved contract explicitly supports broader caching.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗