I wanted to build an AI project related to hardware engineering and use it to learn Neo4j.

But once we started discussing how to store components and split them into nodes, I lost track of the original question. What were we building? Did LM5155 come from a bill of materials? Why did we need Neo4j?

I needed to understand the purpose before the data model. This article follows that discussion through one component example, without installation steps or code.

The project is an AI assistant for component replacement reviews. When an engineer wants to replace a part, they need to organize requirements, read candidate specifications, and compare the differences. I want AI to help with that work while preserving enough evidence for someone to check the result.

Our current example comes from a public TI forum replacement request. The original part was LT8301ESS, the requirements included a 14–30 V input, and a reply mentioned LM5155. We have not imported a real BOM. LM5155 is a candidate we are investigating, not a replacement we have qualified.

A decision needs evidence and a rule. An unknown needs a reason, a next action, and a clear definition of what would resolve it.

If the system says a requirement is met, it should explain which evidence and rule support that answer. If it cannot decide, it should explain what is missing. That tells us what to ask for next and how to check whether the new information actually answers the question.

This is the design we are working toward. It does not mean every follow-up and review step is already implemented.

1. What do we want to ask before we draw any nodes?

If all we need to remember is the name LM5155, a line of text would do. So where does a graph database help?

I started with the questions we want to answer after saving the data:

  • What does this case require?
  • Why is LM5155 a candidate?
  • Under which conditions does a specification apply?
  • Which document supports that specification?
  • If a source needs to be checked again, which cases might need another look?

Those questions suggest an initial path:

Case → candidate component → conditional specification → document revision

Now there is a reason to connect the data. We want to find the information behind those questions. The next step is checking whether each connection means what we think it means.

2. Why should a component be a node?

We may want to find LM5155, inspect its specifications, or see which cases considered it. That gives it a reason to exist as a separate node.

But what do we mean by a component? A model, a complete orderable part number, and a particular physical part on a board are different things.

Here, we are working at the model level. Similar names do not justify merging different models or ordering suffixes. The wiring of one instance on one board should not become a permanent property of every component with that model name.

Before drawing the first node, I need to know what it represents. The same distinction appears outside electronics: a book, an edition, and one physical library copy can each need their own identity.

3. Why not put “maximum voltage: 45 V” on LM5155?

My next question was straightforward: if we already have a component node, why not put its voltage limit there?

Because “maximum voltage: 45 V” leaves too much out. Which pin does it describe? What kind of rating is it? Under which conditions may we use that number?

Our saved LM5155 specification draft contains two recommended BIAS operating ranges:

  • With the internal VCC regulator: 3.5–45 V.
  • With VCC connected directly to BIAS: 2.97–16 V.

The draft also records a junction-temperature range of −40 to 125°C, along with the source page, section, and footnote. These entries were organized from TI's LM5155 datasheet, SNVSB75E, Rev E, page 6, section 8.3. They remain pending human review in our project; they do not approve an actual circuit.

If we keep only “maximum voltage: 45 V,” the difference between those wiring conditions disappears. The system might see a 30 V requirement and say it fits, even though we have not established which specification applies.

That is why we gave the specification its own node. One specification node represents a particular property of a component, under stated conditions, as recorded by a source. It is not the entire datasheet.

A component can connect to several such nodes. Recommended operating conditions and absolute maximum ratings also need to remain distinct, even when both are expressed in volts.

4. Should every number and condition become a node too?

If a specification gets a node, should 45, V, temperature, and wiring each get one?

Not necessarily. Breaking the data into smaller pieces does not automatically improve the design.

For this version, we need to track the specification independently. Its numeric range, unit, wiring condition, and temperature describe it, so they can remain properties.

My starting distinction is:

  • Use a property when a value describes an object, such as the upper limit of this specification.
  • Consider a node when something needs its own identity, references, provenance, or version history.

That choice can change. If we later manage reusable wiring configurations with their own versions and evidence, a configuration may deserve a separate node.

Seeing a noun in the source text is not enough. I want to know whether we will need to find it independently, refer to it from other records, or track its changes.

Neo4j's modeling guidance includes intermediary nodes for modeling context that deserves its own representation. Making specifications separate nodes is our choice for retaining conditions and provenance, not a mandatory schema for every project.

5. What does the relationship actually say?

Once the case, component, specification, and document exist, we still have to decide what their connections mean.

Compare these statements:

  • This case considers LM5155.
  • LM5155 can replace LT8301ESS.

The first records a candidate. The second makes an engineering judgment. They require very different evidence.

At this stage, the graph can say that a case has a requirement, considers LM5155, and references specifications extracted from a document revision. It should not say that the replacement is approved.

I want to be able to read each relationship as a sentence and ask what evidence supports that sentence. Saving it in Neo4j does not make it true.

6. Why keep requirements separate from components?

The 14–30 V range belongs to the request. It is not a specification of LM5155.

If we attach the requirement directly to the component, another case with a different input range becomes confusing. The component is being evaluated; the requirement belongs to the case doing the evaluation.

We need to keep three things distinct: what the requester needs, what the document says the component supports under particular conditions, and what the actual design does.

In particular, a board input voltage is not automatically the voltage at the candidate's BIAS pin. Both being expressed in volts does not make them interchangeable. We need design information to establish that connection.

The same applies to wiring conditions. A datasheet describing a range for one configuration does not establish that our circuit uses that configuration.

So what is missing? We have specifications, but we do not yet know which one applies to this circuit. That is a gap worth recording.

A gap does not always need its own node. A property may be enough to mark one field as unknown. A separate node becomes useful when we need to track which check is blocked, what someone should do next, and what evidence would resolve it.

For the unconfirmed BIAS/VCC wiring, I would want to preserve four answers:

  • Why is it unknown? We do not have evidence of the actual wiring and pin-voltage range, so we cannot select the applicable specification.
  • Which judgment is blocked? Whether this design's BIAS voltage range fits the corresponding recommended operating range.
  • What should happen next? Ask the engineer for circuit information establishing the VCC/BIAS connection and BIAS voltage range.
  • What counts as resolving it? Retain traceable design information, have the engineer confirm the wiring, voltage range, and other applicable conditions, and complete review of the cited specification before rerunning the check.

The reason for an unknown should lead to a specific follow-up. A missing field is not an invitation for the model to invent a value. Receiving an attachment is not enough either; we have to establish that it answers the original question.

Resolving the gap allows this check to proceed. It does not guarantee that the check will pass, and passing this check would not approve the whole replacement.

7. Why do documents need revisions and cases need snapshots?

What happens two months later when the document or extracted data changes?

If we overwrite the old specification, an older case may start showing information it never used. A source link would still exist, but it would no longer explain the original assessment.

When reopening a case, we need to know which document content was referenced, which extraction version was used, and which requirements and evidence belonged to that assessment.

A URL alone is insufficient because it may serve a newer file later. Revision labels and content fingerprints help distinguish saved content. A fingerprint can identify a change; it cannot prove that the content is correct.

A case snapshot is essentially a record of what the case used at that time. New evidence can produce a new snapshot without silently changing the old one.

This also explains why relationships sometimes need properties. If the LM5155 node connects to several batches of specifications, the relationship between a case and its candidate can record which batch that case used. That choice belongs to the case-component relationship, rather than to LM5155 permanently.

A reachable specification is not necessarily an applicable one. Queries must preserve the case's evidence scope.

8. What can we actually do with this graph?

We can follow the relationships in different directions. Starting from a case, we can find its candidate, specifications, and sources. Starting from a document, we can find specifications drawn from it and cases that may need another look.

“May” matters here. A case might have considered a candidate without selecting it. A document update might leave the relevant facts unchanged.

If we later want to track exactly which evidence a formal decision used, we will also need to store that decision and its evidence links. A candidate relationship cannot stand in for that missing history.

Neo4j helps us retrieve the relationships and supporting information. Whether new information changes an answer still requires the relevant checks and, where needed, an engineer's judgment.

A relational database can model these relationships too. For one case, a few specifications, and one range comparison, JSON or a table may be simpler. We chose Neo4j to learn how to make cross-object relationships central to retrieval. We have not established that using a graph makes this project faster or more accurate.

What I want to learn from this

I do not want to memorize a schema for LM5155 and then be stuck again when the component or project changes.

These are the questions I want to carry forward:

  1. What do I want the data to answer?
  2. Which objects need independent identities?
  3. Which values simply describe those objects?
  4. What evidence supports each relationship?
  5. After an update, can I reconstruct the evidence a case used?

Those answers give the nodes, relationships, and properties a reason to exist.

That is what I want to practice through this project: understanding why each piece of information is retained, what it lets us answer now, and what we should do next when an answer is still out of reach.