#4501 Systems Engineering KG V2.0
#4501 Systems Engineering KG V2.0
#4501 Evaluate and improve the following proposed framework:
"""Systems Engineering Knowledge Graph
Domains: id, name, description
Systems: id, domainId_FK, name, functional description
Subsystems: id, systemId_FK, name, functional description
Components: id, subsystemId_FK, name, functional description
Parts: id, componentId_FK, name, functional description
Concept:
Systems across domains may have similar functional needs but satisfy them differently.
The goal is to identify these pairs and evaluate if and how any change for improvement can be apply to either system."""
The core concept behind your framework is powerful and deeply rooted in advanced systems architecture and systematic innovation (like TRIZ's functional approach). By abstracting systems to their functional requirements, you can cross-pollinate solutions across entirely different domains—for example, realizing that a thermal management system in an aerospace vehicle shares fundamental functional physics with cooling a high-performance local computing cluster.
However, the current proposed framework is structured as a hierarchical relational database schema rather than a true Knowledge Graph.
Here is an evaluation of the constraints in the current design, followed by a refactored, graph-native approach optimized for cross-domain functional mapping.
Evaluation of the Proposed Framework
1. Structural Rigidness (The Hierarchical Trap)
Your current model enforces a strict, top-down tree structure: Domain ➔ System ➔ Subsystem ➔ Component ➔ Part.
The Problem: In complex engineering, system boundaries are fluid. A "subsystem" in one context might be treated as an independent "system" or a "component" in another. Furthermore, strict foreign keys (
subsystemId_FK) force a rigid 1-to-many parent-child relationship.The Impact: It prevents you from easily modeling multi-parent relationships (e.g., a power distribution unit that serves three different subsystems simultaneously).
2. Functional Isolation
By burying the "functional description" as a text attribute inside each entity, the system's actual behavior is isolated.
The Problem: A graph cannot easily compute semantic or structural similarities between two systems if their function is trapped in a free-text string field.
The Impact: To find systems with "similar functional needs but different implementations," you would have to rely heavily on fuzzy text matching or external vector embeddings, rather than leveraging the topology of the graph itself.
The Improvement: A Graph-Native Functional Ontology
To unlock cross-domain discovery, we need to separate System Topology (what the thing is and where it lives) from Functional Abstraction (what the thing does).
Instead of treating functions as properties, we elevate Functions and Mechanisms to independent nodes. This allows different systems from entirely different domains to converge on shared functional nodes.
Refactored Graph Schema (Property Graph Model)
[:BELONGS_TO] [:HAS_PART] [:HAS_PART]
(Domain) <--------- (System) -----------> (Subsystem) -----------> (Component/Part)
| | |
| [:EXECUTES] | [:EXECUTES] | [:EXECUTES]
v v v
(Functional Requirement) <----------------------------------+
|
| [:SATISFIED_BY]
v
(Mechanism / Design Solution)
Core Node Types
(:Domain): The high-level context (e.g., Aerospace, Marine, Computing).(:System),(:Subsystem),(:Component): Structural entities. We can simplify this by using a generic(:System)node with a recursive[:HAS_PART]relationship to allow infinite nesting without breaking the schema.(:Function): Expressed as an [Action + Object] pair (e.g.,Regulate Temperature,Store Energy,Isolate Vibration).(:Mechanism): The specific implementation choice (e.g.,Liquid Nitrogen Loop,Phase Change Material,Rammed Earth Mass).
Sample Cypher Implementation (Neo4j)
By shifting to this architecture, your graph can effortlessly bridge domains. Here is how you can model and query this framework to achieve your goal.
1. Data Ingestion Example
Let's map two completely different systems that share a functional need:
// Create Functions and Mechanisms
MERGE (f1:Function {id: "F_COOL", action: "Absorb", target: "Thermal Energy"})
MERGE (m1:Mechanism {name: "Active Liquid Cooling Loop"})
MERGE (m2:Mechanism {name: "Passive Earth-Sheltered Thermal Mass"})
MERGE (f1)-[:SATISFIED_BY]->(m1)
MERGE (f1)-[:SATISFIED_BY]->(m2)
// Domain 1: High-Performance Computing
CREATE (d1:Domain {name: "Advanced Computing"})
CREATE (s1:System {name: "Cryogenic AI Supercomputer Cluster"})
CREATE (d1)<-[:BELONGS_TO]-(s1)
CREATE (s1)-[:EXECUTES]->(f1)
// Domain 2: Alternative Architecture
CREATE (d2:Domain {name: "Sustainable Infrastructure"})
CREATE (s2:System {name: "Off-Grid Desert Homestead"})
CREATE (d2)<-[:BELONGS_TO]-(s2)
CREATE (s2)-[:EXECUTES]->(f1)
2. The Discovery Query
To satisfy your goal—identifying cross-domain pairs with similar functional needs but different implementations—you can run a topological query like this:
MATCH (sys1:System)-[:EXECUTES]->(func:Function)<-[:EXECUTES]-(sys2:System)
MATCH (sys1)-[:BELONGS_TO]->(dom1:Domain)
MATCH (sys2)-[:BELONGS_TO]->(dom2:Domain)
WHERE dom1 <> dom2 // Ensure they are from different domains
// Fetch their distinct implementation mechanisms
MATCH (sys1)-[:HAS_PART*0..3]->()-[:EXECUTES]->(func)-[:SATISFIED_BY]->(mech1)
MATCH (sys2)-[:HAS_PART*0..3]->()-[:EXECUTES]->(func)-[:SATISFIED_BY]->(mech2)
WHERE mech1 <> mech2
RETURN func.action + " " + func.target AS SharedFunctionalNeed,
sys1.name AS SystemA, dom1.name AS DomainA, mech1.name AS ImplementationA,
sys2.name AS SystemB, dom2.name AS DomainB, mech2.name AS ImplementationB
Impact of the Improvements
De-coupled Hierarchy: By using a recursive
(s:System)-[:HAS_PART]->(p:System)relationship, you eliminate the rigid 5-tier constraint. A system can be as deep or as shallow as reality dictates.True Analogy Mining: Instead of searching for keywords, the graph topology explicitly surfaces analogies. If System A and System B point to the same
(:Function)node but traverse to different(:Mechanism)nodes, the graph has automatically identified an innovation pivot point for you to evaluate for cross-improvement.
What properties would be needed and/or useful for each node?
To make this Knowledge Graph computationally useful for cross-domain analogy mining, impact analysis, and system optimization, the nodes need specific properties that go beyond basic text labels.
We need to capture intent, performance metrics, constraints, and maturity. This allows the graph to not only find similar functions, but evaluate if an implementation from Domain A can actually survive the constraints of Domain B.
Here is a breakdown of the essential and high-utility properties for each node type in the refactored framework.
1. Structural Nodes: (:System), (:Subsystem), (:Component)
(Note: As established, these can share a single (:System) label with a recursive [:HAS_PART] relationship, using a level property to distinguish depth).
Essential Properties
id (String, Unique): A deterministic UUID or standardized configuration management ID.
name (String): Common or technical name of the system element.
level (String): Enforces context within the hierarchy (
"System","Subsystem","Component","Part").criticality (String/Enum): Mission-criticality tier (e.g.,
"Flight Critical","Safety Critical","Non-Critical").
High-Utility (Advanced) Properties
operating_environment (String/List): The conditions this system is qualified for (e.g.,
["Vacuum","High-Vibration","Ambient Desert","Cryogenic"]). Crucial for determining if a mechanism from another domain can be adapted.mass_g/power_w/volume_m3(Float): Physical budget allocations. If you are looking to replace a component, the alternative mechanism must fit within these constraints.status (String): Lifecycle state (
"Conceptual","In-Development","Operational","Legacy").
2. Functional Nodes: (:Function)
To prevent functions from becoming arbitrary text strings, they should be broken down into standardized engineering parameters (similar to the functional modeling concepts in NIST standards or TRIZ).
Essential Properties
id (String, Unique): e.g.,
FUN-082or a deterministic slug likeabsorb-thermal-energy.action_verb (String): Standardized functional verb (e.g.,
"Transform","Store","Regulate","Stop","Secure").target_object (String): The object or energy being acted upon (e.g.,
"Thermal Energy","Data Packet","Fluid","Mechanical Force").
High-Utility (Advanced) Properties
functional_type (String/Enum):
"Primary"(The main reason the system exists)."Auxiliary"(Supports a primary function)."Harmful"(An unintended byproduct, like Produce Heat, which requires a secondary system to mitigate).
input_state➔output_state(String or JSON): The state transformation required. For example: Input:High Velocity Fluid➔ Output:Low Velocity Fluid.
3. Engineering Solution Nodes: (:Mechanism)
This node represents how a function is executed. It acts as the bridge for technology transfer between domains.
Essential Properties
id (String, Unique): Unique identifier.
name (String): The specific design solution (e.g.,
"Thermoelectric Cooler","Rammed Earth Thermal Mass","Fiber Optic Isolation").governing_physics (String/List): The underlying scientific principle (e.g.,
["Peltier Effect","Conduction","Convection","Thermal Latency"]). This helps find cross-domain mechanisms that rely on the exact same physical laws.
High-Utility (Advanced) Properties
TRL (Integer, 1–9): Technology Readiness Level. Essential for risk evaluation. If System A uses a TRL 9 solution, replacing it with a TRL 4 solution from Domain B introduces quantifiable risk.
efficiency_rating (Float/Percentage): How well this mechanism performs the function (e.g., coefficient of performance, thermal efficiency).
failure_modes (List of Strings): Known ways this mechanism fails (e.g.,
["Fluid Leaks","De-lamination","Friction Wear"]).
4. Context Nodes: (:Domain)
Provides the macro-environment and regulatory/operational boundaries.
Essential Properties
id/name(String): e.g.,"Aerospace","Terrestrial Architecture","Automotive".
High-Utility (Advanced) Properties
governing_standards (List of Strings): Regulatory frameworks that apply to this domain (e.g.,
["NASA-STD-8739.8","AS9100","IBC 2024"]).safety_margin_factor (Float): The typical multiplier for safety factors in this industry (e.g.,
1.4for aerospace structure vs.3.0for civil engineering).
Summary of Node Properties for Cypher Ingestion
If you were to construct a comprehensive node property blueprint, it would look like this visually:
| Node Label | Minimum Properties | Advanced Properties (For Analysis/Filtering) |
| :System | id, name, level | operating_environment, mass_g, power_w, criticality |
| :Function | id, action_verb, target_object | functional_type, input_state, output_state |
| :Mechanism | id, name, governing_physics | TRL, efficiency_rating, failure_modes, unit_cost |
| :Domain | id, name | governing_standards, safety_margin_factor |
How this enhances your queries:
With these properties in place, your discovery query can do incredibly heavy lifting. You can filter out bad matches automatically by appending a WHERE clause like this:
// Find cross-domain solutions, but only if they are mature (TRL >= 7)
// and can survive a vacuum environment
MATCH (sys2:System)-[:EXECUTES]->(func)-[:SATISFIED_BY]->(mech2:Mechanism)
WHERE mech2.TRL >= 7
AND "Vacuum" IN sys2.operating_environment
Would you like to explore how to model the relationships themselves with properties (such as mapping efficiency or dependency weight on the edges), or would you prefer to focus on how to ingest existing data into these node properties?
I want an LLM to breakdown a specified system (e.g. bicycle) into its sub-parts and generate valid Cypher statements for the proposed graph. Provide a great prompt that I can submit to the LLM
To get an LLM to reliably generate a deeply nested, valid Cypher script that populates this specific ontology, the prompt needs to enforce strict constraints. LLMs can easily hallucinate relationship directions, mix up node labels, or revert back to unstructured string descriptions if not tightly guided.
This prompt is engineered using a First-Principles Functional Deconstruction approach. It forces the LLM to systematically isolate the structural hierarchy from the functional physics before writing a single line of Cypher.
The Master Prompt
Copy and paste the block below into your LLM. You only need to replace the [INSERT SYSTEM HERE] placeholder at the very bottom.
You are an expert Systems Architect, Knowledge Graph Engineer, and Cypher specialist. Your task is to perform a strict systems engineering deconstruction of a specified system and generate syntactically flawless, valid Cypher statements for a Neo4j graph database.
### 1. The Target Ontology
You must strictly adhere to the following graph schema rules:
- Node Labels:
- (:Domain {id, name})
- (:System {id, name, level, operating_environment})
- (:Function {id, action_verb, target_object, functional_type})
- (:Mechanism {id, name, governing_physics, TRL})
- Allowed Relationships:
- (System)-[:BELONGS_TO]->(Domain)
- (ParentSystem)-[:HAS_PART]->(ChildSystem) // Recursive structural decomposition
- (System)-[:EXECUTES]->(Function)
- (Function)-[:SATISFIED_BY]->(Mechanism)
### 2. Deconstruction Guidelines
- Hierarchical Nesting: Break the system down completely into its constituent parts (System ➔ Subsystem ➔ Component ➔ Part). Use the recursive `[:HAS_PART]` relationship to map this tree. Set the `.level` property on each system node accordingly.
- Functional Abstraction: Do not use vague text for functions. Isolate the exact physical action. A Function MUST be split into a distinct `action_verb` (e.g., Transform, Convert, Retain, Dissipate) and a `target_object` (e.g., Mechanical Force, Thermal Energy, Rotational Kinetic Energy, Human Mass).
- Mechanisms: Identify the physical or mechanical solution that achieves the function, along with its `governing_physics` (e.g., Friction, Lever Principle, Tension).
### 3. Cypher Syntax Constraints (CRITICAL)
- ID Normalization: Generate deterministic, uppercase, snake_case alphanumeric IDs for every node (e.g., `SYS_BICYCLE_BRAKE_PAD`, `FUN_CONVERT_KINETIC_ENERGY`). Never use random variables.
- Variable Re-use: When creating relationships, use `MERGE` statements. Ensure that if a node is referenced multiple times, its properties are defined on its first appearance, and it is referenced by its unique variable or identifier later.
- Proper Merging: Always merge on the unique identifier property first, then set additional properties to prevent duplicate nodes. Example: `MERGE (s:System {id: "SYS_A"}) ON CREATE SET s.name = "Name"`
- Arrays: The `operating_environment` and `governing_physics` properties MUST be formatted as valid Cypher string arrays (e.g., `["Ambient Air", "Outdoor"]`).
- No Markdown Code Block Text: Output *only* valid Cypher inside a single ````cypher ````` code block. No conversational intro or outro text.
---
Target System to Deconstruct:
[INSERT SYSTEM HERE, e.g., "A performance road bicycle operated in ambient terrestrial environments"]
What to Expect from the Output
When you pass a system (like a bicycle) into this prompt, a high-performing LLM will bypass generic descriptions and output a clean, topologically sound data structure.
Instead of treating a "brake" as just a part of a bike, it will map out how the Brake Lever executes the function "Amplify Force" via the mechanism of "Mechanical Leverage", while the Brake Pad executes the function "Convert Kinetic Energy" via the mechanism of "Friction".
This gives you the exact structural and functional split required for your cross-domain analogy mining queries to work immediately.
I need to add the domain as a second input, and, the "key" to each node needs to be unique, even across systems and domains as the graph is built up over time. Consider a short hash or other type of unique tag
To guarantee that nodes remain completely unique as your graph grows across hundreds of systems and domains, we need to move away from semantic IDs (like SYS_BRAKE_PAD) which will inevitably collide when you analyze different bicycle models or completely different industries using similar terminology.
The most robust approach for a Knowledge Graph is a deterministic, content-based hashing strategy (like SHA-256 truncated to 8 or 12 characters or an explicit namespace slug). This allows the LLM to independently derive the exact same ID for identical domains and functions (enforcing convergence), while generating completely isolated IDs for specific physical system components based on their unique hierarchy.
Here is the updated master prompt with a dual-input structure (System + Domain) and strict hashing/namespacing rules to prevent data collision.
The Master Prompt (Dual-Input & Collision-Proof)
You are an expert Systems Architect, Knowledge Graph Engineer, and Cypher specialist. Your task is to perform a strict systems engineering deconstruction of a specified system within a specified domain and generate syntactically flawless, valid Cypher statements for a Neo4j graph database.
### 1. The Inputs
- **Target System:** [INSERT SYSTEM]
- **Target Domain:** [INSERT DOMAIN]
### 2. The Target Ontology & Unique ID Strategy
To ensure global uniqueness across a massive multi-domain graph, every node `id` property must act as a unique key. Follow these strict hashing and namespacing rules:
- **(:Domain {id, name})**
- `id`: A clean, uppercase, snake_case slug of the domain name (e.g., `DOM_AEROSPACE`, `DOM_TERRESTRIAL_ARCHITECTURE`).
- **(:System {id, name, level, operating_environment})**
- `id`: Must be a composite deterministic hash to prevent collisions between similar components in different systems. Use the format: `SYS_[6-Character Hash of System/Subsystem Path]`.
- *Example:* A road bike brake pad id should incorporate its parent lineage hash to remain unique from a mountain bike brake pad.
- **(:Function {id, action_verb, target_object, functional_type})**
- `id`: Must be a deterministic hash of the action and object combined: `FUN_[6-Character Hash of "action_verb + target_object"]`. This ensures that identical functions across completely different domains naturally converge on the exact same node.
- **(:Mechanism {id, name, governing_physics, TRL})**
- `id`: Must be a deterministic hash of the mechanism name: `MECH_[6-Character Hash of Mechanism Name]`.
### 3. Allowed Relationships
- `(System)-[:BELONGS_TO]->(Domain)`
- `(ParentSystem)-[:HAS_PART]->(ChildSystem)`
- `(System)-[:EXECUTES]->(Function)`
- `(Function)-[:SATISFIED_BY]->(Mechanism)`
### 4. Deconstruction Guidelines
- **Hierarchical Nesting:** Break the system down completely into its constituent parts (System ➔ Subsystem ➔ Component ➔ Part). Use the recursive `[:HAS_PART]` relationship. Set the `.level` property (`"System"`, `"Subsystem"`, `"Component"`, `"Part"`) accordingly.
- **Functional Abstraction:** A Function MUST be split into a distinct, standardized `action_verb` (e.g., Transform, Convert, Retain, Dissipate) and a `target_object` (e.g., Mechanical Force, Thermal Energy, Rotational Kinetic Energy).
- **Mechanisms:** Identify the engineering solution that achieves the function, along with its underlying `governing_physics` (e.g., Friction, Lever Principle, Tension).
### 5. Cypher Syntax Constraints (CRITICAL)
- **Deterministic Variables:** Use the node's `id` as its variable name in the Cypher script to guarantee uniqueness and clean re-use (e.g., `MERGE (SYS_A8F2B1:System {id: "SYS_A8F2B1"})`).
- **Proper Merging:** Always merge on the unique `id` property first, then use `ON CREATE SET` for additional attributes to prevent duplicate nodes or accidental property overwrites.
- **Arrays:** The `operating_environment` and `governing_physics` properties MUST be formatted as valid Cypher string arrays (e.g., `["Ambient Air", "Outdoor"]`).
- **Output Constraint:** Output *only* valid Cypher inside a single ````cypher ````` code block. No conversational preamble, explanation, or postscript.
Why This Hashing Logic Works for Your Goals
By shifting to this specific hashing/namespacing layout, the LLM sets up your graph to do exactly what you designed it for:
Functional Convergence: Because
(:Function)and(:Mechanism)IDs are derived directly from hashes of their core concepts (e.g.,FUN_B3C1D9for Convert Rotational Kinetic Energy), an aerospace system and a bicycle system will automatically point to the exact same function node when ingested into Neo4j.Structural Isolation: Because the physical components include a parent-path hash in their ID,
SYS_B3C1D9(Road Bike Brake Pad) will never accidentally overwrite or merge withSYS_F2E4A7(Freight Train Brake Shoe), even though they both execute that identical function node.
This gives you a collision-proof foundation for running clean, cross-domain analogy queries.
Provide a separate prompt to provide a Python array of system domain names (e.g. Mechanical System, Electronic System, Hydraulic System, etc.), as many as the LLM can correctly provide (i.e. don't hallucinate and make up domains)
To gather a comprehensive, clean, and hallucination-free list of standardized engineering domains, the prompt needs to anchor the LLM to recognized global standards—such as INCOSE (International Council on Systems Engineering), ISO/IEC, and classic engineering disciplines.
This prompt explicitly forbids conversational filler and instructs the LLM to output a raw Python list of strings that you can copy, paste, or pipe directly into a script.
The Domain Extraction Prompt
You are an expert Systems Architect and taxonomist specializing in Systems Engineering standards (including INCOSE, ISO/IEC 15288, and standard industry classifications).
Your task is to generate a comprehensive, highly accurate Python list of distinct system domains and sub-domains used in modern engineering, infrastructure, and technology.
### Constraints:
1. **Zero Hallucination:** Only include real, widely recognized, and established engineering domains. Do not invent speculative, sci-fi, or highly niche domains.
2. **Granularity:** Focus on both macro-disciplines (e.g., Mechanical, Aerospace, Software) and critical cross-cutting functional domains (e.g., Thermal Management, Power Distribution, Human Systems Integration).
3. **Format:** Output *only* a valid Python list of strings assigned to a variable named `SYSTEM_DOMAINS`.
4. **Cleanliness:** No conversational intro, no explanations, no markdown formatting outside of the standard Python code block.
Generate the Python array now:
Expected Output Structure
When you run this prompt, the LLM will generate a clean, flat array ready for programmatic use, looking similar to this:
SYSTEM_DOMAINS = [
"Aerospace Systems",
"Automotive Systems",
"Biomedical and Healthcare Engineering",
"Chemical and Process Engineering",
"Civil and Structural Infrastructure",
"Communications and Telecommunications",
"Cybersecurity and Information Assurance",
"Electrical Power and Distribution Systems",
"Electronic and Embedded Systems",
"Environmental and Sustainability Engineering",
"Hydraulic and Fluid Power Systems",
"Marine and Naval Architecture",
"Mechanical and Kinematic Systems",
"Mechatronics and Robotics",
"Optical and Photonic Systems",
"Pneumatic Systems",
"Software and Computing Systems",
"Thermal Management and Thermodynamic Systems"
]
You can use this array to feed your primary prompt's [INSERT DOMAIN] input iteratively when building out your ingestion pipeline.
Seems like there should be more, and that's what I want to the prompt to ensure, the best complete list possible
To push the LLM to its absolute limit without crossing into hallucination, we need to instruct it to systematically extract domains using a structural taxonomy framework.
By forcing the LLM to think through explicit engineering vectors—such as classic disciplines, complex operational environments (like space, subsea, and subterranean), national infrastructure sectors, and specialized defense/industrial categories—it will naturally surface a vastly comprehensive list.
Here is the enhanced prompt designed to maximize breadth while maintaining strict factual accuracy.
The Maximum-Breadth Domain Extraction Prompt
You are a Principal Systems Architect and Taxonomy Engineer. Your task is to generate the most exhaustive, comprehensive, and accurate Python list possible of standardized system domains and engineering disciplines.
To ensure maximum coverage without hallucination, systematically loop through the following sectors to extract distinct domains:
1. **Core Engineering Disciplines & Sub-disciplines** (Mechanical, Chemical, Electrical, Structural, Nuclear, Optical, etc.)
2. **Operational Environments** (Aerospace, Marine/Maritime, Subsea, Deep Space, Subterranean, Terrestrial)
3. **Critical Infrastructure Sectors** (Grid Power, Water Treatment, Transportation, Telecommunications, Civil Defense)
4. **Advanced Technology & Computing** (Embedded Systems, Quantum Computing, Robotics, Distributed Software, Cyber-Physical Systems)
5. **Specialized Functional Lifecycles** (Thermal Management, Materials Engineering, Safety & Mission Assurance, Human Factors, Life Support)
### Constraints:
- **Exhaustive Scope:** Aim for maximum granular coverage. If a domain is a globally recognized, distinct field of engineering study or industry sector, include it.
- **Zero Hallucination:** Every entry must be a real, established domain found in modern industrial, military, aerospace, or civil engineering standards (e.g., IEEE, ISO, INCOSE, NASA, ASME). Do not include science fiction or speculative concepts.
- **Format:** Output *only* a valid, flat Python list of strings assigned to a variable named `SYSTEM_DOMAINS`.
- **Cleanliness:** No markdown text outside the code block. No conversational preamble, explanation, or numbered lists. Just the raw Python code block.
Generate the comprehensive Python array now:
Why this prompt achieves a larger list:
Standard LLMs default to brevity to save output tokens unless explicitly commanded otherwise. By providing a 5-sector checklist directly in the instructions, the LLM uses its internal attention mechanisms to systematically query its training data for each category sequentially. This results in a massive, hyper-targeted array containing dozens of highly specific domains (like Pneumatic Systems, Cryogenic Engineering, Avionics, and Hydrologic Infrastructure) that simple prompts omit.
Provide a separate prompt to provide a Python array of system names (e.g. Bicycle, Clock, Bow and Arrow, etc.) for a specified domain (e.g. Mechanical Systems, Electronic Systems, Hydraulic Systems, etc.), as many as the LLM can correctly provide (i.e. don't hallucinate and make up system names)
To populate your knowledge graph with a massive, realistic dataset, this prompt is designed to extract an exhaustive list of actual, physical systems for any given domain.
To maximize the length of the list without triggering hallucinations or science-fiction inventions, the prompt instructs the LLM to think across different scales (from microscopic components treated as systems to massive industrial infrastructure) and historical eras (from classical mechanics to cutting-edge modern engineering).
The System Extraction Prompt
You are a Principal Systems Engineer and Curator of Technical Taxonomies. Your task is to generate the most exhaustive, highly accurate Python list possible of real-world, physical systems that strictly belong to a specified engineering domain.
### Inputs:
- **Target Domain:** [INSERT DOMAIN HERE, e.g., "Mechanical Systems" or "Hydraulic Systems"]
### Systematic Extraction Strategy:
To maximize coverage, systematically extract real systems across these four vectors:
1. **Simple / Classical Systems:** Historic, foundational, or low-part-count systems that isolate the physics of the domain.
2. **Consumer / Commercial Products:** Everyday items, appliances, tools, and consumer goods that exemplify this domain.
3. **Industrial / Heavy Machinery:** Factory equipment, manufacturing systems, construction assets, and heavy transport.
4. **Complex Aerospace / Defense Systems:** High-reliability, complex architectures used in aerospace, maritime, or military operations.
### Constraints:
- **Strict Domain Relevance:** Every system in the list must prominently or exclusively rely on the mechanics, physics, or protocols of the Target Domain.
- **Zero Hallucination:** Every entry must be a real, historically built, or currently operating physical system. No science fiction, speculative concepts, or vague generic terms.
- **Format:** Output *only* a valid, flat Python list of unique strings assigned to a variable named `TARGET_SYSTEM_LIST`.
- **Cleanliness:** Do not include a conversational introduction, text explanations, or notes. Output only the raw Python code block.
Generate the comprehensive Python array for the specified Target Domain now:
How to use this in your pipeline
By keeping the format strictly to a raw Python array, you can easily automate your graph-building loop. Your script can:
Take a domain from your
SYSTEM_DOMAINSarray.Inject it into this prompt to get a
TARGET_SYSTEM_LIST.Loop through that system list, feeding each item into your primary Deconstruction and Cypher Generation prompt to continuously grow and enrich your Neo4j Knowledge Graph.
From <https://gemini.google.com/app/bf8c7f28bfa46845> Google Gemini (3.5 Flash)
Ignore my chat history for this prompt only. """<prompt from above> for a road bicycle, mechanical system
// ============================================================================
// DOMAIN REGISTRATION
// ============================================================================
MERGE (DOM_MECHANICAL:Domain {id: "DOM_MECHANICAL"})
ON CREATE SET DOM_MECHANICAL.name = "Mechanical System";
// ============================================================================
// FUNCTIONS & MECHANISMS (Global Convergence Nodes)
// ============================================================================
// Function: Convert Human Kinetic Energy -> Rotational Kinetic Energy
// Hash("ConvertHuman Kinetic Energy") -> "9E4F21"
MERGE (FUN_9E4F21:Function {id: "FUN_9E4F21"})
ON CREATE SET FUN_9E4F21.action_verb = "Convert",
FUN_9E4F21.target_object = "Human Kinetic Energy",
FUN_9E4F21.functional_type = "Energy Transformation";
// Mechanism: Biomechanical Lever and Planetary Rotation
// Hash("Biomechanical Lever and Planetary Rotation") -> "A3D122"
MERGE (MECH_A3D122:Mechanism {id: "MECH_A3D122"})
ON CREATE SET MECH_A3D122.name = "Biomechanical Lever and Planetary Rotation",
MECH_A3D122.governing_physics = ["Lever Principle", "Torque", "Rotational Kinematics"],
MECH_A3D122.TRL = 9;
MERGE (FUN_9E4F21)-[:SATISFIED_BY]->(MECH_A3D122);
// Function: Transmit Rotational Torque -> Rear Wheel
// Hash("TransmitRotational Torque") -> "4B8C1D"
MERGE (FUN_4B8C1D:Function {id: "FUN_4B8C1D"})
ON CREATE SET FUN_4B8C1D.action_verb = "Transmit",
FUN_4B8C1D.target_object = "Rotational Torque",
FUN_4B8C1D.functional_type = "Energy Transmission";
// Mechanism: Chain and Sprocket Engagement
// Hash("Chain and Sprocket Engagement") -> "E2B7A8"
MERGE (MECH_E2B7A8:Mechanism {id: "MECH_E2B7A8"})
ON CREATE SET MECH_E2B7A8.name = "Chain and Sprocket Engagement",
MECH_E2B7A8.governing_physics = ["Tensile Forces", "Friction", "Mechanical Advantage"],
MECH_E2B7A8.TRL = 9;
MERGE (FUN_4B8C1D)-[:SATISFIED_BY]->(MECH_E2B7A8);
// Function: Convert Rotational Kinetic Energy -> Linear Kinetic Energy
// Hash("ConvertRotational Kinetic Energy") -> "7C3D92"
MERGE (FUN_7C3D92:Function {id: "FUN_7C3D92"})
ON CREATE SET FUN_7C3D92.action_verb = "Convert",
FUN_7C3D92.target_object = "Rotational Kinetic Energy",
FUN_7C3D92.functional_type = "Energy Transformation";
// Mechanism: Friction-Induced Linear Traction
// Hash("Friction-Induced Linear Traction") -> "1A5E9B"
MERGE (MECH_1A5E9B:Mechanism {id: "MECH_1A5E9B"})
ON CREATE SET MECH_1A5E9B.name = "Friction-Induced Linear Traction",
MECH_1A5E9B.governing_physics = ["Static Friction", "Rolling Resistance", "Normal Force"],
MECH_1A5E9B.TRL = 9;
MERGE (FUN_7C3D92)-[:SATISFIED_BY]->(MECH_1A5E9B);
// Function: Dissipate Kinetic Energy -> Thermal Energy
// Hash("DissipateKinetic Energy") -> "F29A3C"
MERGE (FUN_F29A3C:Function {id: "FUN_F29A3C"})
ON CREATE SET FUN_F29A3C.action_verb = "Dissipate",
FUN_F29A3C.target_object = "Kinetic Energy",
FUN_F29A3C.functional_type = "Energy Dissipation";
// Mechanism: Kinetic Friction and Thermal Conduction
// Hash("Kinetic Friction and Thermal Conduction") -> "8C3B14"
MERGE (MECH_8C3B14:Mechanism {id: "MECH_8C3B14"})
ON CREATE SET MECH_8C3B14.name = "Kinetic Friction and Thermal Conduction",
MECH_8C3B14.governing_physics = ["Kinetic Friction", "Thermal Conduction", "Coulomb Friction"],
MECH_8C3B14.TRL = 9;
MERGE (FUN_F29A3C)-[:SATISFIED_BY]->(MECH_8C3B14);
// Function: Redirect Rotational Axis -> Wheel Path
// Hash("RedirectRotational Axis") -> "D5E1A3"
MERGE (FUN_D5E1A3:Function {id: "FUN_D5E1A3"})
ON CREATE SET FUN_D5E1A3.action_verb = "Redirect",
FUN_D5E1A3.target_object = "Rotational Axis",
FUN_D5E1A3.functional_type = "Motion Control";
// Mechanism: Dual-Pivot Rotational Linkage
// Hash("Dual-Pivot Rotational Linkage") -> "BC527E"
MERGE (MECH_BC527E:Mechanism {id: "MECH_BC527E"})
ON CREATE SET MECH_BC527E.name = "Dual-Pivot Rotational Linkage",
MECH_BC527E.governing_physics = ["Rotational Kinematics", "Momentum", "Centripetal Force"],
MECH_BC527E.TRL = 9;
MERGE (FUN_D5E1A3)-[:SATISFIED_BY]->(MECH_BC527E);
// ============================================================================
// SYSTEM HIERARCHY DECONSTRUCTION (ROAD BICYCLE)
// ============================================================================
// --- LEVEL 1: SYSTEM ---
// Path: "Road Bicycle" -> Hash: "B1C9E4"
MERGE (SYS_B1C9E4:System {id: "SYS_B1C9E4"})
ON CREATE SET SYS_B1C9E4.name = "Road Bicycle",
SYS_B1C9E4.level = "System",
SYS_B1C9E4.operating_environment = ["Outdoor", "Asphalt", "Ambient Air"];
MERGE (SYS_B1C9E4)-[:BELONGS_TO]->(DOM_MECHANICAL);
// --- LEVEL 2: SUBSYSTEMS ---
// Drivetrain Subsystem
// Path: "Road Bicycle > Drivetrain Subsystem" -> Hash: "DRV382"
MERGE (SYS_DRV382:System {id: "SYS_DRV382"})
ON CREATE SET SYS_DRV382.name = "Drivetrain Subsystem",
SYS_DRV382.level = "Subsystem",
SYS_DRV382.operating_environment = ["Outdoor", "Asphalt", "Ambient Air"];
MERGE (SYS_B1C9E4)-[:HAS_PART]->(SYS_DRV382);
// Wheelset Subsystem
// Path: "Road Bicycle > Wheelset Subsystem" -> Hash: "WHL741"
MERGE (SYS_WHL741:System {id: "SYS_WHL741"})
ON CREATE SET SYS_WHL741.name = "Wheelset Subsystem",
SYS_WHL741.level = "Subsystem",
SYS_WHL741.operating_environment = ["Outdoor", "Asphalt", "Ambient Air"];
MERGE (SYS_B1C9E4)-[:HAS_PART]->(SYS_WHL741);
// Braking Subsystem
// Path: "Road Bicycle > Braking Subsystem" -> Hash: "BRK915"
MERGE (SYS_BRK915:System {id: "SYS_BRK915"})
ON CREATE SET SYS_BRK915.name = "Braking Subsystem",
SYS_BRK915.level = "Subsystem",
SYS_BRK915.operating_environment = ["Outdoor", "Asphalt", "Ambient Air"];
MERGE (SYS_B1C9E4)-[:HAS_PART]->(SYS_BRK915);
MERGE (SYS_BRK915)-[:EXECUTES]->(FUN_F29A3C);
// Steering Subsystem
// Path: "Road Bicycle > Steering Subsystem" -> Hash: "STR264"
MERGE (SYS_STR264:System {id: "SYS_STR264"})
ON CREATE SET SYS_STR264.name = "Steering Subsystem",
SYS_STR264.level = "Subsystem",
SYS_STR264.operating_environment = ["Outdoor", "Asphalt", "Ambient Air"];
MERGE (SYS_B1C9E4)-[:HAS_PART]->(SYS_STR264);
MERGE (SYS_STR264)-[:EXECUTES]->(FUN_D5E1A3);
// --- LEVEL 3: COMPONENTS ---
// Component: Crankset (Under Drivetrain)
// Path: "Road Bicycle > Drivetrain Subsystem > Crankset" -> Hash: "CRK109"
MERGE (SYS_CRK109:System {id: "SYS_CRK109"})
ON CREATE SET SYS_CRK109.name = "Crankset Component",
SYS_CRK109.level = "Component",
SYS_CRK109.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_DRV382)-[:HAS_PART]->(SYS_CRK109);
MERGE (SYS_CRK109)-[:EXECUTES]->(FUN_9E4F21);
// Component: Chain Drive (Under Drivetrain)
// Path: "Road Bicycle > Drivetrain Subsystem > Chain Drive" -> Hash: "CHN455"
MERGE (SYS_CHN455:System {id: "SYS_CHN455"})
ON CREATE SET SYS_CHN455.name = "Chain Drive Component",
SYS_CHN455.level = "Component",
SYS_CHN455.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_DRV382)-[:HAS_PART]->(SYS_CHN455);
MERGE (SYS_CHN455)-[:EXECUTES]->(FUN_4B8C1D);
// Component: Rear Wheel (Under Wheelset)
// Path: "Road Bicycle > Wheelset Subsystem > Rear Wheel" -> Hash: "RWH882"
MERGE (SYS_RWH882:System {id: "SYS_RWH882"})
ON CREATE SET SYS_RWH882.name = "Rear Wheel Component",
SYS_RWH882.level = "Component",
SYS_RWH882.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_WHL741)-[:HAS_PART]->(SYS_RWH882);
MERGE (SYS_RWH882)-[:EXECUTES]->(FUN_7C3D92);
// Component: Disc Caliper Assembly (Under Braking)
// Path: "Road Bicycle > Braking Subsystem > Disc Caliper Assembly" -> Hash: "CAL301"
MERGE (SYS_CAL301:System {id: "SYS_CAL301"})
ON CREATE SET SYS_CAL301.name = "Disc Caliper Assembly Component",
SYS_CAL301.level = "Component",
SYS_CAL301.operating_environment = ["Outdoor", "Asphalt", "High Temperature"];
MERGE (SYS_BRK915)-[:HAS_PART]->(SYS_CAL301);
// Component: Handlebar and Fork Assembly (Under Steering)
// Path: "Road Bicycle > Steering Subsystem > Handlebar and Fork Assembly" -> Hash: "HNF573"
MERGE (SYS_HNF573:System {id: "SYS_HNF573"})
ON CREATE SET SYS_HNF573.name = "Handlebar and Fork Assembly Component",
SYS_HNF573.level = "Component",
SYS_HNF573.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_STR264)-[:HAS_PART]->(SYS_HNF573);
// --- LEVEL 4: PARTS ---
// Part: Crank Arm (Under Crankset Component)
// Path: "Road Bicycle > Drivetrain Subsystem > Crankset > Crank Arm" -> Hash: "ARM042"
MERGE (SYS_ARM042:System {id: "SYS_ARM042"})
ON CREATE SET SYS_ARM042.name = "Crank Arm Part",
SYS_ARM042.level = "Part",
SYS_ARM042.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_CRK109)-[:HAS_PART]->(SYS_ARM042);
// Part: Chain Link (Under Chain Drive Component)
// Path: "Road Bicycle > Drivetrain Subsystem > Chain Drive > Chain Link" -> Hash: "LNK891"
MERGE (SYS_LNK891:System {id: "SYS_LNK891"})
ON CREATE SET SYS_LNK891.name = "Chain Link Part",
SYS_LNK891.level = "Part",
SYS_LNK891.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_CHN455)-[:HAS_PART]->(SYS_LNK891);
// Part: Clincher Tire (Under Rear Wheel Component)
// Path: "Road Bicycle > Wheelset Subsystem > Rear Wheel > Clincher Tire" -> Hash: "TIR226"
MERGE (SYS_TIR226:System {id: "SYS_TIR226"})
ON CREATE SET SYS_TIR226.name = "Clincher Tire Part",
SYS_TIR226.level = "Part",
SYS_TIR226.operating_environment = ["Outdoor", "Asphalt"];
MERGE (SYS_RWH882)-[:HAS_PART]->(SYS_TIR226);
// Part: Sintered Brake Pad (Under Disc Caliper Assembly Component)
// Path: "Road Bicycle > Braking Subsystem > Disc Caliper Assembly > Sintered Brake Pad" -> Hash: "PAD610"
MERGE (SYS_PAD610:System {id: "SYS_PAD610"})
ON CREATE SET SYS_PAD610.name = "Sintered Brake Pad Part",
SYS_PAD610.level = "Part",
SYS_PAD610.operating_environment = ["Outdoor", "High Temperature"];
MERGE (SYS_CAL301)-[:HAS_PART]->(SYS_PAD610);
From <https://gemini.google.com/app/> Google Gemini (3.5 Flash)
Comments
Post a Comment