Overview of this Site

This site represents work I have been pursuing since 2004 with one central question:

How can Business Intelligence progress from simply presenting and reporting values to becoming a system that:

  1. Notices what is happening.
  2. Remembers what has been observed.
  3. Connects events and conditions across the enterprise.
  4. Reasons about what they may mean.
  5. Helps people decide what to do next?

This succinct timeline of chosen milestones demonstrates that this is a coherent and long-running R&D effort:

Enterprise Intelligence, Time Molecules, and The Assemblage of Artificial Intelligence form the conceptual trilogy. Semantic Webs of Meaning is a semantic prequel and companion, developing the explicit meaning layer upon which the other systems increasingly depend.

Where to start if you’re completely new to my work:

My book, Enterprise Intelligence, is the best starting point. It organizes much of the work I had developed before ChatGPT’s public arrival in November 2022, while showing how LLMs make more of that architecture feasible. It remains the foundation for most of my subsequent work.

This is really the end of the “overview”. The rest is origin story and why I’m doing this.

How I Got Onto this Path

When I joined the SQL Server OLAP Services team in 1998, I had never heard the terms OLAP or Business Intelligence. I assumed that the “I” in BI meant the same sort of active intelligence as the “I” in AI. It finally sank in years later that the “I” in BI was primarily about integrating, aggregating, querying, and presenting data. Those capabilities are essential, but I kept expecting the systems we built to do more with all that carefully assembled information.

A dashboard could tell us that a KPI had entered pain. It usually could not tell us what else had changed, whether the presumed relationships behind the KPI still held, which earlier events had led to the current condition, or whether someone elsewhere in the enterprise had observed something related. Those pieces were scattered among databases, cubes, formulas, process diagrams, application logs, documents, and the heads of people working in different domains.

It seemed to me that we had built an extraordinarily capable sensory and memory system that stopped just as thinking should begin.

That problem became concrete for me in 2004, when I began building an “AI” SQL Server performance-tuning engineer. SQL Server events and performance logs were its senses. Prolog-style rules supplied deductive reasoning. I wrote SCL—Soft-Coded Logic—to separate logic from application procedure and to support rules assembled from multiple sources. Machine-learning models and database metadata could contribute automatically generated rules alongside manually authored expert knowledge.

The KPI Cause and Effect Graph followed from the same concern. Performance-management systems contained goals, KPI statuses, formulas, and presumed cause-and-effect relationships. I wanted the system to expose and test those relationships instead of treating each KPI as an isolated number on a dashboard. That eventually led to the Effect Correlation Score, Map Rock, the Insight Space Graph, the Tuple Correlation Web, and the other structures described throughout this site.

The underlying reason for all of this was that a business does not operate as a collection of isolated values. It operates through interacting processes unfolding over time. Conditions change, assumptions expire, actions transfer costs to other parts of the system, and people working in separate domains see different fragments of the same developing situation. A more intelligent form of BI would help the enterprise accumulate those fragments instead of repeatedly losing them.

The technology available then was not ready to support that vision at enterprise scale. Graph technologies and Semantic Web standards were immature or difficult to deploy. Natural-language processing was too brittle to interpret the many ways people, documents, formulas, and software expressed the same idea. Compute and storage were expensive. Enterprise metadata was thin and inconsistent. Creating and maintaining the necessary relationships and rules required far too much manual labor.

The ideas could be explored through prototypes, diagrams, and individual applications, but the complete system remained beyond practical reach.

Why the Time Is Now

The missing pieces did not arrive in one miraculous piece. They accumulated over two decades.

Modern data platforms can retain enormous histories of transactions and events. Semantic layers can provide governed measures, dimensions, and relationships across many sources. Pre-aggregated OLAP can support the volume and concurrency required when analysts, applications, and AI agents all become consumers of enterprise data. Event streaming, IoT devices, application telemetry, and AI-agent workflows are producing a rapidly expanding record of what happens through time.

Knowledge graphs and Semantic Web standards now provide practical ways to represent identity, meaning, context, and explicit relationships across domains. Machine learning can discover patterns and generate models from data. Prolog and related rule systems can execute deterministic reasoning that remains inspectable and testable.

LLMs removed another major barrier. They can translate among natural language, database schemas, formulas, RDF, Prolog, Python, and other representations. They can help author and connect the artifacts that were once prohibitively labor-intensive to create. They are not the whole of intelligence, but they are remarkably capable connective tissue among its components.

At the same time, the need has become more urgent. Analysts throughout an enterprise continually produce dataframes, visualizations, and small observations while resolving their immediate problems. Most of that analytical attention disappears when the session ends. The Insight Function Array can capture simple observations from that ordinary work. The Insight Space Graph can remember them with their query context. The Tuple Correlation Web can discover relationships among the corresponding tuples. Time Molecules can examine the sequences, delays, branches, and processes through which conditions develop. An Enterprise Knowledge Graph can connect those observations to shared meaning. LLMs, Prolog, machine learning, and human analysts can then reason over the accumulated evidence.

AI agents make this foundation even more important. They will greatly increase the number of queries, decisions, interactions, and events produced inside an enterprise. Without governed meaning, persistent memory, and awareness of processes through time, they can multiply fragmentation and ambiguity at machine speed.

This is therefore the right time for the work—not because every component is finished or because AGI has arrived, but because the components have become capable enough to assemble. BI provides the data foundation. Enterprise Intelligence supplies the observation and relationship structures. Time Molecules supplies processes and interactions through time. Semantic Webs of Meaning supplies explicit meaning and deduction. The Assemblage of Artificial Intelligence considers how these and other components can work together.

A Blueprint, Not a Packaged Product

I need to be clear. This body of work is a blueprint, not a finished software product. It is not presented as a ready-to-deploy alternative to a commercial platform such as Palantir. The sample databases, code, knowledge graphs, Prolog, Insight Function Array, and Time Molecules implementations make parts of the architecture concrete, but they do not collectively form a turnkey Enterprise Intelligence platform.

That distinction is more than a disclaimer about the maturity of the software. It reflects something fundamental about enterprise intelligence.

A product can provide storage, processing, security, orchestration, graph technology, machine learning, visualization, and interfaces to LLMs. It cannot arrive already knowing what an enterprise means by customer, risk, success, pain, or opportunity. It cannot already know which events mark the beginning and end of an important process, which measures should be related, which apparent improvements merely transfer costs elsewhere, which assumptions should be tested, or which observations matter enough to remember.

Those are not peripheral configuration details around the intelligence. They constitute much of the intelligence itself.

I am not suggesting that every enterprise should write its own database engine, graph database, BI visualization tool, or LLM. Commercial and open-source platforms should provide those broadly applicable capabilities. For example, Palantir might be one environment in which portions of this blueprint could be implemented. Kyvos, cloud data platforms, event-streaming systems, knowledge-graph products, Prolog engines, and other technologies could supply different parts.

However, an enterprise should retain ownership of the business-specific layer constructed with those products: its semantic models, KPI logic, event definitions, process models, ontologies, insight functions, correlations, rules, strategies, and accumulated observations. That layer expresses how the enterprise believes it works, what it has learned, and how it distinguishes one situation from another.

If competitors can purchase the same platform and apply the same standard implementation, the platform alone cannot provide a lasting competitive advantage. The greater opportunity lies in how an enterprise assembles the components, what it teaches the system to notice, which relationships it develops, how quickly it recognizes changes, and how effectively it turns those observations into decisions.

Building this layer is also a means of discovering the enterprise. Defining an ontology forces people to confront what their terms actually mean. Modeling events and processes exposes what really happens rather than what a procedure manual says should happen. Connecting KPIs reveals competing goals and transfers of cost. Preserving analysts’ observations allows lessons found in one domain to contribute to problems arising in another.

A vendor can provide powerful machinery, but it cannot perform all of that thinking on behalf of the enterprise without also becoming the custodian of much of what differentiates the enterprise.

This blueprint therefore does not promise intelligence in a box. It describes the structures, processes, and feedback cycles through which an enterprise can build and continually improve its own intelligence. The work required to adapt it to a particular enterprise is not an unfortunate gap between the blueprint and a product. It is precisely where much of the competitive value is created.

Why I Chose Books and a Blueprint

I could have pursued these ideas by building a commercial software product. I have been developing software for about 45 years, so this was not a path I rejected because I did not know how to build it. In fact, I know that path from experience. Across roughly a dozen attempts at implementing the ideas as they stood over four decades, I spent perhaps twenty years of those years in all-out dev mode, going through stretches of coding more than 10+ hours a day—every single day. The rest of that time didn’t consist of 10+ days of coding, but project work with lots of travel—still intense, but not quite as crazy.

Creating a successful enterprise software company has odds resembling those of becoming a big-time rock band. Technical ability, dedication, and a good idea are necessary, but so are timing, luck, endurance, and the right people. Everything has to click in unforeseen ways.

The initial implementation is only the beginning. It must become secure, scalable, supportable, configurable, documented, and usable by people who did not build it. Then come funding, marketing, sales, customer implementations, competitive positioning, and years of support. Even success places you in a continuing race to the bottom against imitators and commoditization. You must also find those rare people who genuinely understand the vision and are willing and able to jump in early. With a perfect MVP (like a hit single from an unknown act), you might hit the top of the charts, but that brings us back to the big-time rock band.

Writing my blogs and books took me on another path. Logically, I must have thought that all that work was based on good ideas … hahaha. I have a feeling that those thousands of hours of coding, long hours of thinking, etc., might be of use to somebody in this time where AI is churning things in IT land a bit. If it didn’t make me a billionaire, maybe it can provide a bit of insight someone else.

These concepts were (but still are to a lesser extent) difficult to explain in a short conversation because each one depends on several others. Business Intelligence, performance management, process mining, knowledge graphs, Prolog, machine learning, and LLMs each carry their own histories and assumptions. Explaining how they fit together usually requires beginning much farther back than the immediate question.

The books, especially Enterprise Intelligence, allow me to make the complete argument once. They preserve the definitions, reasoning, diagrams, examples, and relationships among the ideas so I do not need to reconstruct the same explanation in fifty separate conversations.

Of course, most people would not read even one big technical book merely to understand what I mean. That is one reason this overview exists. It is not a replacement for the blogs and books. It is a map that lets a reader see the overall space, understand why the pieces belong together, and decide which parts warrant a deeper look.

AI also changes the balance between publishing a blueprint and building a product. Software development is becoming accessible to far more people. AI can help an enterprise generate code, convert schemas, author ontologies and rules, create analytical functions, test implementations, and connect existing platforms. A capable team no longer needs to wait for one vendor to package every architectural idea into a single product before it can begin experimenting.

As implementation becomes easier, the scarce resource shifts. The software machinery still matters, but the harder questions concern what an enterprise should build: what it should notice, which relationships it should remember, how it represents its processes, which assumptions it tests, and how its accumulated knowledge should influence decisions.

Those answers should not be identical for every enterprise. A competitive organization needs its own strategy, reflecting its particular capabilities, customers, history, risks, and understanding of its environment. If every competitor purchases the same product and follows the same standard implementation, the product may improve efficiency, but it does not by itself provide much lasting differentiation.

The purpose of this work is therefore not to hand every enterprise the same finished intelligence system. It is to provide concepts, structures, working examples, and an architectural direction from which an enterprise can build a system reflecting what it uniquely knows and how it intends to compete.

A software product would have embodied one implementation of these ideas. The books and this site preserve the ideas from which many different implementations—and many different strategies—can be built.