Why I Built Sensemaker

The Question That Followed Me Out of PARC

Xerox PARC sharpened a question that had been forming in me for years: what is the use of collecting more data if an enterprise still can’t make sense of what it already knows? It didn’t arrive as a slogan for a pitch deck, and it didn’t start out as a product thesis either. It came from watching real technology run into the practical limits of what an institution could actually understand.

The promise of big data was real. The Big Data Foundry, graph analytics, recommender systems, machine learning, SAP HANA, and enterprise datasets running into hundreds of terabytes all made the future feel technically within reach. We could pull in more data, store more of it, and run heavier analysis against it than any earlier generation of enterprise systems had managed. The tools were finally catching up to the size of the problems, and that felt intoxicating.

Yet something stayed unfinished. Enterprises were gaining visibility faster than they were gaining understanding. Dashboards kept multiplying, reports kept stacking up, data lakes grew, models got trained, pilots got launched, and the decisions that actually mattered still came down to manual digging, disconnected workflows, institutional memory, and people trying to stitch context together from too many broken places. The organization could see more. It couldn’t always decide better.

That gap was the opening for the Sensemaker. The problem was never just data. It was the enterprise’s inability to turn scattered signals into action it could trust.

When Data Outran Understanding

The enterprise had landed in a strange spot. More records than before, more systems, more analytical tools, more technical ambition, and decision-making that was still fragile underneath all of it. A dashboard could show a trend without telling the operator what actually mattered. A model could produce a score, and the user still had to decide whether to believe it. A data lake could hold years of institutional history while the one signal that mattered failed to reach the right person at the right time.

This was the part of big data nobody had really solved. The industry had gotten very good at moving, storing, and processing information, and much less disciplined about turning that information into judgment. The path from signal to interpretation, interpretation to decision, and decision to accountable action was where most organizations kept getting stuck.

I’d already spent years learning to look past visible outcomes for the conditions underneath them. Soil teaches you that growth depends on things you can’t see with your eyes, the microbes, the minerals, the water table beneath the topsoil. Circuits work on a similar principle, except the hidden layer is pathways instead of soil chemistry. Factories taught me a related lesson, that software is only as good as the actual work it serves. And public infrastructure adds one more piece: trust becomes real the moment strangers can rely on a system without ever needing to understand how it works.

The enterprise wasn’t any different. Every visible decision rested on conditions nobody could see directly: connected context, reliable memory, real relationships, workflow people trusted, human judgment, machine assistance, explanation, and governance. Weaken any of those, and the decision built on top of them gets weaker too.

The Compliance Machine

Financial crime is where the problem became impossible to ignore. For years, institutions had treated it mainly as a transaction-monitoring problem. That framing was too narrow. Financial crime is a sensemaking problem, and treating it as anything less had made compliance expensive, reactive, and exhausting to run.

Traditional systems worked through rules, thresholds, checklists, and ever-growing teams of analysts. A transaction crossed a threshold and triggered an alert. A name matched a watch list and a case opened. A known pattern showed up and the investigation queue grew by one more item. Every new regulation added another workflow, every new threat added another rule, and every investigation eventually produced another report that fed straight back into more rules.

The machinery kept expanding because the people on the other side kept adapting. Criminal networks don’t organize their activity around regulatory thresholds. They split it across entities and jurisdictions, hide behind legitimate-looking structures, and look constantly for the gaps in what an institution can actually see. So the institution adds rules. The rules generate alerts. The alerts need analysts. The analysts’ findings turn into more rules. Around it goes.

At some point the system starts optimizing for activity instead of understanding. Millions of alerts can move through a compliance operation while only a small fraction of them point to anything that actually matters. The institution looks busy, spends a fortune, documents every step, and is somehow still behind the people it’s trying to catch.

The Pattern Beneath the Company

A founder usually starts with a pattern before he has proof of it. It shows up in different places under different names, across different customers and technologies. At first it looks like a problem specific to one industry. Later you realize it’s architectural, and the industry was just where you happened to notice it first.

The pattern I kept running into was simple to state and hard to fix: institutions were becoming data-rich and decision-poor. They had invested in data infrastructure, analytics, reporting, machine learning pilots, and visualization layers, and the actual decision still lived scattered across people, systems, policies, emails, queues, and memory. More information existed. The act of deciding hadn’t been rebuilt to handle that much of it.

Financial institutions showed this most clearly. They sat on enormous amounts of information: transactions, customer records, sanctions databases, watch lists, past investigations, regulatory filings, news feeds, third-party intelligence. The limitation was never the availability of data. It was the inability to turn all of it into understanding.

Sensemaker grew out of that recognition. The enterprise needed a way to turn scattered signals into decisions people could understand, trust, act on, and learn from. Everything else was downstream of that one problem.

The Rules Trap

Rules had their place. They’re understandable, auditable, and genuinely necessary in regulated environments. The trouble started when rules became the entire imagination of what intelligence could be. A rule is good at catching what’s already been defined. It’s much worse at recognizing behavior that’s still changing shape.

This is where traditional compliance systems began to fall apart. They were built on deterministic logic inside a world that isn’t deterministic at all. If this happens, raise an alert. If that pattern shows up, escalate it. If a name matches a list, open a case. These systems could document what happened, but they were never built to understand why it happened.

Sophisticated risk rarely shows up as a single suspicious event. It shows up through relationships, timing, repetition, distance, and ownership, stitched together over time. The same transaction can be completely harmless in one setting and a red flag in another. A rule sees the transaction. A system built for sensemaking has to understand everything around it.

That difference shaped everything that came after. Sensemaker couldn’t just become another alerting tool stacked on top of the old ones. It had to treat risk as something alive, not something that could be fully captured in a list of conditions.

Risk as a Living System

Risk doesn’t sit inside isolated transactions. It comes out of how entities, events, behaviors, relationships, and intentions interact with each other. A transaction is one signal. A customer is an actor inside a network. A company carries ownership structures, dependencies, counterparties, behavior patterns, and history. Even a closed case is really part of a longer institutional memory, whether the software treats it that way or not.

That insight changed the architecture. Instead of scoring isolated events one at a time, Sensemaker modeled the whole environment as an interconnected system, with customers, accounts, transactions, counterparties, devices, addresses, documents, alerts, past investigations, behaviors, and outside intelligence all sitting inside one operational landscape.

Graph reasoning sat at the center of this, because most of the serious problems in an enterprise are relationship problems. Fraud reveals itself through relationships. Financial crime hides inside them. Customer risk, supplier exposure, sanctions evasion, and compliance failures usually only become visible once you can see how entities connect to one another. A table can tell you an account exists. A graph can show you how that account behaves inside its network.

The graph was never the finish line, though. The goal was never a beautiful map of complexity for its own sake. A relationship only mattered if it led somewhere, to attention, to an investigation, to an explanation, to an action the system could later learn from. The graph had to serve the decision, not replace it.

The Architecture That Realized Sensemaker

Turning this into something real took more than analytics. It needed an architecture that could observe, remember, reason, explain, and learn, all as part of the same system. That foundation rested on three core components.

Put together, they formed a system that could keep observing the enterprise’s environment, build understanding over time, weigh competing explanations, and support people working through high-stakes decisions.

I have clearer words for this now than I did at the time. Pulse was an early form of autonomous sensing. Factbase was persistent institutional memory. Qiera was explainable reasoning. Together they made Sensemaker feel less like a typical compliance product and more like an early version of a cognitive intelligence architecture.

That distinction mattered because the original problem was never a shortage of reports. The institution needed a living picture of its own operating environment, one that could change as the environment changed.

Pulse and the Work of Observation

The first problem was observation. Traditional systems collected data, but collection on its own wasn’t enough. Sensemaker needed something that could keep watching the environment and turn raw information into behavioral signal.

Pulse was built for that job. It pulled in structured, semi-structured, and unstructured information from sources inside and outside the institution: transactions, sanctions lists, customer records, past investigations, watch lists, news feeds, social signals, regulatory data, third-party intelligence. Its purpose wasn’t just to bring information into the system. It had to notice what the behavior was suggesting.

That distinction mattered a lot in practice. A conventional system asks what happened. Pulse asked what the behavior might mean. It turned events into signals, and signals into the start of interpretation. In today’s vocabulary you’d probably call Pulse an agent layer, but the intent behind it was practical long before the term became fashionable.

What the enterprise needed was sensing that didn’t wait around for someone to run a report. It needed continuous observation, normalization, and signal formation happening quietly in the background. Pulse gave Sensemaker that first move from raw data to something closer to behavior.

Factbase and the Problem of Memory

Most compliance systems forget. They might store case histories, archive old reports, and keep logs around, but they don’t necessarily remember in a way that helps the next investigation go any faster. Too often, that next investigation starts close to zero, even when the institution has already seen a related pattern before.

Factbase existed to fix that. It held onto persistent knowledge about entities, events, relationships, investigations, behaviors, outcomes, and emerging patterns. Every investigation added a little more context. Every confirmed case sharpened how the system read the next one. Every correction a human made became part of the system’s memory going forward.

This was more than storage. Factbase turned past observation into something closer to organizational intelligence. It let Sensemaker carry continuity across cases, across users, and across time, so the system could recall that a relationship had mattered before, that a particular pattern had led to a certain outcome, or that a behavior had shifted meaning under new circumstances.

The industry would later coin terms like knowledge graphs, contextual memory, and digital twins for ideas in this space. Factbase was my early attempt at building that kind of memory inside the enterprise. Intelligence without memory stays shallow, no matter how sophisticated the model underneath it. Factbase gave Sensemaker depth.

Qiera and the Work of Understanding

If Pulse observed and Factbase remembered, Qiera was where the system actually reasoned. It built dynamic models of entities, activities, relationships, and behaviors, then worked through possible explanations for what it was seeing, weighing one hypothesis against another against the evidence on hand.

Qiera wasn’t built just to flag suspicious transactions. Its real job was to get at intent: who was involved, what relationships were in play, what associations might be hiding underneath the obvious ones, and which explanation actually fit the evidence best. Those were the questions it had to work through before an investigator ever saw the case.

That was a real departure from typical machine learning, where most models hand you a prediction and stop there. Qiera needed to produce a reasoning path that investigators, auditors, and regulators could actually follow, with evidence, relationships, and interpretation coming together in a form that supported human judgment instead of replacing it with something opaque.

This is where Sensemaker started to feel genuinely alive. It wasn’t just collecting, scoring, and routing work. It was trying to understand, and trying to make that understanding visible enough for people to challenge it, check it, and ultimately trust it.

Explainability as a First Principle

One of the most important calls behind Sensemaker was refusing to build a black box. Financial institutions operate in a world where decisions have to be explained. Regulators don’t just ask whether a system found risk. They ask why. Auditors ask what evidence was used. Investigators need to know why one case deserves their attention while another can wait.

Explainability had to live inside the architecture itself, not get bolted on afterward. Every prediction needed its relationships attached. Every relationship needed its evidence. Every piece of evidence needed its reasoning spelled out. Accurate prediction on its own was never the goal. Trustworthy intelligence was.

That single distinction shaped both the product and the company. A prediction nobody can explain might impress a technologist in a demo, but it struggles the moment it enters regulated work. A model nobody can interrogate might perform beautifully in a lab and still fail once it’s inside a real enterprise. Sensemaker had to earn trust in a world where people, not algorithms, carried responsibility for what happened next.

That’s also why governance was part of the architecture from the start rather than a layer we added later. Authority, auditability, controls, policy, and human oversight had to travel alongside the intelligence, not trail behind it. In high-stakes environments, trust is really the product underneath the product.

The Enterprise Digital Genome

The most important architectural idea in all of this was something we called the Enterprise Digital Genome. It tried to model an organization as a living system made up of entities, relationships, activities, objectives, constraints, and behavioral patterns, rather than as a pile of isolated transactions waiting to be scored one at a time.

That idea came straight out of my habit of looking past whatever is visible for the structure underneath it. In soil, the crop you can see depends on a dense web of microbial, mineral, water, root, and climate relationships you can’t. In circuits, visible function depends on hidden pathways. In an enterprise, a visible transaction depends on a similarly dense structure of identity, ownership, behavior, incentive, policy, workflow, and history.

The Enterprise Digital Genome was an attempt to capture that hidden structure directly. It gave Sensemaker a way to represent the enterprise as something alive enough to observe, remember, reason about, and improve over time. It also became the intellectual root of a lot of what came later in my work: the broader Enterprise Genome concept, later versions of Factbase and Qiera, autonomous digital twins, and the agentic architectures now taking shape across 451 Labs.

The vocabulary has changed since then, but the original insight hasn’t. You can’t understand a complex system by looking only at isolated events. Its behavior comes from structure, relationship, memory, and adaptation, all working together at once.

The Human Belonged Inside the System

Machine learning had a real job to do here. It could prioritize signals, catch anomalies, surface patterns, and help people focus their attention where it counted. I believed in that deeply, but enterprise reality had also taught me to be careful. Prediction without context can become its own kind of confusion.

The human side of this could never be treated as a temporary inconvenience on the road to full automation. Investigators, analysts, compliance officers, and risk teams carried forms of knowledge no model had access to: policy nuance, exceptions, intent, institutional history, customer context, and a practical sense of what a wrong call would actually cost.

Sensemaker had to learn from human action: corrections, escalations, approvals, rejections, explanations. An analyst wasn’t there just to click through a queue of alerts. The analyst was part of the intelligence itself. Every judgment they made had the potential to sharpen Factbase, push back on Qiera, and refine how Pulse sensed things going forward.

That belief sounds almost obvious now, in an era full of talk about AI governance and human-centered automation. Back then, during that first generation, it was simply the only way the system could earn anyone’s trust. The institution needed intelligence shared between machine and human, with each one making the other better.

Workflow Was Where Intelligence Became Real

Software only earns its place once it actually serves the work. I’d learned that lesson in factories and public infrastructure long before Sensemaker existed. An insight that never makes it into a workflow is just decoration. A model output that never changes what someone does next is unfinished work. A recommendation that can’t move through roles, permissions, queues, escalations, approvals, and audit trails is never going to be trusted.

Enterprise decisions happen inside real operating structures. People carry responsibilities, systems have boundaries, policies carry authority, and actions have consequences attached to them. Sensemaker had to respect all of that. It had to support the actual movement from signal to investigation, investigation to recommendation, recommendation to action, and action back into learning.

The phrase that eventually summed it up only sounds simple after the fact: sense, decide, act, learn. Inside a real enterprise, that cycle crosses systems, people, policy, and trust every single time it runs. The architecture had to carry all of that weight without burying the person trying to use it.

This is part of why Sensemaker could never just be a dashboard. Dashboards show you things. A decision system helps the next right action actually happen.

The Founder’s Translation Problem

The technical work was hard, but the founder’s job carried its own kind of weight. The market didn’t yet have clean language for what we were building. Customers understood the symptoms in front of them. One leader saw alert fatigue. Another saw false positives piling up. Another saw fragmented investigations or data silos. Others saw models nobody could explain, mounting compliance pressure, or risk buried inside relationships no existing system could trace.

Every one of those symptoms was real, and every one of them pointed at the same underlying condition. The hard part was helping people see the whole picture without forcing them to buy into an abstraction first. A founder building ahead of the market’s vocabulary ends up translating constantly, in nearly every conversation.

To a technologist, Sensemaker was about graph intelligence and decision infrastructure. A risk leader heard better investigation and prioritization. A compliance leader cared about explainability, auditability, and governance. An operator wanted workflow and productivity. An executive needed risk reduction, cost efficiency, and confidence that the program actually worked.

The same system had to be explained through several different doors, and every door had to lead back to the same house. That kind of work is genuinely tiring. It asks the founder to hold the whole architecture in his head while speaking, sentence by sentence, in whatever language the buyer’s pain happens to use.

The Technology Had to Earn Its Place

SAP HANA mattered because performance mattered. Dense relationships, heavy analytical workloads, and large enterprise datasets demanded real speed, real scale, and enterprise-grade credibility. We weren’t working on toy problems. The system had to hold up in environments where delays, weak integrations, or slow response times could quietly destroy whatever trust we’d built.

Still, the technology always had to stay subordinate to the decision it was supporting. A fast system that doesn’t improve judgment is just fast. A powerful model nobody trusts is still incomplete. A graph that reveals relationships but never changes what someone does is just another piece of analysis sitting on a shelf.

Every technical choice had to answer a few practical questions: did it help the user see what actually mattered, cut down the burden of investigating something, or surface a relationship that had been hidden? Did it explain its own recommendation, preserve accountability, and help the institution learn something it didn’t already know?

That discipline kept the product honest. Sensemaker was never meant to look impressive. It had to become useful intelligence inside a real enterprise, on a normal Tuesday, not just in a demo.

The Long Middle

The early days of any company carry a particular kind of energy. A belief turns into motion. A small team gathers around a question. The product starts to take shape. Customer conversations sharpen the thesis. Technical decisions turn into commitments you can’t easily walk back. The roadmap starts to say out loud what you actually believe the world is going to need.

Then comes the long middle, where the idea runs into real buyers, real budgets, integration headaches, implementation delays, user behavior, investor expectations, and a market that still doesn’t have the right category for what you’re selling. Conviction stops being romantic somewhere in that stretch. It has to turn into discipline instead.

Sensemaker taught me that a broad thesis needs a wedge. Decision infrastructure was the bigger belief, but enterprises don’t buy a belief in the abstract. They buy an urgent problem, one with consequences, users, budget, and pressure to act now rather than later.

Risk intelligence turned out to be that wedge. AML, KYC, fraud, compliance, and financial crime carried the full weight of complexity the system had been built to handle: fragmented signals, hidden relationships, human investigation, machine learning, workflow, explainability, governance, and consequences nobody could afford to ignore. The wedge gave the larger vision somewhere to actually land.

What the First Generation Taught

That first generation of Sensemaker taught lessons that still hold up. Data on its own doesn’t create intelligence. Understanding comes out of relationships. Machine learning without memory stays shallow, because real intelligence needs continuity across time. Predictions without explanation don’t survive contact with a serious institution.

Risk is contextual. The same event can be harmless in one setting and alarming in another. Alerts only help when they actually carry meaning. Workflow matters because intelligence has to enter the work itself, not sit beside it. Human judgment matters because no model gets to own responsibility for the outcome. Governance matters because enterprise decisions eventually have to survive scrutiny from someone outside the building.

The deepest lesson was also the simplest.

Looking at it through today’s lens, Sensemaker was never really just an AML platform. It was an early cognitive intelligence architecture. Pulse brought autonomous sensing. Factbase brought persistent organizational memory. Qiera brought explainable reasoning. The Enterprise Digital Genome brought a way to represent a complex system as a whole.

What Sensemaker Really Answered

Sensemaker answered a question I’d been circling for years before I ever had a name for it. Soil had shown me that visible growth depends on conditions you can’t see. Circuits had shown me that function depends on hidden pathways. Factories had shown me that software only matters if it serves real work. Public infrastructure had shown me what it takes for strangers to trust a system. Databases had shown me that institutions need memory. Cloud had shown me how infrastructure turns into economics. PARC had shown me that data without sensemaking is unfinished work.

All of those lessons came together in one enterprise problem. How does an institution turn scattered signals into action it can actually stand behind, while keeping human judgment in the loop alongside machine intelligence, in a way that can be explained, governed, audited, and improved over time?

Sensemaker was my answer to that. It connected records to relationships, models to people, signals to workflow, and explanation to governance. It helped the enterprise move from simply seeing more to actually understanding better, and from understanding better to acting with real confidence.

The Question Beneath the Product

Every company a founder builds carries a piece of how he was formed. Quantiply carried a lot of mine, and Sensemaker carried the specific question that had followed me out of PARC. The enterprise had entered an age of data abundance, and that abundance had exposed a weakness nobody quite expected: more data hadn’t automatically produced better decisions.

What was actually missing was decision infrastructure, a trusted layer where signals, relationships, human judgment, machine intelligence, workflow, explanation, and governance could all come together in one place. Sensemaker gave that need a working architecture through Pulse, Factbase, Qiera, and the Enterprise Digital Genome.

It started with financial crime, but the real discovery reached well past compliance. Every complex system runs into the same wall eventually. The hard part is turning information into understanding, understanding into judgment, and judgment into action people can actually trust. That question didn’t end with Sensemaker. It’s still shaping how I think about intelligent enterprises, agentic systems, regenerative prosperity, and the hidden architecture underneath every serious thing worth building.