Context Streams

The 8 data streams injected into every query to give the AI full situational awareness.

What context streams are

Context streams are structured data injected into the query pipeline alongside the technician's question and the retrieved source documentation. They give the AI situational awareness beyond what the manual says -- the actual fault codes present, the customer's service history, parts availability, relevant TSBs, and diagram context.

Every query can receive up to 8 context streams. Each stream is optional and configured per-tenant. When a stream is enabled, its data is fetched at query time and included as structured context.

The 8 streams

#	Stream	Source	What it provides
1	Step Notes	Database	Technician's free-text notes on the current work order. Pulled at runtime from the session context.
2	Fault Codes	Fault code library + ontology	Structured info for active fault codes: description, system, common causes, related codes, severity. Includes OBD-II to manufacturer code translation.
3	Customer Context	Work order / DMS integration	Customer name, vessel/equipment info, and active complaint. Helps the AI personalize responses to the specific unit.
4	Feedback History	Database	Previous queries and feedback from this session. Lets the AI avoid repeating answers the technician already rejected.
5	Parts Inventory	Mock or DMS integration	Real-time parts availability for part numbers referenced in the retrieved documentation. Shows in-stock quantity, bin location, price, and ETA for backordered parts.
6	Service History	Mock or DMS integration	Previous work orders for this equipment: dates, complaints, resolutions, engine hours at service, and which tech performed the work.
7	TSB Matching	TSB database	Technical Service Bulletins matched by equipment model and symptom keywords. Includes superseded part numbers and recommended actions.
8	Diagram Context	Image lookup index	Diagram and image references for cited pages. Lists available diagrams per page with image IDs and types (actual diagram vs. page render).

How streams flow into the pipeline

Technician query
    │
    ├── Stream 1: step notes (from session)
    ├── Stream 2: fault code lookup (from query + telemetry)
    ├── Stream 3: customer context (from work order)
    ├── Stream 4: feedback history (from session)
    │
    ▼
  Retrieval (source documentation)
    │
    ├── Stream 5: parts inventory (from part numbers in results)
    ├── Stream 6: service history (from customer name)
    ├── Stream 7: TSB matching (from model + symptoms)
    ├── Stream 8: diagram context (from cited pages)
    │
    ▼
  Generation (all streams + retrieved documentation)
    │
    ▼
  Structured response

Streams 1-4 are available before retrieval and can influence query expansion. Streams 5-8 depend on retrieval results (part numbers from the documentation, cited pages, equipment model from context) and are injected after retrieval but before generation.

Stream configuration

Streams are controlled at two levels:

Tenant configuration:

Enable/disable each stream per namespace
Set the data source (mock, integration, none) for streams 5-7
Configure integration adapters for real data sources

Per-query override (API request body):

telemetry_context: inject specific telemetry readings
fault_code_context: inject specific fault codes
include_telemetry: boolean to force-include telemetry stream

Fault code database

Stream 2 uses a structured fault code library that maps OBD-II codes to rich context:

{
  "P0217": {
    "description": "Engine Coolant Over Temperature",
    "system": "cooling",
    "common_causes": [
      "Thermostat stuck closed",
      "Low coolant level",
      "Water pump failure",
      "Blocked heat exchanger"
    ],
    "related_codes": ["P0116", "P0117", "P0118"],
    "severity": "critical"
  }
}

This works alongside the ontology expansion -- the fault code library provides structured context for generation, while the ontology maps fault codes to manufacturer-specific terminology for retrieval. Both are needed for accurate fault code handling.

TSB matching

Stream 7 matches Technical Service Bulletins by equipment model and symptom keywords extracted from the query and fault codes. Matching is keyword-overlap based, ranked by relevance. Example:

A query about "overheat alarm on Model A" with fault code P0217 matches:

TSB-2025-003: Thermostat Housing O-Ring Premature Failure (keywords: overheat, thermostat, coolant temperature)

TSBs include superseded part numbers, which lets the AI recommend updated parts in the response.

Parts inventory lookup

Stream 5 extracts manufacturer-format part numbers from the retrieved documentation using pattern matching, then looks up each in the inventory database. The result tells the AI:

Whether the part is in stock
Quantity available and bin location
Price
ETA for backordered parts

This enables responses like "Replace thermostat (PART-12411-00, $42.50, 3 in stock at Bin A-12)" instead of just listing the part number.

Eval queries with context streams

Eval queries can include context streams to test multi-stream reasoning. A query config might specify:

{
  "query": "P0217 overheat alarm on the engine",
  "context_streams": {
    "fault_codes": ["P0217"],
    "telemetry": { "coolant_temp_f": 225, "rpm": 5200 }
  },
  "expected_stream_usage": ["fault_codes", "telemetry"],
  "expected_facts": ["thermostat", "trouble code 46"]
}

This verifies that the pipeline uses fault code context and telemetry data to produce a better answer than document retrieval alone. See Eval Management for details.

Widget API -- endpoint catalog including diagram highlighting
Dashboard Configuration -- enable/disable streams per tenant
Tuning & Customization -- how to build fault code maps for new manufacturers
Diagram Highlighting -- how stream 8 powers visual context

Context Streams

On this page