Operational discovery

A call handler hears “boiler keeps cutting out after the fan runs.” An engineer remembers something similar from last winter. An account manager wants to know whether the same customer has seen the pattern before. VH3 AI connects every job to the right customer, site, engineer, and outcome — and keeps those links searchable. When someone asks “have we seen this before,” the answer comes back in under a second. When someone needs a brief, comparison, or narrative, Connie, reports, and investigations read the same prepared operation to build it.

Before you search

How relational, semantic, structured, and temporal memory combine into one operational picture.

What discovery gives you

Most teams have tried one of these:

Keyword search in the field management system (exact words, ten ways to describe the same fault, no match).
A generic AI chat over exported spreadsheets (similar text, no customer context, no links between jobs).

Neither connects a job to its customer, its place, its engineer, and its outcome — and keeps that whole picture searchable. VH3 AI separates lookup from judgement. Discovery finds similar jobs, resolves entities, ranks precedents, and scopes by customer. Connie, reports, and investigations turn that evidence into a narrative when someone needs a brief, comparison, or recommendation.

New to the platform? Working with your operation walks operators through how to brief Connie and when to reach for discovery first. Use it alongside this page.

Your enriched operational model belongs to your organisation. It is isolated per tenant, exportable, and intended to outlive any single field system or UI. Discovery and agents both read from that model.

The contact-centred model

Every record in your operation resolves around the customer (contact). A retail chain, a housing block, and a single-site café are contacts in your model. Places are addresses and locations linked to that contact: where work happened, described in language your teams already use. Records stay connected so jobs, outcomes, engineers, and places align even when source systems spell names differently. In documentation and customer-facing apps, prefer:

Customer / contact (contact_id) for scoping
Place (address, postcode) for human-readable context
Engineer (resource_id) when filtering by who attended

Do not expose internal linkage identifiers in end-user interfaces.

When scoping search, start from the customer wherever possible. “Everything we have done for this account” maps cleanly to contact_id filters on discovery endpoints.

Four discovery capabilities

Discovery covers four complementary capabilities, all running on the same enriched data.

1. Precedent discovery (meaning plus keywords)

Find jobs that resemble a fault or outcome, even when nobody used the same words twice. Field service intuition: A call handler types “combi losing flame after fan runs.” The platform surfaces jobs described as “intermittent heat,” “boiler lockout,” or “CH unit tripping,” because matching combines meaning and terminology, not keywords alone. Best for: First-time fix support, pre-visit research, technical precedent across the operation.

Endpoint	Searches	When to use
`POST /search/outcomes`	Enriched outcomes (what was found and done)	“How was this fixed before?”
`POST /search/intake`	Original fault descriptions	”What was reported?”
`POST /search/intake/enriched`	Intake plus connected context per hit	When you need the thread, not just the snippet
`POST /search/summary-sections`	Customer knowledge sections (see below)	Account themes, risk, equipment patterns

2. Entity resolution (finding the right record)

Resolve customers, people, engineers, and jobs when names are misspelled, abbreviated, or inconsistent across systems. Field service intuition: Dispatch hears “Pure Gym Manchester” while the CRM says “PureGym Ltd.” Resolution matches sound-alike and look-alike names, postcodes, partial emails, and references so the right contact is selected before anyone runs a broader search. Best for: Call handling, email triage, automations that must attach work to the correct account. Primary endpoint: GET /search/autocomplete This path uses multi-strategy entity resolution: multiple matching strategies (spelling, sound-alike, postcode, references, partial emails) plus cross-checks against the operational graph. Strategies combine into a single ranked candidate list. Inbound email and portal traffic uses the same resolution philosophy: extracted names and addresses are matched back to contacts in your model so new work lands on the right account.

3. Connected results

A useful precedent is a job tied to a customer, a place, an engineer, and an outcome. Enriched search responses attach that context so briefings, cases, and Connie do not rebuild relationships on every request. A search result on VH3 AI carries the account history, not just the matching snippet. Field service example (connected intelligence):

“Show me every job Engineer Patel completed for Tesco in the last twelve months, and how each one went.”

That question is relational and structured. Aggregations and Connie handle the traversal; discovery endpoints help when you start from language (“repeat fire panel faults at Tesco stores”) and then narrow by contact_id and date range.

4. Continuous signals (temporal memory)

Some insights should surface before anyone searches. Sentinels evaluate patterns on the graph continuously: performance slips, repeat visits, dormant accounts, overdue rhythms, engineer-flagged follow-ups. Detection is a structured read at the data layer with near-zero AI cost at detection. Agents pick up from there. Connie, automations, or case workflows consume sentinel output, run discovery for precedents, and open cases for human follow-through. Search finds what happened before; sentinels flag what is changing now.

Customer knowledge base (modular, searchable, kept current)

Each customer can have a Customer Summary: a structured knowledge object stored in your operation — searchable and updated as jobs land, not locked in a one-off PDF or chat thread. The summary is split into seven independent sections, each indexed for discovery on its own:

Section key	Typical content
`customer_overview`	Account context, locations, primary service needs
`job_history_patterns`	Job types, frequency, reactive vs planned balance
`systems_equipment`	On-site systems, makes and models
`key_analyses`	Recurring issues, root causes, maintenance themes
`operational_performance`	Engineer performance, punctuality, scheduling
`communication_summary`	Contacts, access issues, escalation patterns
`risk_opportunity`	Risks, opportunities, quick wins vs strategic actions

Each section has its own searchable index. You can query one dimension (for example equipment profiles only) or search across all sections. Results are ranked and scored like job precedent search, with near-zero AI cost at retrieval.

Keeping summaries current

Summaries are generated from the operational graph and enriched jobs, then stored for reuse.
Incremental refresh updates accounts when job volume or age thresholds indicate drift, so Connie and APIs do not rely on stale narratives.
When Connie opens a conversation, the platform can inject the stored summary plus a compact list of jobs completed since the summary was generated, so the picture stays current without regenerating the full report every time.

API paths

Action	Endpoint
Search sections by meaning	`POST /search/summary-sections` (optional section key filter)
Fetch full summary for one contact	`GET /search/summary-sections/by-contact/{company_id}/{contact_id}`
Regenerate or refresh the knowledge base	`POST /backfill/summary-kb` (async; see API reference)

Use section-scoped search for portfolio questions: “Which accounts mention recurring boiler issues in risk sections?” Use the by-contact GET when you need the full account brief in one call.

Ranking and similarity (without exposing the engine)

Job similarity and result ordering use combined meaning and keyword ranking: signals from meaning-based matching and exact-term matching are fused into one ordered list. You do not maintain synonym lists or search dictionaries. Narrative text is indexed once at ingest and ranked against the same representation at query time.

We do not publish internal ranking or generation settings. Reliability comes from resolved entities, structured outcomes, and linked records, not from a single search shortcut.

What you can rely on in product terms:

Precedent quality improves as history grows and entities resolve more cleanly.
Exact references (asset tags, model numbers, product codes) still rank strongly when they appear in worksheets.
Scoping (customer, date range, job type, engineer) sharpens results more than clever query wording alone.

Field service query playbook

Write queries the way you would brief a colleague. Then scope to the customer or date range when you know them.

Call handler / dispatcher

Situation	Example query	Endpoint
New callout, need precedents	`intermittent heating loss unit not maintaining temperature`	`/search/outcomes`
Only original wording matters	`tenant reported no hot water since yesterday`	`/search/intake`
Wrong customer name on phone	Resolve “Smith Security” / “Smyth Alarms”	`/search/autocomplete`

Engineer (pre-visit)

Situation	Example query	Scoping
Same account as last month	`repeat fault fire alarm panel isolate`	Filter by `contact_id`
Unfamiliar kit on worksheet	`CCURE 9000 access controller fault`	Outcomes search; exact kit names help the keyword leg

Operations manager

Situation	Example query	What to combine
Pattern across an account	`escalating repeat attendance same equipment`	Outcomes search + sentinel digest
Account review prep	`HVAC performance decline`	`/search/summary-sections` + account monthly report

Commercial / account manager

Situation	Example query	What to combine
Evidence for QBR	`SLA punctuality and repeat visits`	Summary sections + account monthly report
Quiet account	(no search required)	Dormant-customer sentinel, then Connie for narrative

Scoping search in the API

Combine natural language with structured filters. Use snake_case field names as in the API reference.

curl -X POST "https://api.vh3connect.io/api:kP8T1CK7/search/outcomes" \
  -H "Content-Type: application/json" \
  -d '{
    "company_id": "your-company-id",
    "api_key": "your-api-key",
    "query_text": "water leak from ceiling void",
    "limit": 10,
    "contact_id": "your-contact-id"
  }'

Broad fault language finds precedents across the operation. Tight filters (customer, date range, job type) turn precedents into account-specific or place-specific context.

When discovery ends and synthesis begins

Start with discovery when you need a ranked list, a resolved customer, or a quick account signal. Move to synthesis when the evidence needs to become a brief, comparison, recommendation, or client-ready explanation.

You need	Use
A ranked list of similar past jobs	`POST /search/outcomes` or `/search/intake/enriched`
To resolve a misspelled customer or person	`GET /search/autocomplete`
Themes across account knowledge sections	`POST /search/summary-sections`
A cited narrative, comparison, or “why”	Connie (`POST /connie/chat`) or `POST /investigate`
What changed this week without asking	`POST /sentinels/run`
Structured follow-through	Cases API (escalations, complaints, multi-step work)

/investigate and Connie with tools are synthesis paths (multi-step, higher latency). Set client timeouts accordingly (see Agent Starter Kits). Discovery endpoints are the fast first hop.

How agents use discovery

Connie and automation agents work through the same enriched operation:

Sentinels surface a pattern (for example repeat visits on an account).
Discovery retrieves precedents, similar outcomes, or relevant summary sections.
Structured records supply compact job context without re-reading raw worksheets.
Connie or a case turns evidence into a briefing, a Slack message, or owned follow-up.

Teams and case management add ownership and workflow: assign a case to a regional team, link jobs and sentinel triggers as case items, progress through review states. That is how AI integration becomes an operational process with owners, evidence, and follow-through.

Data sovereignty and why discovery stays fast

VH3 AI builds your operational model alongside your field systems:

Enrichment and entity resolution run when data lands, not on every search.
Rankings and graph reads use that prepared picture.
LLM spend is reserved for interpretation and narrative.

If you change field systems later, the model and history remain yours to connect to the new source. Discovery, sentinels, and agents keep reading the same prepared operation.

Intelligence layer

Four memory primitives and the synthesis contract.

Search API

Request fields, endpoints, and examples.

Building on the layer

Citizen builders, coding agents, integrations, and secure extensibility.

Connie

Conversational synthesis with citations.

Sentinels

Watches your operation around the clock and surfaces patterns before they escalate.

Native integrations

Connect inboxes, calendars, CRM, and storage into the same model.

​Operational discovery

Before you search

​What discovery gives you

​The contact-centred model

​Four discovery capabilities

​1. Precedent discovery (meaning plus keywords)

​2. Entity resolution (finding the right record)

​3. Connected results

​4. Continuous signals (temporal memory)

​Customer knowledge base (modular, searchable, kept current)

​Ranking and similarity (without exposing the engine)

​Field service query playbook

​Call handler / dispatcher

​Engineer (pre-visit)

​Operations manager

​Commercial / account manager

​Scoping search in the API

​When discovery ends and synthesis begins

​How agents use discovery

​Data sovereignty and why discovery stays fast

​Related

Intelligence layer

Search API

Building on the layer

Connie

Sentinels

Native integrations

Operational discovery

What discovery gives you

The contact-centred model

Four discovery capabilities

1. Precedent discovery (meaning plus keywords)

2. Entity resolution (finding the right record)

3. Connected results

4. Continuous signals (temporal memory)

Customer knowledge base (modular, searchable, kept current)

Ranking and similarity (without exposing the engine)

Field service query playbook

Call handler / dispatcher

Engineer (pre-visit)

Operations manager

Commercial / account manager

Scoping search in the API

When discovery ends and synthesis begins

How agents use discovery

Data sovereignty and why discovery stays fast

Related