01
Product value
Advanced search should reduce review cost
More filters are useful only when they help a user reach a defensible research set. Define which decision each filter supports and how the result will be reviewed. DewEngine's target catalog includes search.perform but no implemented LinkedIn adapter, approved query contract, or filter schema. Advanced search therefore remains a product-research topic behind the legal and provider decision gate.
- Measure time to a reviewed shortlist, not filter count
- Keep a workflow for customer-provided or licensed search data
02
Filter contract
Type every filter and state its semantics
Location, company, role, relationship, list membership, and free-text criteria can behave differently across product entitlements. Use explicit operators, controlled values where available, and a versioned schema. Do not translate an unsupported filter into a vaguely similar query. A customer should be able to inspect what was requested, what the authorized provider contract accepted, and what was omitted.
- Return field-level validation for unsupported combinations
- Preserve the original user intent beside any normalized query
03
Reproducibility
Treat saved search as a versioned instruction
A saved search should contain a tenant-owned definition, account or entitlement requirements, creator, purpose, and revision history. Results are observations from a run, not permanent members of the definition. When filters change, retain the old version so prior CRM decisions remain explainable. Re-running later may produce different candidates and must not rewrite the original evidence.
- Separate the query definition from each execution record
- Show users when entitlement changes invalidate a saved filter
04
Result interpretation
Explain why a candidate is in the set
A review interface can show matched filters and the fields that supported them, while clearly labeling provider order and customer scoring as separate concepts. Missing attributes should not be treated as failed criteria unless the contract proves the field was evaluated. For recruiting, never infer protected characteristics or let search position make an advancement decision; for sales, never treat inclusion as buying intent.
- Display matched, unknown, and conflicting criteria
- Keep human rejection reasons available for future review
05
Operational design
Bound expensive queries and partial runs
Compound searches need conservative account budgets, pagination checkpoints, cancellation, deduplication, and honest coverage. A worker should persist a page before advancing and stop when authorization, entitlement, or provider health changes. Cached results need source time and account scope; sharing a cache across tenants or accounts can leak personalized visibility and invalidate the meaning of the query.
- Scope caches and cursors to account plus query version
- Let users cancel without discarding reviewed results
06
Qualification
Prove each filter on the exact product variant
A release suite must cover filter validation, combinations, pagination, reordering, empty and partial results, subscription change, account restriction, throttling, tenant substitution, saved-search migration, retention, and deletion. It also needs qualified legal review, provider authorization, consented real-account fixtures, and current capability documentation. Without these, advanced search cannot be described as available through DewEngine.
- Maintain a conformance row for every advertised operator
- Disable stale filters instead of approximating them silently