5 AI Project Foundations

Sep 23

Before we begin I think its worth mentioning the master Japanese swordsman Miyamoto Musashi, a samurai Musashi lived from about 1584 to 1645, so late 1500s and 1600s. By his own account, Miyamoto Musashi fought more than 60 duels and never lost. Late in life he wrote The Book of Five Rings, and in it he argued that a warrior couldn't afford a single gap in your mental, physical or spiritual game: he painted, sculpted, practiced philosophy, poetry and wrote alongside his sword work. He saw them all as complimentary to one another. One line from that book has followed me through every AI implementation I've led:

"If you know the way broadly, you will see it in all things."

AI projects rarely fail because the model is bad. They fail through a hole somewhere else; a use case nobody can fund past the pilot, data nobody cleaned, a system nobody mapped, knowledge nobody wrote down. Seeing those holes early takes breadth across strategy, data, architecture and people. That breadth is what lets you work backwards from the goal instead of only forwards from the requirements.

Client: "Here is where we need to be." You: "Here is how we get there."

Who is this for

This article is for architects, delivery leads and product owners planning enterprise AI projects, especially on Salesforce and Agentforce. It draws on real implementations, including my work with field service organizations.

These are project foundations: what has to be in place before and during delivery. They are different from the layers of an AI solution, such as the Reasoning, Action and Feedback (Governance) layers. That's a separate article.

Scroll & Foundation

These are the five foundations I check on every project, one for each of Musashi's scrolls, and the mistakes that taught me to check them.

Earth - 1. Use Cases & Vision

Water - 2. Data Management

Wind - 3. System Architecture & Technical Debt

Fire - 4. Integration Strategy

Void - 5. Project Documentation & Knowledge Management

(Note: In Musashi's book, Wind comes after Fire. I've swapped them, because in a real project you study the other component before you engage)

1. Earth: Use Cases & Vision

Musashi compared the strategist to a master carpenter, who knows the plan for the whole house and chooses the right lumber for each part. Use cases are your lumber. Pick the wrong size and the house doesn't stand.

Find the “sweet spot”

The biggest challenge in any AI initiative is proving ROI, and it starts with how you size the use case.

Too big: the funding risk is high, someone senior has to sign off on possible failure, and a miss costs leadership's trust. That puts up walls for every AI project after it.
Too small: there's not enough value, visibility or support to matter. The budget often ends with the pilot, no matter how well the pilot went.

The right use case is big enough to matter and small enough to deliver.

Start from ‘The Vision’

AI is not an enhancement, an upgrade or an add-on. It's a shift in the operating model that affects everyone in the company and everyone who does business with it. That's why it needs a clear company vision, driven from leadership down, with success metrics tied to it. Make those metrics big, bold, defined and achievable.

The vision also has to survive the budget cycle so bring this up at the beginning. The CFO wants measurable impact. IT governance weighs risk against return. Other projects are competing for the same money. Without a clear link to revenue growth, efficiency gains or risk reduction, your AI initiative slides to the edge of the desk, next to the trash bin.

You can assist the client to create their vision and while doing this exercise, explain that the payoff will take time. Value often doesn't arrive until gaps in people, processes or technology are fixed, and that takes sustained focus.

Where enterprise AI use cases come from

The strongest candidates share three traits:

Large amounts of data
Repetitive processes or decisions
Expensive human effort, such as pulling and aggregating documents or handling support cases

The use cases I'm building workflows for next:

Customer support automation: answering support questions and routing cases.
Enterprise knowledge search: letting employees search across knowledge bases, wikis, CRM records, email and Slack in one place.
Document processing and automation: extracting information from contracts, invoices, forms and PDFs into digital templates.
Predictive maintenance: predicting asset and part failures before they happen, using IoT sensor records and maintenance logs.

Document automation shows how much value is hiding in plain sight. Picture a user who needs every contract, invoice, warranty form and recent call note for one client, location and set of assets. Today that means chasing several systems and people. With AI, the system can gather everything, put it in a template with an overview and next steps, and schedule the review meeting. Anyone who has done that work by hand can see the ROI.

Label every use case by type

Different types of AI need different architectures, so tag each use case early.

Examples:

Predictive - Ex. Lead scoring

Generative - Ex. Case summaries

Optimization - Ex. Route scheduling

Classification - Ex. Ticket routing

Key Blockers to 2026 AI Budgets

These are just a few of the common concerns:

Unclear ROI and weak financial discipline
Integration and infrastructure complexity which prevents real-time visibility
Governance, risk and security concerns
Talent and skills shortages
The pilot-to-production funding trap described above

Ask your client: What does success look like in 12 months, who is measuring it, and what happens to the budget after the pilot?

2. Water: Data Management

Musashi taught that the mind should be like water, which takes the shape of whatever holds it. AI data has to do the same - flow into the right system, the right prompt and the right user's hands at the right time. And like water, it's only useful if it's clean.

AI is only as good as its data and the architecture behind it. For my projects, data is the most common hidden blocker in AI implementations. Once a company opens the door to its data, the gap between what it has and "good" often turns into projects of their own.

Build a Data Management Plan for AI

A Data Management Plan (DMP) for AI is built around output - getting the right data to the right user or system at the right moment. Writing one forces ownership and accountability, because it answers two questions: where are we going, and how do we get there? A DMP should define at least the following.

Data processing standards. How data is collected, processed, secured and governed across the AI lifecycle, from ingestion to model retirement.
Data definitions and governance. What "clean," "compliant" and "accessible" mean for your organization, written down, from metadata through integrations to the UI. This includes ethics, which here means transparency and audit processes for detecting bias.
A semantic layer. The layer between raw data sources (such as warehouses) and the tools people use. It translates technical data into business terms, so metrics and KPIs mean the same thing everywhere. For AI, think of it as what lets a plain-language prompt find the right data.
AI-ready data architecture. Data has to be in a system where it can be acted on. It can stay in your ERP or data warehouse as long as integrations make it available when a user or process asks for it. For example, field service technicians need product, tool and asset documents in real time, and they need to download them before going offline in the field.
Metadata is the meaning of the data. Without standards for metadata and API naming conventions, you have data without meaning. I treat missing metadata standards as technical debt, which is covered in the next section.

The next three foundations build on the plan: finding the data (where is it?), getting it (how do we reach it?) and preparing it (how big is the gap to good?).

Ask your client: Who owns the definition of "clean" for each data source the AI will use?

Further reading: The 6 Primary Components of Asset Centric Projects

3. Wind: System Architecture & Technical Debt

Musashi's Wind scroll is about knowing other schools: their habits, their shortcuts and their weak points. When you arrive at a client, you're studying someone else's school. Their systems, their design decisions and their technical debt were all there before you, and you have to know them before you can build on them.

Map every system, not just the ones in scope

Before I look at requirements or integrations, I find out where the data lives. I assess the client's architecture and produce a system diagram with context. That covers all of their systems, not only the ones they think the project needs, and it identifies where the master data sits.

I learned this the hard way. On one project, a last-minute system update surfaced large data sets nobody had told the team about. Was that the client's fault? No. I owned it, because I hadn't checked every system with upstream or downstream impact on the data lifecycle we needed. Since then I've mapped the full landscape early on every project, with no exceptions.

Grade each system twice

Once the systems are mapped, I grade each one on two levels:

The system on its own. Is it healthy and well designed?
It’s fit for the AI initiative. A system that serves today's needs well may still fall short of what the AI use cases require.

I use Red, Yellow and Green with a short explanation for each, so the client can see the gap to Green. The system strategy is then how the team closes that gap. Typical findings: metadata isn't standardized and descriptions are missing, technical debt needs cleanup, or the data model isn't flexible enough for new requirements.

On one project, several systems each did their own job well. When their data had to move to the target system, only two passed with transformation. The rest didn't meet the data requirements.

Ask how the client handles technical debt

Technical debt is the cost of taking shortcuts now, often to hit a deadline, which comes back later as compounding "interest" in extra development and maintenance. It makes systems fragile (the opposite of Taleb's Antifragile), causes bugs and lowers customer satisfaction and trust for future projects.

Three kinds matter most for AI:

Type of debt > What it looks like >What it costs you

Code debt > Messy, hard-to-read code > Slower, more expensive development later
Data quality debt > Incomplete, inaccurate or unstandardized data, especially metadata > Slow, unreliable outputs and actions
Architectural debt > Rigid data models with built-in ceilings > Restructuring when data volume or requirements grow

AI multiplies whatever debt already exists, because it touches more data, more often, across more systems. Address debt early, while it's still cheap.

Decide where the data should be acted on

The last question is how to position data for the people who act on it. I work with field technicians, so I look for data that's immediately actionable, from knowledge articles to logistics for parts, tools, skills and certifications. Do we move the data to the target system, or build integrations back to the master systems? Can the data even be moved?

Ask your client: Which systems haven't we talked about yet, and who owns them?

4. Fire: Integration Strategy

Fire is Musashi's scroll on the fight itself: timing, initiative and reading the situation as it unfolds. Integration is where your systems actually meet, live and underload. Everything in the first three foundations is tested here.

An integration strategy is a roadmap

With the data and system assessments done, you can build the AI integration strategy. It starts from the use case types in foundation 1, because each type needs a different architecture.

The strategy is a roadmap for connecting AI to existing workflows, applications and channels. A customer service agent working in a console needs something very different from a field technician working offline on a phone.

This is where APIs or middleware connect your prepared data to AI models in Salesforce, so that Agentforce can automate work and handle tasks on its own.

APIs or Middleware?

My rule of thumb:

Direct APIs fit a small number of systems, simple point-to-point calls and real-time lookups where every millisecond counts.
Middleware fits many systems, heavy data transformation, orchestration across several steps, and cases where you need central monitoring, retries and error handling.
Most enterprise AI projects use both. Use APIs for real-time grounding at the moment of the prompt, and middleware for moving and transforming data in bulk.

Concepts to get right:

Data transformation: reshaping source data into the format and meaning the target and the model expect.
Disparate systems: legacy, cloud and third-party systems with different formats, speeds and owners.
Standard web protocols: REST and event-driven patterns, which Salesforce supports extensively.
Microservices architecture: small, independent services that can change without breaking each other.
Grounding: anchoring AI responses in trusted, current company data. This is one of the most important defenses against hallucinations and inaccurate answers.

Ask your client: For each use case, where does the AI get its grounded truth (facts) at the moment it answers?

Further reading: my article on integrations

5. Void: Project Documentation & Knowledge Management

Musashi's last scroll deals with what can't be seen. He warned that people often mistake what they don't understand for emptiness (the void), when it's really confusion. On a project, undocumented knowledge looks like nothing is missing, right up until the person who held it leaves.

I've arrived at projects with almost no documentation and spent days chasing people for answers that should have been written down and available on arriving. Once, the documentation couldn't be recovered at all: the person who had it left the company, and their laptop was wiped and handed to the next employee. Another time, the one person who knew something went on vacation without passing it on.

It’s sloppy, and it's risky. Documentation is the foundation of the build. Clients should assign ownership of implementation documentation to the Center of Excellence (CoE) or product managers, who sign off on it and keep it current. It's also a courtesy to the next team that comes in.

The 3 Core Documents:

Functional Design Document (FDD)

How the system works from the user's point of view
Contents: Process flows, UI mockups, data models, inputs and outputs, user roles

Solution Architecture Design Document (SADD)

How the technology fits the business goals and the wider organization
Contents: Business context and goals, logical diagrams, technology stack, data flow architecture, security strategy, non-functional requirements such as scale

Technical Design Document (TDD)

How developers will build it
Contents: Database schemas, API definitions (endpoints and payloads), algorithms, error handling, class diagrams, infrastructure configuration

How I structure them

On my last project, as on every large project, I delivered an FDD and a SADD:

System diagram of every system, backed by a detailed master spreadsheet.
Target system objects in a table below it, with descriptions, future-state designs and source to target mappings.
Integration design model with current and future states, versioned as integration points and decisions change.

Every system box and integration line carries a status color:

Red: blocked
Yellow: in progress, no decision yet
Green: signed off and ready to go

The underlying detail can be complex, but the high-level view should be easy to read at a glance by any team member or by the client. (I use ppt in many cases so that all users will be able to view, edit and save the documentation).

Documentation becomes knowledge management

The same discipline applies beyond the project. The document automation use case from foundation 1, where AI gathers contracts, invoices and notes on demand, is the start of a knowledge management strategy. I'll cover that in a future article.

Ask your client: If your lead architect or product manager left tomorrow, what would we lose?

Readiness Checklist

If you can't check every box, you've found the hole in your game.

Earth: Use Cases & Vision

Each use case is tied to a company vision and a measurable business outcome
Each use case is labeled by type (predictive, generative, optimization or classification)
Funding is planned beyond the pilot

Water: Data

A Data Management Plan for AI exists and has an owner
"Clean," "compliant" and "accessible" are defined in writing (signed off)
Metadata and API naming standards are in place

Wind: Systems

Every system is mapped, including those outside the project's scope
Each system is graded Red, Yellow or Green on its own and for AI fit
Technical debt is identified and has a plan

Fire: Integration

An integration roadmap exists for each use case and channel
The API versus middleware decision is made for each integration
Grounding sources are defined for every AI response

Void: Documentation

FDD, SADD and TDD have named owners
System and integration diagrams show Red, Yellow and Green status
The CoE or product manager has signed off on documentation standards

Closing

Musashi didn't win more than 60 duels by being strong in one area. He won because an opponent couldn't find a gap. AI projects work the same way. A strong model can't make up for a use case nobody funds, data nobody trusts, a system nobody mapped, an integration with nothing to ground it, or knowledge that walked out the door.

This isn't every foundation. Governance, Security and Change Management each deserve their own treatment, and I'll come back to them. These five come from real projects and real mistakes, and they're the ones I check first. Using the scrolls is also a great way to remember the key 5 components of a project.

Know the way broadly, and you'll see the gaps before your client does.