Your data is connected. Can you find a pattern like this one?
A delayed sales order shows how searching connected patterns could help teams find useful past cases, then check the facts in a graph.
On this page
Connected data is everywhere. A purchase connects a person to products and places. A repair connects a machine to symptoms, parts, and earlier maintenance. These relationships are part of ordinary work, even when our systems present the information in separate categories.
We often come to think in those categories too: orders, products, customers, addresses. Each view serves a purpose, but answering a practical question can mean putting the pieces back together.
Imagine you work in sales operations. A customer asks about an order that has not arrived, and you need to work out what to check next.
You open the order, look at its items, and switch to fulfillment to find the shipping point and destination. Customer records provide another view of the address. You remember handling something similar, but cannot remember which order it was. Finding that case might save you from repeating the investigation.
What if you could use the connected pattern in front of you to find that earlier case?
Follow the connections
A graph makes recorded relationships explicit. An order contains an item; the item ships to an address; a customer record references that address. Starting with the order, you can follow those connections and inspect the details.
Relational joins (in SQL) can also assemble the same information. A report might also show whether delays have increased at the shipping point. These are useful answers: what is connected to this order, and what is happening across many orders?
Your remembered case raises another question: which previous situations resemble this one?
You might know the product category, the shipping point, and the destination country, while the region is missing from the information currently available. The relevant precedent could involve another customer or a nearby destination. You want enough shared context to make the comparison useful.
When the pattern is the best query you have
Searching for this customer excludes other customers’ orders. Requiring every known detail to match might exclude a relevant case with a similar pattern. Relaxing several filters gives you more results, but leaves you deciding which ones deserve attention.
SQL and graph queries can handle optional information, and developers can write rules that assign more importance to some matches than others. Modern databases also support forms of similarity search.1
The opportunity is to make a selected connected pattern searchable as a whole. Instead of repeatedly adjusting filters, you could use the parts of the situation you know to retrieve a shortlist of comparable cases.
For this investigation, a fulfillment specialist might judge the shipping point and product category more useful than the customer’s name. Another investigation might depend strongly on the destination. Choosing what makes cases meaningfully alike is part of the work, whichever search method we use.
Give the pattern a searchable representation
Hyperdimensional computing (HDC) can support associative memory, where an input pattern prompts recall of a stored pattern associated with it. Here, we propose using the known relationships and properties of an order to retrieve similar stored order patterns.
HDC represents information as long numerical patterns called hypervectors. It also provides composable operations for building representations2 that capture roles and relationships and can be compared by similarity. Selected details can be combined while distinguishing their roles. A location used as a shipping destination, for example, plays a different role from the place an item ships from.
For our order, we could combine selected relationships and properties into a hypervector representing that connected context. Other order contexts would have their own hypervectors. “Hyperspace” is the space in which we compare these representations. We still keep the original graph records and a way to open them from each search result.
The known parts of your current order become the search input. If the region is unavailable, that detail is omitted. Comparing this partial representation with stored patterns could retrieve cases that share enough of the represented context to be worth inspecting.
This is where modeling matters. Many orders share the same relationship structure. Including properties that vary, such as product category and shipping point, lets the search distinguish their circumstances. Choosing those properties with the operations team helps focus retrieval on patterns that matter to the investigation.
Open the candidates and check the details
Suppose the search finds a past order for lamps shipped from East depot to Canada. It shares the product category, shipping point, and destination country with the order you’re investigating. These similarities make it a useful starting point: what happened to that shipment, and how did the team respond?
You open the past order and follow its connections to the item and delivery address. Where shipment history and case notes are linked, you can continue into the investigation itself: the shipment’s status, the actions recorded by the team, and how the case was resolved. The graph gives you a way to move from a promising match to the records that explain what happened.
Perhaps the earlier case involved a dispatch hold that is worth checking now. You have a specific question for fulfillment, supported by a case they can inspect. You can check the current shipment status to see whether the same issue applies.
HDC proposes candidates, while the graph provides the details to validate their relevance. You can inspect a past case’s destination, shipment history, and recorded actions, then compare them with the current order to decide which explanation to investigate.
The proposed workflow could put relevant history close at hand when someone needs to decide what to investigate next. For the operations team, that means drawing on earlier investigations to ask more focused questions and choose a useful next step.
Where else would a pattern help?
A maintenance technician might face a similar problem when symptoms arrive without a clear diagnosis. Comparing symptoms together with the machine’s components and operating conditions could surface relevant service history. The technician could inspect the earlier repair and check its suitability for the current configuration.
In software support, the same error message can arise in different circumstances. A pattern that includes dependency versions and customer configuration could help locate a more useful precedent. The next step would be to inspect the incident and verify that its resolution remains applicable.
In these scenarios (and many others), comparable history and an understanding of the relevant relationships give the search a useful foundation. HDC offers a way to represent this connected information so a partial pattern can bring relevant history into view.
If you find yourself regularly asking “have I seen a pattern like this before?”, reach out to us with a recurring situation, the information you already have, and what a useful result would help someone do downstream. We would welcome a conversation at HDC Labs about whether the techniques described above fit your use case.
If you’re interested in the technical argument behind this scenario, see our blog post on why connected data needs associative search.
Footnotes
-
Cypher supports optional pattern matching, PostgreSQL offers text similarity through
pg_trgm, and Neo4j provides full-text and vector indexes. ↩ -
Kleyko and colleagues’ survey of HDC/VSA models and data transformations, especially sections 2.2 and 3, explains structured representations, role-filler bindings, and similarity. The sales-order scenario applies these representation principles to finding relevant history. ↩