#4114 Knowledge Graph Cypher Queries & LLM Prompts

#4114 Given """Knowledge graph 'Artemis III Integrated Hazard Reports'

schema:

Entities: Program, Mission, Hazard_Report, Subsystem Hazard_Cause, Hazard_Cause_Control, Hazard_Cause_Control_Verif

Relationships:

(Program)-[:HAS_MISSION]->(Mission)

(Mission)-[:HAS_SUBSYSTEM]->(Subsystem)

(Mission)-[:HAS_HR]->(Hazard_Report)

(Hazard_Report)-[:REFS_SUBSYSTEM]->(Subsystem)

(Hazard_Report)-[:HAS_CAUSE]->(Hazard_Cause)

(Hazard_Cause)-[:HAS_CONTROL]->(Hazard_Cause_Control)

(Hazard_Cause_Control)-[:HAS_VERIF]->(Hazard_Cause_Control_Verif)

(Mission)-[:HAS_DOC]->(Document)

(Hazard_Report)-[:HAS_DOC]->(Document)

(Hazard_Cause)-[:HAS_DOC]->(Document)

(Hazard_Cause_Control)-[:HAS_DOC]->(Document)

(Hazard_Cause_Control_Verif)-[:HAS_DOC]->(Document)"""

List and describe ten useful queries for first-time reviewer of 30 hazard reports represented in the graph

Stepping into a review of 30 integrated hazard reports can feel a bit like trying to drink from a firehose. Since these reports track everything from life support to propulsion for Artemis III, the goal of your first pass should be to identify hotspots, gaps, and logical flow.

Here are ten queries designed to help a first-time reviewer navigate the complexity of this knowledge graph.

1. The High-Level Landscape

Query: List all Hazard_Reports grouped by Subsystem.

Why it’s useful: This provides an immediate "map" of the mission risk. It helps you see which subsystems (e.g., ECLSS vs. Avionics) are driving the most hazard documentation, allowing you to prioritize your review time.

2. The "Control Gap" Audit

Query: Find any Hazard_Cause that does not have a linked Hazard_Cause_Control.

Why it’s useful: This is a safety "red flag" query. In a mature hazard report, every cause must be mitigated. Identifying causes without controls highlights incomplete work or high-risk areas that haven't been addressed.

3. Verification Traceability

Query: For a specific Hazard_Report, list all Hazard_Cause_Control entities and their associated Hazard_Cause_Control_Verif.

Why it’s useful: This checks the "closing" of the loop. A control is only as good as the test or analysis that proves it works. This query ensures that for every "we will do X to stay safe," there is a corresponding "here is how we prove X worked."

4. Documentation Density

Query: Count the number of Document entities linked to each Hazard_Report.

Why it’s useful: High document counts often indicate "heavy" hazards with complex histories or high criticality. Conversely, a hazard report with very few documents might be under-supported and require a deeper dive into its evidence base.

5. Subsystem Cross-Talk

Query: Identify any Subsystem that is referenced by more than five different Hazard_Reports.

Why it’s useful: This identifies "critical nodes." If the Power subsystem is involved in 15 different hazards, it’s a high-consequence area where a single failure could ripple through multiple safety scenarios.

6. Verification Bottleneck Identification

Query: List all Hazard_Cause_Control_Verif types across the entire Mission.

Why it’s useful: If you see that 80% of verifications are "Analysis" and only 5% are "Test," it tells you the mission is relying heavily on models rather than physical hardware results—a key insight for a reviewer’s risk assessment.

7. The Single-Point Failure Path

Query: Find Hazard_Causes that are mitigated by only a single Hazard_Cause_Control.

Why it’s useful: Redundancy is king in spaceflight. Finding causes with only one control helps you identify potential single-point failures where the mitigation strategy might be "thin."

8. Document Reuse and Consistency

Query: Find Document entities that are linked to multiple Hazard_Reports.

Why it’s useful: This identifies "Master Documents" (like an Interface Control Document). If one of these documents changes, you’ll immediately know which set of hazard reports needs to be updated.

9. Breadth of Cause Analysis

Query: Return the average number of Hazard_Cause entities per Hazard_Report.

Why it’s useful: This helps you understand the granularity of the reporting. If a report only has one cause, it might be too broad; if it has 50, it might be too focused on minutiae, making it hard to see the "big picture" risk.

10. The Deep Trace (The "Thread")

Query: For a specific Hazard_Cause, trace the path: Hazard_Cause → Control → Verification → Document.

Why it’s useful: This is the ultimate "sanity check." It allows a reviewer to pick one specific scary scenario and see exactly how it's controlled, how that control is tested, and where the raw data lives.

Would you like me to help you draft the specific Cypher or SQL syntax for one of these queries?

For each of the 10 queries, provide the Cypher and/or LLM prompts

To help you navigate these 30 hazard reports effectively, I’ve translated the strategies into technical Cypher queries (for a Neo4j-style graph database) and LLM Prompts (if you are interacting with the data via a Natural Language Interface).

1. The High-Level Landscape

Cypher:

MATCH (s:Subsystem)<-[:REFS_SUBSYSTEM]-(hr:Hazard_Report)
RETURN s.name, count(hr) AS report_count
ORDER BY report_count DESC

LLM Prompt: "Give me a summary table showing each subsystem and the total number of Hazard Reports associated with it. Sort it by the highest number of reports."

2. The "Control Gap" Audit

Cypher:

MATCH (hc:Hazard_Cause)
WHERE NOT (hc)-[:HAS_CONTROL]->(:Hazard_Cause_Control)
RETURN hc.id, hc.description

LLM Prompt: "Identify any Hazard Causes in the graph that do not have any linked Hazard Cause Controls. Provide a list of these 'unmitigated' causes."

3. Verification Traceability

Cypher:

MATCH (hr:Hazard_Report {id: 'HR-001'})-[:HAS_CAUSE]->(hc)-[:HAS_CONTROL]->(hcc)-[:HAS_VERIF]->(hcv)
RETURN hc.description, hcc.description, hcv.method

LLM Prompt: "For Hazard Report [ID], show me the full chain from Cause to Control to Verification. I want to see how we are proving each mitigation works."

4. Documentation Density

Cypher:

MATCH (hr:Hazard_Report)-[:HAS_DOC]->(d:Document)
RETURN hr.id, count(d) AS doc_count
ORDER BY doc_count DESC

LLM Prompt: "Rank the Hazard Reports by the number of supporting documents they have. Which reports have the most evidence, and which have the least?"

5. Subsystem Cross-Talk

Cypher:

MATCH (s:Subsystem)<-[:REFS_SUBSYSTEM]-(hr:Hazard_Report)
WITH s, count(hr) AS hr_count
WHERE hr_count > 5
RETURN s.name, hr_count

LLM Prompt: "Which subsystems are referenced by more than five different Hazard Reports? List these 'high-interaction' subsystems."

6. Verification Bottleneck Identification

Cypher:

MATCH (hcv:Hazard_Cause_Control_Verif)
RETURN hcv.type, count(hcv) AS type_count

LLM Prompt: "Analyze all verification entities and give me a breakdown of the verification types (e.g., Test, Analysis, Inspection). What is the most common method?"

7. The Single-Point Failure Path

Cypher:

MATCH (hc:Hazard_Cause)-[:HAS_CONTROL]->(hcc)
WITH hc, count(hcc) AS control_count
WHERE control_count = 1
RETURN hc.id, hc.description

LLM Prompt: "Find any Hazard Causes that are mitigated by only one single Control. I want to flag these for a redundancy review."

8. Document Reuse and Consistency

Cypher:

MATCH (d:Document)<-[:HAS_DOC]-(hr:Hazard_Report)
WITH d, collect(hr.id) AS reports
WHERE size(reports) > 1
RETURN d.title, reports

LLM Prompt: "List any Documents that are used across multiple Hazard Reports. Show me the document title and the IDs of the reports that reference it."

9. Breadth of Cause Analysis

Cypher:

MATCH (hr:Hazard_Report)-[:HAS_CAUSE]->(hc)
WITH hr, count(hc) AS cause_count
RETURN avg(cause_count) AS average_causes_per_report

LLM Prompt: "On average, how many Hazard Causes are defined per Hazard Report? Also, identify any outliers that have an unusually high or low number of causes."

10. The Deep Trace (The "Thread")

Cypher:

MATCH path = (hc:Hazard_Cause)-[:HAS_CONTROL]->(hcc)-[:HAS_VERIF]->(hcv)-[:HAS_DOC]->(d)
WHERE hc.id = 'HC-101'
RETURN path

LLM Prompt: "Perform a deep dive on Hazard Cause [ID]. Show me every linked Control, the Verifications for those Controls, and the specific Documents supporting those Verifications."

Would you like me to generate a mock visualization or a summary table of how these entities might look for a specific subsystem like 'Life Support'?

Summary Table

To help you organize your review strategy, here is a summary table of the 10 queries. This table maps each Review Objective to the Graph Pattern it investigates and the Key Insight you'll gain.

Artemis III Hazard Report Review Strategy

#	Review Objective	Graph Relationship Path	Key Insight for Reviewer
1	Landscape Map	(Subsystem)<-[:REFS_SUBSYSTEM]-(Hazard_Report)	Identifies which subsystems are the most "dangerous" or complex.
2	Control Gaps	(Hazard_Cause) ![:HAS_CONTROL]	Flags safety violations where a cause exists without a mitigation.
3	Verification Trace	(HC)-[:HAS_CONTROL]->(HCC)-[:HAS_VERIF]->(HCV)	Confirms that every safety promise has a corresponding proof.
4	Evidence Density	(Hazard_Report)-[:HAS_DOC]->(Document)	Distinguishes between "mature" reports and those lacking data.
5	Critical Nodes	`(Subsystem)` referenced by `n > 5` Reports	Spotlights hardware that, if failed, impacts multiple safety areas.
6	Risk Posture	Count of `(Hazard_Cause_Control_Verif.type)`	Reveals if the mission is relying on "Tests" (high rigor) vs. "Analysis" (lower rigor).
7	Redundancy Audit	`(Hazard_Cause)` with only 1 `(HCC)`	Highlights single points of failure in the safety architecture.
8	Impact Analysis	`(Document)` linked to `1+ Hazard_Reports`	Shows which documents are "load-bearing"—changing one affects many reports.
9	Granularity Check	Average count of `(HC)` per `(Hazard_Report)`	Identifies if reports are too vague (too few causes) or too fragmented.
10	The "Deep Thread"	(HC)->(HCC)->(HCV)->(Document)	Provides a "drill-down" to verify the technical integrity of a single risk.

Pro-Tip for the First-Time Reviewer

When you start, I recommend running Query #2 (Gaps) and Query #7 (Redundancy) first. These act as "sanity checks"—if you find many causes without controls or single-control mitigations, it’s a signal that the documentation might be premature or the design carries higher risk than intended.

Would you like me to focus on a specific subsystem (like Thermal or Propulsion) to show how these results might look in practice?

For each of the LLM prompts for the ten queries, can they be trusted to respond with a complete and correct list?

The short answer is: Not with 100% certainty. While LLMs are excellent at interpreting the intent of your data, they are prone to specific failure modes when navigating complex knowledge graphs. Think of the LLM as a very smart, slightly overconfident intern—they can find what you need, but you should double-check their math.

Here is a breakdown of why you should apply a "trust but verify" policy to these prompts.

1. The "Hallucination" Risk

LLMs sometimes "fill in the blanks." If you ask for a list of all unmitigated causes (Query 2) and the LLM only finds 8 out of 10, it might simply stop there, or worse, invent a 9th and 10th cause that sound plausible but don't exist in your graph.

The Fix: Always ask the LLM to provide the Unique ID (e.g., HC-402) for every item it lists.

2. The "Context Window" Limit

If your 30 hazard reports contain thousands of causes and controls, the LLM might "forget" the beginning of the list by the time it gets to the end. It may provide a "complete" list that is actually just the most recent part of the data it processed.

The Fix: For large datasets, use the Cypher queries directly in a graph database (like Neo4j) rather than asking an LLM to "read" the whole graph in text form.

3. Counting and Math Errors

LLMs are notoriously shaky with precise counting (Query 1, 4, 9). If you ask for the "average number of causes," the LLM might perform a "vibe-based" estimate rather than a mathematical calculation.

The Fix: Use the LLM to write the Cypher code for you, then run that code against your database. This uses the LLM's strength (coding) and the database's strength (exact math).

4. Directional Confusion

In knowledge graphs, the direction of the relationship matters. An LLM might confuse (Document)-[:HAS_DOC]->(Hazard_Report) with the correct (Hazard_Report)-[:HAS_DOC]->(Document). This can lead to empty results or nonsensical lists.

How to make the LLM Prompts "Trustworthy"

To get the most reliable results, refine your prompts using these three rules:

Demand Schema Adherence: Start your prompt with: "Using only the provided schema (Entities and Relationships)..."
Ask for Citations: "For every hazard report listed, include the specific Document ID that supports it."
The "Chain of Thought" Request: Ask the LLM to explain its logic. For example: "First, identify all Hazard Causes. Second, check if each has a HAS_CONTROL relationship. Third, list only those where the relationship is missing."

A Note on Tooling

If you are using a professional GraphRAG (Graph Retrieval-Augmented Generation) system, these risks are much lower because the system uses the Cypher queries I gave you to fetch the "ground truth" before the LLM even starts talking.

Would you like me to show you how to combine a prompt and Cypher into a "Verification Step" to ensure 100% accuracy?

Yes

To ensure 100% accuracy, you should use a "Verification Loop" (often called a "Text-to-Cypher" workflow). Instead of asking the LLM to "hallucinate" an answer from its memory, you treat the LLM as a translator that writes a precise database query, which then returns the ground truth.

Here is the three-step workflow to ensure you aren't misled during your Artemis III review.

The Verification Loop Workflow

Step 1: The "Code First" Prompt

Instead of asking for the list directly, ask the LLM to generate the logic.

The Prompt:
"I need to find all Hazard Causes that are missing a Hazard Cause Control. Based on the schema provided, write a Cypher query to identify these. Then, explain the logic of that query so I can verify it matches my intent."

Step 2: Human-AI Logic Check

The LLM will provide the Cypher and an explanation. You check if the "logic" sounds right before running it.

LLM Output: MATCH (hc:Hazard_Cause) WHERE NOT (hc)-[:HAS_CONTROL]->() RETURN hc.id
LLM Explanation: "This query looks for all nodes labeled Hazard_Cause and filters for those where the HAS_CONTROL relationship does not exist outgoing from that node."
Your Verification: You confirm that "outgoing" is correct based on the schema (Hazard_Cause)-[:HAS_CONTROL]->(Hazard_Cause_Control).

Step 3: The Data Execution

You run the code in your database. Because the database is executing logic—not "predicting the next word"—the result is mathematically certain.

Comparison: Direct Prompting vs. Verification Loop

Feature	Direct LLM Prompt	Verification Loop (Cypher)
Source of Truth	LLM's internal "memory"	The actual Database
Accuracy	80–90% (Risk of omission)	100%
Scalability	Limited by context window	Unlimited (can scan 1M+ nodes)
Auditability	Low (hard to tell why it missed one)	High (the code is the receipt)

A "Golden Prompt" for the Reviewer

If you want to use the LLM to help you analyze the results without losing accuracy, use this Template Prompt for any of the 10 queries:

"Act as a NASA Safety Data Analyst. I am going to provide you with the JSON output from a graph database query regarding [Query Topic, e.g., Unmitigated Causes].
Summarize the findings.
Identify the most critical subsystem based on this data.
List the IDs of the reports that need immediate attention.
Do not add any IDs that are not present in the attached JSON data."

What's next?

This approach turns the AI from a "storyteller" into a "data scientist."

Would you like me to take one of the more complex queries—like #7 (Single-Point Failures)—and provide the exact JSON structure and the follow-up prompt you'd use to analyze the results?

How do I apply "Human-AI Logic Check" in an automated Python application? I do not want to request user input

To automate the Human-AI Logic Check without a human in the loop, you implement a Multi-Agent "Critic" Pattern. You essentially create a "Debate" between two LLM instances: one that writes the code (the Coder) and one that audits it against the schema (the Auditor).

If they disagree, the Coder fixes the script. Once they agree, the Python script executes the Cypher against your database.

The Automated Workflow (Python Logic)

1. The "Coder" Agent

This agent is tasked with generating the Cypher query.

Prompt: "Generate a Cypher query for: [User Query]. Use only this schema: [Schema]. Return ONLY the Cypher code."

2. The "Auditor" Agent (The Automated Logic Check)

This agent acts as the "Human" validator. It is given a different prompt designed to find errors.

Prompt: "You are a database auditor. You are given a Cypher query and a schema.
1. Check if the relationship directions match the schema.
2. Check if the labels (Entities) exist in the schema.
3. If correct, respond with 'VALID'. If incorrect, explain why."

3. The Python Loop

def get_verified_query(user_intent, schema):
    # Step 1: Generate
    cypher_code = llm_coder.generate(user_intent, schema)
    
    # Step 2: Audit (The "Logic Check")
    audit_results = llm_auditor.check(cypher_code, schema)
    
    if "VALID" in audit_results:
        return cypher_code
    else:
        # Step 3: Self-Correction (Retry once with audit feedback)
        return llm_coder.refine(cypher_code, audit_results)

4. Specific "Guardrail" Functions in Python

Beyond using another LLM, you can use hard-coded Python "Sanity Checks" to ensure the logic is sound before it hits your production data.

A. Schema Keyword Validation

Before executing, use a Python script to scan the generated Cypher for "hallucinated" entities.

allowed_entities = ["Hazard_Report", "Hazard_Cause", "Subsystem", ...] # from your schema

def validate_entities(generated_cypher):
    for word in generated_cypher.split():
        if ":" in word: # Looking for labels like :Hazard_Report
            label = word.split(":")[1].strip("() {}[],")
            if label not in allowed_entities:
                raise ValueError(f"LLM Hallucinated an entity: {label}")

B. Directionality Enforcement

Since the LLM might flip (A)-[:HAS_CONTROL]->(B), you can use a dictionary of "Legal Triplets" to verify the relationship logic.

legal_triplets = [
    ("Hazard_Report", "HAS_CAUSE", "Hazard_Cause"),
    ("Hazard_Cause", "HAS_CONTROL", "Hazard_Cause_Control")
]

# A simple regex can check if the generated Cypher respects these pairs.

C. Read-Only Execution

To prevent the LLM from accidentally generating a DELETE or REMOVE command (a common "Logic" error where it tries to "fix" the data), always wrap your Python execution in a Read-Only Transaction.

Summary of the "Automated" Logic Check

By chaining these steps, you replace the "Human" in the loop with a Validator Agent and a Schema Enforcement Script:

LLM 1 (Coder): Writes the Cypher.
LLM 2 (Auditor): Checks the Cypher against the schema.
Python Script: Strips out any commands that aren't MATCH or RETURN.
Database: Executes the query.
LLM 1 (Summarizer): Interprets the final JSON results for the user.

Would you like me to write a complete Python class structure that demonstrates this "Agent-Auditor" flow for your Hazard Reports?

From <https://gemini.google.com/app/2aed963614709710> Google Gemini 3.0 Pro (Thinking)