Search Strategy

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

The core intelligence behind enterprise search. Transforms a single natural language question into parallel, source-specific searches and produces ranked, deduplicated results.

The Goal

Turn this:

"What did we decide about the API migration timeline?"

Into targeted searches across every connected source:

~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
~~knowledge base: semantic search "API migration timeline decision"
~~project tracker:  text search "API migration" in relevant workspace

Then synthesize the results into a single coherent answer.

Query Decomposition

Step 1: Identify Query Type

Classify the user's question to determine search strategy:

Query Type	Example	Strategy
Decision	"What did we decide about X?"	Prioritize conversations (Google Chat, Gmail), look for conclusion signals
Status	"What's the status of Project Y?"	Prioritize recent activity, task trackers, status updates
Document	"Where's the spec for Z?"	Prioritize Drive, wiki, shared docs
Person	"Who's working on X?"	Search task assignments, message authors, doc collaborators
Factual	"What's our policy on X?"	Prioritize wiki, official docs, then confirmatory conversations
Temporal	"When did X happen?"	Search with broad date range, look for timestamps
Exploratory	"What do we know about X?"	Broad search across all sources, synthesize
Brand	"What do we know about [brand]?"	Search brand directory, CRM, editorial archives, marketplace
Job market	"Job postings for [company]"	Search jobs dataset, employer CRM records, API integrations
Editorial	"Articles about [topic]"	Search editorial archives, GraphQL API, Drive
Catalog	"Products from [brand]"	Search marketplace dataset, product database, GraphQL API

Step 2: Extract Search Components

From the query, extract:

• Keywords: Core terms that must appear in results
• Entities: People, projects, teams, tools, brands, markets (use memory system if available)
• Intent signals: Decision words, status words, temporal markers
• Constraints: Time ranges, source hints, author filters, market/region filters
• Negations: Things to exclude

Step 3: Generate Sub-Queries Per Source

For each available source, create one or more targeted queries:

Prefer semantic search for:

• Conceptual questions ("What do we think about...")
• Questions where exact keywords are unknown
• Exploratory queries

Prefer keyword search for:

• Known terms, project names, acronyms, brand names
• Exact phrases the user quoted
• Filter-heavy queries (from:, in:, after:)

Generate multiple query variants when the topic might be referred to differently:

User: "Kubernetes setup"
Queries: "Kubernetes", "k8s", "cluster", "container orchestration"

Source-Specific Query Translation

~~chat (Google Chat)

Semantic search (natural language questions):

query: "What is the status of project aurora?"

Keyword search:

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

Filter mapping:

Enterprise filter	Google Chat syntax
from:sarah	from:sarah or from:<@USERID>
in:engineering	in:engineering
after:2025-01-01	after:2025-01-01
before:2025-02-01	before:2025-02-01
type:thread	is:thread
type:file	has:file

~~knowledge base (Wiki / GitHub)

Semantic search — Use for conceptual queries:

descriptive_query: "API migration timeline and decision rationale"

Keyword search — Use for exact terms:

query: "API migration"
query: "\"API migration timeline\""  (exact phrase)

~~code repositories (GitHub)

File search:

path:src/components filename:Button

Code search:

language:typescript "interface Product"
repo:fashionunited/api "GraphQL schema"

README/doc search:

path:README.md OR path:docs "deployment"

Repository-specific searches for FashionUnited:

Query Intent	Repository	Search Pattern
API endpoints	api	path:src filename:resolver OR schema
UI components	frontend	path:src/components
Data pipelines	integrations	path:feeds OR path:sync
Product schema	product-database	path:models OR schema
Deploy procedures	deploy	path:docs OR README
Company policies	about	path:handbook OR policies

~~project tracker (GitHub Issues/Projects)

Task search:

text: "API migration"
is:issue is:open
assignee:username
label:priority-high

Filter mapping:

Enterprise filter	GitHub syntax
from:sarah	author:sarah or assignee:sarah
after:2025-01-01	created:>2025-01-01
type:milestone	milestone:"Milestone Name"
status:open	is:open

~~data warehouse (BigQuery)

Dataset-specific queries for FashionUnited:

Query Type	Dataset	Example Query
Editorial content	editorial	Articles, publication dates, authors
Job market	jobs	Job postings, employer data, market trends
Marketplace	marketplace	Product listings, brand catalogs
Traffic/analytics	analytics	Page views, engagement, traffic sources
Ad performance	advertising	Campaign metrics, impression data

Query patterns:

-- Editorial archives
SELECT * FROM editorial.articles WHERE title LIKE '%sustainable fashion%'

-- Job posting history
SELECT * FROM jobs.postings WHERE company = 'Brand Name' AND posted_date > '2024-01-01'

-- Marketplace catalog
SELECT * FROM marketplace.products WHERE brand = 'Brand Name'

~~CRM (Vtiger)

Record search:

module: Accounts, Contacts, Opportunities, Invoices
search: "Brand Name" OR "Company Name"

Filter mapping:

Enterprise filter	Vtiger query
type:account	module=Accounts
type:contact	module=Contacts
status:active	accountstatus=Active
owner:username	assigned_user_id=username

Fashion Industry Query Patterns

Brand Lookup

When the query mentions a brand name, search across multiple sources:

User: "What do we know about Gucci?"

1. ~~CRM: Search Accounts for "Gucci" (customer relationship, billing)
2. BigQuery/editorial: Search articles mentioning "Gucci" (news coverage)
3. BigQuery/marketplace: Search products from "Gucci" (catalog presence)
4. BigQuery/jobs: Search job postings from "Gucci" (employer data)
5. GraphQL API: Search brand directory for "Gucci" (official profile)

Job Market Queries

When the query is about jobs or employers:

User: "Design jobs in London this month"

1. BigQuery/jobs: Query postings WHERE category='design' AND location='London' AND posted_date > 30 days ago
2. ~~CRM: Check employer accounts in London with active subscriptions
3. GraphQL API: Real-time job search for design roles in London

Editorial Archive Queries

When the query is about news, articles, or content:

User: "Coverage of Paris Fashion Week 2025"

1. BigQuery/editorial: Query articles WHERE topic='Paris Fashion Week' AND year=2025
2. GraphQL API: Full-text search for "Paris Fashion Week 2025"
3. ~~cloud storage: Check Drive for editorial calendars, photo archives
4. ~~chat: Search #editorial channel for PFW discussions

Marketplace/Catalog Queries

When the query is about products or catalog:

User: "Products from Zara in the women's category"

1. BigQuery/marketplace: Query products WHERE brand='Zara' AND category='women'
2. GitHub/product-database: Check product schema and feed specs
3. GraphQL API: Real-time product search
4. ~~CRM: Check Zara account status for catalog integration

Result Ranking

Relevance Scoring

Score each result on these factors (weighted by query type):

Factor	Weight (Decision)	Weight (Status)	Weight (Document)	Weight (Factual)	Weight (Brand)
Keyword match	0.3	0.2	0.4	0.3	0.4
Freshness	0.3	0.4	0.2	0.1	0.2
Authority	0.2	0.1	0.3	0.4	0.3
Completeness	0.2	0.3	0.1	0.2	0.1

Authority Hierarchy

Depends on query type:

For factual/policy questions:

Wiki/Official docs > Shared documents > Email announcements > Chat messages

For "what happened" / decision questions:

Meeting notes > Thread conclusions > Email confirmations > Chat messages

For status questions:

Task tracker > Recent chat > Status docs > Email updates

For brand/entity questions (FashionUnited specific):

CRM (official relationship) > Brand directory > Editorial coverage > Marketplace data > Chat mentions

For job market questions:

BigQuery jobs dataset > CRM employer records > API integrations > Email correspondence

Handling Ambiguity

When a query is ambiguous, prefer asking one focused clarifying question over guessing:

Ambiguous: "search for the migration"
→ "I found references to a few migrations. Are you looking for:
   1. The database migration (Project Phoenix)
   2. The cloud migration (AWS → GCP)
   3. The email migration (Exchange → O365)"

Only ask for clarification when:

• There are genuinely distinct interpretations that would produce very different results
• The ambiguity would significantly affect which sources to search

Do NOT ask for clarification when:

• The query is clear enough to produce useful results
• Minor ambiguity can be resolved by returning results from multiple interpretations

Fallback Strategies

When a source is unavailable or returns no results:

1. Source unavailable: Skip it, search remaining sources, note the gap
2. No results from a source: Try broader query terms, remove date filters, try alternate keywords
3. All sources return nothing: Suggest query modifications to the user
4. Rate limited: Note the limitation, return results from other sources, suggest retrying later

Query Broadening

If initial queries return too few results:

Original: "PostgreSQL migration Q2 timeline decision"
Broader:  "PostgreSQL migration"
Broader:  "database migration"
Broadest: "migration"

Remove constraints in this order:

1. Date filters (search all time)
2. Source/location filters
3. Less important keywords
4. Keep only core entity/topic terms

Parallel Execution

Always execute searches across sources in parallel, never sequentially. The total search time should be roughly equal to the slowest single source, not the sum of all sources.

[User query]
     ↓ decompose
[Google Chat query] [Gmail query] [Google Drive query] [GitHub query] [BigQuery query] [Vtiger query]
     ↓            ↓            ↓              ↓            ↓            ↓
  (parallel execution)
     ↓
[Merge + Rank + Deduplicate]
     ↓
[Synthesized answer]