Discovery

A disciplined start to operational AI. Rigorous in method, narrow in scope, fast to insight.

Most organizations can point to where their operations struggle: slow responses, recurring exceptions, inconsistent decisions, work that depends on a few experienced people. What they usually lack is a precise account of why those problems persist, and what it would take to resolve them.

Discovery supplies that account. It is the first engagement, and a complete one in its own right. We reconstruct how the operation actually decides, make that logic explicit, test it against the evidence, and recommend what to build first, or whether to build at all.

Start with the decision

We begin with an outcome the organization wants to improve, then narrow it to one consequential decision, or a small set of closely related ones, that drives it. Faster exception resolution, more consistent service, fewer preventable errors, better use of scarce people and assets: each becomes a specific decision to examine.

The narrow scope is deliberate. It keeps an AI initiative from turning into a technology program before anyone has said what the system must accomplish.

Reconstruct the operation

Procedures describe how work is supposed to happen. Experienced people know what happens when information is missing, systems disagree, a constraint changes, or an exception needs judgment. Discovery examines both.

Through focused interviews, process reviews, operational records, and working sessions with the people closest to the decisions, we establish:

• which decisions determine the outcome;
• what information each decision needs, and where it lives;
• which rules, policies, and constraints apply;
• how exceptions, conflicts, and uncertainty are handled;
• who holds decision authority, and when escalation is required;
• where delay, duplication, wasted effort, and preventable error arise.

We pay particular attention to knowledge that has never been written down. It is often what makes AI useful, and what makes it safe.

Make the logic explicit

We then model what we have learned: the entities, relationships, events, and states that define the operating world, and the rules, sequences, dependencies, and exceptions that govern the decisions.

Each part of a decision is assigned to the form of intelligence that suits it: deterministic rules, optimization, statistical or language models, conventional software, or human judgment. Authority is assigned the same way. An agent may retrieve information, assess a situation, recommend an action, or carry out a bounded task; higher-consequence decisions require review or explicit approval. These limits are set in the architecture, where they can be examined and tested, rather than discovered after deployment.

The result is a decision and logic map that executives, practitioners, and engineers can read together, and that engineers can build from.

Test the evidence

A plausible use case is not yet an investment case. We examine the available data, identify gaps, test key assumptions against real operating cases, and assess the practical constraints on implementation.

We also define how performance will be judged, and separate established baselines from estimates. Where the evidence is thin, Discovery names what must be measured before any performance claim is made.

Fast, because it is narrow

Speed comes from scope, not shortcuts. Investigation, modeling, review, and refinement run in short cycles, and early models are tested against real cases, including the awkward exceptions that expose a weak design. Discovery does not need to map an entire enterprise to show how one consequential part of it can work better.

What you receive

Deliverables are shaped to the assignment. Typically:

• An operational diagnosis: the problem, its causes, and the decisions that shape the outcome.
• A decision and logic map: entities, information flows, rules, exceptions, dependencies, and decision rights.
• An initial system architecture: the roles of rules, optimization, models, conventional software, and human authority.
• An evidence and feasibility assessment: available data, critical assumptions, constraints, risks, and baseline measures.
• An implementation recommendation: a bounded first build or pilot, with acceptance criteria, priorities, and a staged path forward.

A sound basis for investment

At the end of Discovery, leadership can answer five questions: what problem we are solving, which decisions must improve, what the system must know and do, how it will be governed and measured, and what to build first. Technical teams get a common specification. Executives get a clear account of what they are being asked to fund. The work stays useful whether the build is done by our engineers, yours, or a partner’s.

Discovery can also conclude that AI is unnecessary, that existing systems should be fixed first, or that a build should wait for better evidence. Those are valuable findings, not failed engagements.

When the answer is to proceed, the next step is usually a narrow first build, described in The Minimum Viable Pilot.

We start with a decision that matters.