Ultrahost/ docs
All examples

Example 04

Experiment

Knowledge Graph

Store the relationships between entities of any kind.

A graph is only as useful as the things you can say about its nodes and edges. Keep the nodes as documents and the connections as edges, then add search, similarity, rules, and upkeep so the graph stays findable and consistent as it grows.

Chapter one

When something joins the graph

A new entity arrives, and a few small jobs make sure it can be found, trusted, and protected.

  1. 1

    At the same time

    Nodes and edges are stored

    Entities and the relationships between them are kept in two different places.

    • Document Database

      Nodes as documents

      Each entity is a JSON document with its own key and content.

    • Graph Database

      Edges as links

      Each relationship is stored as an edge connecting two nodes.

  2. 2
    File Server

    Files become nodes too

    If the entity is a file

    The file is kept in the File engine and joins the graph like any other node, so documents and files live in one web.

  3. 3
    Schemas & Ontology Versioning

    Its content is checked for shape

    The node is compared with the shape declared for its kind, so malformed entities are caught before they spread.

  4. 4
    Authorization Layer

    Who can see it is decided

    Rules establish who has access to each node and each edge, so parts of the graph can stay private.

  5. 5

    At the same time

    It is made findable

    Two views of the node are kept, so people do not need to know its key.

    • Search Engine

      Indexed for words

      The content of nodes and edges is indexed, so they can be found by what they say.

    • Vector DB

      Stored for meaning

      An embedding of the node is saved, so similar nodes can be found across the graph.

Chapter two

When someone asks the graph a question

Every question starts somewhere, then walks the relationships until the answer is found.

  1. 1

    At the same time

    A starting point is found

    Nobody knows the exact key, so the question is first matched to a node in one of two ways.

    • Search Engine

      By keywords

      Search finds the node that mentions the words in the question.

    • Vector DB

      By similarity

      The Vector engine finds nodes that mean something close, even in other words.

  2. 2
    Graph Database

    The best route is chosen

    The Graph Optimizer works out the cheapest way to travel from the starting node to what is needed.

  3. 3
    Graph Database

    The graph is traversed

    The Graph API follows the edges, hop by hop, and returns the nodes and relationships along the way.

Chapter three

While nobody is looking

The graph keeps working on itself, checking its health and learning things nobody wrote down.

A scheduled job wakes up

On a timer, with no one waiting for the result.

  • Measure

    Recalculate the blast radius

    For every node, work out how much of the graph would be affected if it changed or disappeared.

    Cron

  • Verify

    Re-check consistency

    Look for broken links and edges that no longer make sense, before anyone trips over them.

    Cron

  • Derive

    Infer new knowledge

    The ontology and semantic dictionaries are applied to the graph, revealing facts that were never stored directly.

    Schemas & Ontology Versioning

Make it yours

Variations worth trying

  • Begin with nodes and edges only, then add search once the graph is too big to browse.
  • Skip the ontology while you explore, and add it when the edges start to drift.
  • Keep sensitive nodes in their own region of the graph with stricter access rules.

Starting point

Ask your coding agent for your version

Use this prompt as a starting point, then change whatever does not fit your idea.

Build a knowledge graph where entities are nodes, relationships are edges, and everything is searchable, permissioned, and kept consistent.

Use these Ultrahost building blocks, in this flow.

When something joins the graph:
1. Nodes and edges are stored, at the same time:
   - Document Database: Each entity is a JSON document with its own key and content.
   - Graph Database: Each relationship is stored as an edge connecting two nodes.
2. File Server (if the entity is a file): The file is kept in the File engine and joins the graph like any other node, so documents and files live in one web.
3. Schemas & Ontology Versioning: The node is compared with the shape declared for its kind, so malformed entities are caught before they spread.
4. Authorization Layer: Rules establish who has access to each node and each edge, so parts of the graph can stay private.
5. It is made findable, at the same time:
   - Search Engine: The content of nodes and edges is indexed, so they can be found by what they say.
   - Vector DB: An embedding of the node is saved, so similar nodes can be found across the graph.

When someone asks the graph a question:
1. A starting point is found, at the same time:
   - Search Engine: Search finds the node that mentions the words in the question.
   - Vector DB: The Vector engine finds nodes that mean something close, even in other words.
2. Graph Database: The Graph Optimizer works out the cheapest way to travel from the starting node to what is needed.
3. Graph Database: The Graph API follows the edges, hop by hop, and returns the nodes and relationships along the way.

While nobody is looking:
- Measure (Cron): For every node, work out how much of the graph would be affected if it changed or disappeared.
- Verify (Cron): Look for broken links and edges that no longer make sense, before anyone trips over them.
- Derive (Schemas & Ontology Versioning): The ontology and semantic dictionaries are applied to the graph, revealing facts that were never stored directly.

Treat this as a starting point. Keep the parts that fit my idea and adapt the rest.

Next example

Semantic Similarity