Graph Engineering Workbook

    Build the graph
    that earns its place

    Use this as a working document. Bring one recurring question, five to ten source records, and enough time to compare your graph against a simpler baseline.

    Before you build

    A 30-minute first pass

    Do these in order. Stop if the graph does not improve the question you chose.

    1. 01Write one question that requires more than a single record, such as which commitment is at risk and why.
    2. 02Collect five to ten source records and give each a stable reference, observed timestamp, and owner.
    3. 03Run the decision matrix. Start with direct lookup or vector search when they answer the question cleanly.
    4. 04Model only the entities and relationships needed for the question. Add provenance to every important edge.
    5. 05Save the baseline answer, graph answer, evidence list, corrections, and score in one evaluation record.
    Operating loop
    01Question and scope
    02Evidence and extraction
    03Query and answer
    04Review and re-evaluate
    01 / Start with the question

    A one-page model prevents an expensive detour.

    Fill this in before choosing Neo4j, Postgres, a graph library, or a managed service. A graph is justified only when the relationship structure changes the answer or the maintenance workflow.

    Question-first design canvas
    QUESTION: Which commitments are at risk, why, and what should happen first?
    
    SCOPE: One launch project, current quarter
    ENTITIES: people, project, commitment, task, decision, source
    RELATIONSHIPS: owns, part_of, blocks, supports, evidenced_by
    MUST_INCLUDE: owner, due date, blocker, evidence, freshness
    MUST_NOT_CLAIM: causality that no source records
    BASELINE: direct lookup plus filtered task list
    SUCCESS: answer is more complete and still traceable

    If the baseline already answers the question, keep the graph as a later experiment. The design canvas is also the boundary that stops an ontology from expanding without a user-facing reason.

    Graph retrieval is one tool among several. Use the simplest method that preserves the evidence and answers the question.

    Question shapeStart withReason
    What is the current due date?Direct lookupA single authoritative field is easier to validate than a relationship query.
    Which notes are similar to this one?Vector searchSimilarity is the primary signal. A graph may be unnecessary.
    Which decisions affect this commitment through a task?GraphTyped paths and intermediate entities are part of the answer.
    What changed, who owns it, and which source supports it?HybridUse structured relationships for joins and text retrieval for the source passages.
    What are the next three steps in this checklist?No graphA document or workflow state is clearer and cheaper to maintain.
    Rule of thumb: Add a graph when a typed, inspectable path changes the answer. Do not add one to make a simple lookup sound more advanced.
    Second Brain 2.1

    The graph is one layer of the operating brain.

    Use the relationship layer to connect current truth, timelines, commitments, decisions, and work items. Keep the surrounding contracts explicit: task truth, rituals, memory ownership, evidence-gated learning, provider routing, and automation state.

    Explore Second Brain

    Your first graph slice

    Finish with one question that matters to your work this week. Keep the scope small enough that you can inspect every important edge.

    1. 01Write the question and the baseline method you would use without a graph.
    2. 02List five to ten source records and assign stable references.
    3. 03Name no more than six entity types and five relationship types for this slice.
    4. 04Add evidence, observed time, confidence, review state, and retirement rules.
    5. 05Run one query, return the evidence with the answer, and record one likely failure.
    6. 06Score baseline versus graph, then decide whether to keep, simplify, or retire the graph.

    Sources and further reading

    The implementation boundaries in this guide are grounded in official documentation. Community posts can suggest questions, but they are not used here as evidence for performance or product claims.

    Sources checked July 2026. Product capabilities, APIs, pricing, and provider availability can change. Verify the current documentation before implementing a production system.

    Build the smallest graph that can be checked.

    If the relationship layer cannot improve an answer, expose its evidence, and survive a correction, it is not ready to become part of the operating system.

    See Second Brain