Bloomspec: Breaking Things Down, Connecting Them Back — Why Not a Graph?

I have always had a fairly structured way of learning a new domain or system.

I normally start by classifying things—areas, then L1, L2, L3, L4, followed by capabilities, functions, operations and supporting details. It is almost relational-database thinking applied to learning, and it has worked well for me for years.

But while working through a few newer solution areas, I started wondering: why should all of this be hierarchical in the first place?

A capability can relate to several operations. An operation can touch multiple business entities. The same technical need may appear across completely different domains. Constraints, automation approaches, products and agents can cut across all of them.

A graph started feeling much more natural.

I had actually come up with the name Bloomspec roughly six months earlier, while exploring several related ideas. Only after the project had moved to Neo4j did I notice that its cloud interface has the usual Query option—and another called Bloom, which opens its visual graph exploration UI.

I genuinely had no idea about that when I chose the name. Seeing Bloom sitting there just when Bloomspec had become a graph made me strangely happy. A tiny coincidence, but I liked it. :)

From breaking down to connecting

Bloomspec started as an experiment around that simple question.

There is still an understandable backbone:

Area → Solution Area → Capability → Operation

But an Operation can then connect outward to the entities it acts on, technical needs, methods, constraints, automation opportunities, techniques, agents, products and other concepts.

Instead of deciding that everything must sit somewhere inside one tree, I can look at the same problem from different directions and follow the relationships that matter.

That changed what the graph meant to me.

It was becoming a way to learn a system, rather than simply a place to store what I had already learned.

How much should the graph know?

The next question came quickly: once you start creating nodes and relationships, where do you stop?

I don’t want Bloomspec to become an ontology for its own sake. The working idea is to capture enough of the business, system and technical reality to make it useful as an evolving model for understanding and solution exploration.

That is why newer concepts such as AI opportunities, automation techniques and agents sit alongside more fundamental things such as technical needs, methods and constraints.

The AI layer matters, but it does not replace the systems thinking underneath it. An operation should not suddenly get an agent just because agents are interesting. The work, technical need and constraints have to make sense first.

As the model grew, I also started seeing several connected clusters: a business/domain side, a technical side, an automation and AI side, and a market layer where actual products and modules can map back to the underlying work.

The interesting part is what starts becoming visible when those different views meet.

What is in the graph today

I have been working through five substantially authored Areas so far:

• Financial Close & Consolidation
• Employee Knowledge & Action
• Workload Automation
• Commercial & Specialty P&C Underwriting
• Life Insurance Underwriting

There wasn’t a grand selection strategy behind these. I picked a few areas I was personally interested in, and a few came from things friends and collaborators wanted to understand or explore. The mix has actually been useful because the Areas challenge the model in quite different ways.

The current graph has about 2,660 nodes, 16,294 relationships, 24 node types and 21 relationship types.

One design pattern I particularly like is that much of the business structure remains local to an Area, while technical needs, methods, constraints and automation techniques are much more reusable across Areas.

So the graph is not trying to force every domain into one universal hierarchy. Different domain bodies can meet through a more shared technical and automation spine.

There are already more Areas represented at a lighter level, but the overall system is still very much being built.

Why not just ask an LLM?

This is probably the most obvious question.

And yes, I can ask an LLM to explain almost any of these domains.

But I have a particular way I want to learn. I want to see the structure, the relationships and different paths through the same problem. I also want that understanding to persist and evolve rather than beginning again from a blank prompt every time.

So one reason for Bloomspec is quite personal:

I want LLMs to work with a model shaped around how I want to understand a system.

There is another part I only began appreciating after some of the graph existed.

The connections themselves start creating new questions.

For example, while looking at Automation Opportunities I started wondering whether they could connect to current, specific research—not broad AI white papers, but deeper research relevant to the actual technique or problem involved.

That wasn’t something I began Bloomspec intending to build. I noticed the possibility because the graph was sitting in front of me.

A new Area challenges a relationship. A connection exposes something missing. One cluster suggests another kind of knowledge worth attaching.

The graph is slowly becoming part of the thinking process itself.

Building while thinking

Coding agents have made this kind of experiment much more practical for me.

I can change the model, test it against another domain, question whether a node or relationship really belongs where I put it, regenerate the graph and keep moving without making every conceptual experiment a large engineering exercise.

AI therefore appears in Bloomspec in two different ways: inside the graph, through automation opportunities, techniques and agents; and outside it, through coding agents helping me evolve the system itself.

Tech & engineering snapshot

Area	What I’m using
Graph	Neo4j Aura
Model	Explicit node and relationship contracts with authored YAML/corpus
Knowledge handoff	Generated graph briefs plus complete node/relationship TSVs
Development	Coding-agent-assisted implementation and iteration

One related experiment is generating compact representations of the live graph specifically for humans and LLMs. The larger authoring corpus contains much more provenance and repetition; the generated handoff exposes the graph as it actually exists, with one graph fact per line where useful for retrieval.

That is beginning to raise another question for me: not only how should the knowledge be modelled?, but how should an LLM be given that knowledge so it can work with it reliably?

Where it is heading

For now, the objective is modest: make Bloomspec genuinely useful for me and for a few others who like learning complex systems this way.

I can already see directions around deeper domain exploration, solution design, research connections, richer product mapping, system specifications and better ways for LLMs to navigate the graph.

But I don’t want to decide all of those too early.

This is still an experiment, and that is partly the point.

Bloomspec is in progress. More interestingly, I am still finding out what the graph makes me want to explore next.