By Raj Brar, Founder of Argus AI Labs
Nearly three decades ago, in my early twenties, I was running three automotive diagnostic centers. My world was not engines in the traditional sense. It was electrical systems, relays, control modules, ECUs, sensors, wiring, and the logic connecting them.
A fault code could tell you where to begin, but it could not tell you what was actually wrong. Two vehicles could present the same code for completely different reasons. The component named by the computer might be perfectly healthy. The real problem could be a broken signal upstream, a failed ground, an intermittent relay, damaged wiring, or a control module responding exactly as designed to bad information.
That was the work. You traced the system, tested assumptions, compared what should be happening with what was actually happening, and learned that the obvious answer was often only the first layer of the problem.
Diagnostics taught me very early that information and understanding are not the same thing. The computer could give you information. The intelligence came from understanding the relationships inside the system well enough to interpret what that information meant.
That way of thinking became foundational for me. Long before I knew the language of machine learning, retrieval systems, schemas, knowledge graphs, or large language models, I was already learning to think in terms of signals, evidence, relationships, dependencies, logic, and failure paths. More importantly, I was learning to investigate.
That distinction matters to me today because we are living through an extraordinary moment in artificial intelligence, yet much of the conversation still begins too late.
We start with the model: Which model is smartest? Which model has the largest context window? Should we fine-tune? Should we use retrieval? Should we build a knowledge graph? These are legitimate questions, but they are downstream questions.
Before an AI system reasons about anything, someone has already decided what it gets to see— what matters, how things relate, what gets preserved or discarded, and what should be trusted. The model arrives after many of the most consequential decisions have already been made.
That is why I have come to think about this work less as AI implementation and more as intelligence architecture.
Because information is not intelligence.
Intelligence is what determines what matters, what connects, what can be trusted, what is missing, and what should ultimately be acted on.
Learning to see before deciding what something means
Roughly two decades later, my life took me in a completely different direction.
I spent five years in India, including roughly two and a half years in and around Rishikesh, in the Himalayan foothills. I spent long periods in solitude, studying the mind, meditation and yoga, and moving through different ashrams and monastic communities. One of those periods brought me into a Buddhist ashram, where I encountered a line from the Dhammapada that stayed with me:
“Heedful among the heedless, wide-awake among the sleepy…”
A Buddhist teaching like that is difficult to explain in one paragraph because it is not designed to be consumed as a quotation. You sit with it and revisit it. Sometimes you think you understand it, and then months or years later you see something else inside it.
For me, one of the deepest ideas in that teaching is attention. Not attention in the modern sense of simply concentrating harder, but attention as a quality of seeing: being awake enough to notice what is actually occurring before the mind rushes in to explain it.
Human beings are extraordinarily fast interpretation machines. Something happens and almost immediately we create a story around it. We categorize it, compare it to memory, decide what caused it, and decide what should happen next. Often that ability is useful. Sometimes it blinds us.
The interpretation can become so fast that we stop distinguishing between what we observed and what we concluded.
I had seen the same problem in diagnostics. A technician sees a fault code and replaces the component named in the code. The experienced diagnostician asks what would have to be happening elsewhere in the system for that code to appear.
One person reacts to the information. The other investigates the system that produced it.
Those are different forms of thinking, and increasingly I believe that distinction sits at the center of the AI problem.
The investigator is looking for what the report cannot tell him
I have read extensively in Jim Sterne’s work over the years, and his writing around discovery and the analyst as investigator has always resonated with me.
Sterne writes about the difference between simply producing analysis and actually discovering something. A report usually begins with a known question: what happened, how much changed, how one category performed against another. Those questions have value. Organizations need answers to them.
Discovery begins when the answer creates another question.
Something does not fit. A number is unexpectedly high, a pattern disappears, two datasets disagree, a result moves in a direction nobody anticipated, or something that should have happened did not happen.
That is when analysis becomes investigation.
The investigator does not immediately try to force the anomaly back into the expected story. The anomaly is the interesting part because it is evidence that the current mental model may be incomplete.
Something should be there, and it isn’t. In diagnostics, that could be a signal, a voltage, a ground, or a response from a control module. The absence tells you something about the system — but only if you understand what should have been present in the first place.
To recognize that something is missing, you need more than information about what is present. You need a model of what should have been present. That is a much more difficult problem.
A database can tell you what happened. An intelligent system should increasingly be able to help us understand what should have happened, what relationship we expected to observe, why reality diverged from that expectation, and whether that divergence matters.
Doing that requires context, history, relationships, and some understanding of the system beyond the individual record. That is why I think intelligence architecture begins much earlier than the LLM.
Before the machine learns, we have already shaped its world
This became tangible for me in India.
Around 2017, I began investing in data-annotation companies. I also invested in a LiDAR company. At the time, the current generative-AI wave did not exist, but the underlying problem was already there:
How does a machine learn what the world contains?
Annotation sounds deceptively simple. A person draws a box around a pedestrian, marks the edge of a vehicle, labels a road sign, classifies an image, identifies an object, or categorizes a sentence.
Look more closely, though, and a human being is deciding what distinction matters. Where does the object begin and end? What category does it belong to? Is the example ambiguous? Does an edge case belong with the others? Which features matter, and which should be ignored?
At a fundamental level, annotation is an act of representation. We take something messy and continuous in the real world and convert it into a structure a machine can learn from.
That realization has stayed with me because machine intelligence does not begin with reality. It begins with our representation of reality.
Annotation is only one expression of that. Schemas, taxonomies, ontologies, metadata, graph relationships, authority rules, and retrieval systems all participate in representing the world and determining what the model is ultimately able to see.
This is where I think many AI discussions become too model-centric. We talk as though the model is sitting in front of reality and independently discovering meaning.
It is not.
The model receives an environment that has already been shaped. Documents have been selected, data cleaned, fields named, categories created, relationships encoded or omitted, and information transformed. Some evidence will be retrieved; some will never reach the model at all.
By the time an LLM generates a sentence, an enormous amount of architecture has already influenced what that sentence can possibly contain.
This is also why I am skeptical when people speak casually about an AI system “understanding the data.” Which data, represented how, and derived from which source? What happened to it before it reached the model, and what important context or relationship might be missing?
Those questions are not peripheral to intelligence. They are the conditions under which intelligence becomes possible.
That early exposure to annotation strongly shaped how I think about knowledge architecture at Argus AI Labs today. The model is important, but the model is downstream of the world we have built for it.
Every layer of abstraction can hide the thing that actually happened
There is another idea in Sterne’s work that connects strongly with this: understanding the raw material.
Data does not remain untouched for long. It gets cleaned, normalized, mapped, aggregated, summarized, segmented, embedded, ranked, and passed between systems. Each step can make information easier to use, while also creating more distance from the original event.
That tradeoff matters.
Suppose a regulatory authority issues a finding. Someone summarizes it for an internal compliance team. That summary enters a broader risk report, which becomes one input into a risk-scoring process. The score is later surfaced to an AI system asked to recommend an action.
At the end of the chain, the recommendation might look sophisticated. But what exactly does the system still know about the original finding? Does it know which authority issued it and when? Can it distinguish the regulator’s language from an internal summary? Does it know what assumptions entered the risk score, and could someone trace the recommendation all the way back to the original evidence?
If not, something important has been lost.
This is why provenance is not administrative overhead. It is part of the intelligence itself.
If we cannot reconstruct where knowledge came from and how it changed along the way, we may have information without context. And information without context is extremely easy to misuse.
The further a conclusion travels from its source, the more important it becomes to preserve the path between them.
That is what I mean by Source to System.
It is not simply moving data from one location to another. It is preserving enough meaning along the path that the system can still understand what the information represents, where it came from, how it relates to other information, and why it should or should not be trusted.
Legal intelligence became the proving ground
Our work in legal intelligence made these ideas difficult to ignore.
In our internal research and development at Argus, we have been building and testing legal knowledge systems around provenance, authority, temporal validity, relationships, and bounded reasoning. Legal information exposes the weakness of simple retrieval very quickly.
A system can retrieve a highly relevant piece of law and still arrive at the wrong conclusion.
The document may be real. The citation may be real. The passage may contain the exact terminology used in the question. But that does not establish that the law applies.
The provision may have been amended, another authority may control, an exception may change the result, the relevant date may put the matter under a different version of the law, or two authorities may need to be read together before either makes sense.
This became the basis of the research problem behind our forthcoming paper: relevance is not applicability.
The distinction sounds narrow until you realize what it reveals about AI more broadly.
A retrieval engine solves one problem: what information appears related to this question?
An intelligence system has to solve a harder one: what information actually governs the answer, under these conditions, at this time, and why?
That requires representation of relationships, authority, time, provenance, context, and clear boundaries on what the system is allowed to conclude. If those things are missing from the architecture, the language model at the end cannot simply invent them reliably.
What we often call an AI failure may therefore have begun much earlier. The wrong information may have been represented, an important relationship left unencoded, relevant evidence missed during retrieval, temporal context stripped away, or provenance lost during transformation.
The final answer is merely where the upstream mistake becomes visible.
That insight has influenced how I now approach any intelligence problem. I do not begin by asking what the model can do. I begin by asking what the system must understand.
Intelligence has an architecture
There is a reason so much AI terminology sounds cognitive. We speak of attention, memory, learning, perception, reasoning, recognition, and language because these are functions we first encountered in ourselves.
The human being remains the richest intelligence system we know. We still understand only fragments of how attention, perception, memory, emotion, intuition, pattern recognition, and reasoning interact inside a living person.
And every year, we discover more complexity.
For me, that is one of the most interesting aspects of artificial intelligence. Building machines that perform pieces of cognition forces us to look again at cognition itself.
What does it really mean to remember or recognize something? How does context change meaning, and how do we know when a familiar pattern no longer fits?
Humans wrestle with these problems constantly, often without being aware of it. We see selectively, remember selectively, form patterns, carry assumptions, misread signals, and become attached to explanations. Sometimes a single anomaly forces us to reconstruct the entire model.
Machines are different from human beings, of course. But many of the architectural problems we encounter when building intelligent systems have recognizable parallels. Attention affects what enters consideration, memory affects what remains available, representation shapes how something can be understood, retrieval determines what evidence reaches the moment of reasoning, context changes meaning, and judgment determines whether the system should act.
That is why I have little interest in reducing intelligence architecture to a list of technologies.
The technologies will change. The underlying questions are much older: what deserves attention, what does the information mean, what does it connect to, where did it come from, what is missing, what can be trusted, and what should happen next?
Nearly three decades ago, I was asking primitive versions of those questions while tracing electrical faults through automotive control systems. Later, in the Himalayas, I encountered them through the study of attention and the mind. In India, annotation and machine perception showed me how explicitly humans have to represent the world before machines can begin learning from it. Today, building AI systems has brought those threads together.
I do not believe the most consequential AI systems will be defined simply by access to the most powerful models. Models will become better, cheaper, and faster.
The deeper advantage will come from how well we architect the intelligence around them: whether we preserve the source and its provenance, represent the world accurately enough for meaningful relationships to survive, control what reaches the reasoning layer, notice what is missing, preserve uncertainty honestly, and remain able to trace an answer back through the system that produced it.
That is the work.
Information is not intelligence.
The job of an Intelligence Architect is to architect the path by which information becomes intelligence—from source to system.