The Missing Layer Between Documentation and Experience

One thing has been bothering me lately.

We have incredible engineering knowledge. Standards. Design guides. Vendor documentation. Whitepapers. YouTube videos. Training courses. Experienced colleagues willing to help.

Yet becoming a good engineer still takes years.

Not because the information is unavailable.

Because experience is incredibly difficult to transfer.

When someone wants to learn about data center design today, they usually jump between dozens of different sources.

They read standards.

They watch videos.

They attend meetings.

They ask senior engineers questions.

They read vendor documentation.

Over time, they slowly piece together a mental model of how everything fits.

Eventually, they become experienced.

But that learning model was built for a world where information was scarce.

Today, information is abundant. Large language models can explain almost any concept, summarize standards, answer technical questions, and retrieve documentation in seconds. Access to knowledge is no longer the bottleneck.

The bottleneck is building intuition.

Knowing what a CDU is is easy. Knowing when to use one—and understanding how that decision ripples through cooling, electrical design, maintenance, cost, risk, and construction—is what takes years.

I don’t think the next generation of engineering tools should simply make documentation easier to search. They should help engineers build intuition by making decisions, trade-offs, and consequences interactive.

While talking to experienced data center engineers, I noticed something interesting.

They rarely explain systems.

They explain decisions.

Someone asks:

“Should we use liquid cooling?”

The answer is never just “yes” or “no.”

Instead, an experienced engineer immediately starts describing consequences.

“Well, if you choose liquid cooling…”

• your rack density can increase,
• your mechanical system changes,
• maintenance procedures become different,
• new leak detection is required,
• electrical loads change,
• construction becomes more complex,
• operating costs may decrease,
• different teams need to be involved.

That entire chain happens almost instinctively.

That’s what experience looks like.

Not memorizing components.

Understanding consequences.

The more I thought about it, the more I realized that engineering knowledge isn’t really organized the way engineers think.

Documentation is organized around systems.

Cooling.

Electrical.

Fire protection.

UPS.

Generators.

But engineers think in questions.

“Should I increase rack density?”

“Should I use hot aisle containment?”

“Should I choose N+1 or 2N?”

Each question creates dozens of downstream effects.

Engineering isn’t a collection of systems.

It’s a network of decisions.

That realization led me to build this prototype.

The idea is simple.

Instead of organizing knowledge by components, organize it by decisions.

Click on Choose Liquid Cooling and immediately see:

• the systems affected,
• the components required,
• the project stages impacted,
• the teams involved,
• the risks introduced,
• the risks reduced,
• and, most importantly, the trade-offs.

Because every engineering decision is really a balance between competing objectives.

Higher efficiency.

Lower operating cost.

Greater construction complexity.

Less layout flexibility.

Higher rack density.

There is rarely a universally correct answer.

Only a set of trade-offs that fit a particular project.

But the graph itself isn’t the interesting part.

It’s what comes next.

Imagine learning by experimenting instead of reading.

Choose liquid cooling.

Watch the graph change.

New components appear.

New risks emerge.

Construction complexity increases.

Operating costs decrease.

Now reset.

Choose air cooling instead.

See a completely different set of consequences.

You’re no longer consuming information.

You’re building intuition.

Other professions have already embraced this idea.

Pilots spend hundreds of hours in simulators before flying passengers.

Doctors increasingly train using simulations before treating patients.

Software engineers learn by building projects rather than just reading books.

The built environment industry still relies heavily on documentation and accumulated experience

What if we had the equivalent of a flight simulator—not for aircraft, but for engineering decisions?

Not a detailed physics simulation.

A decision simulator.

A place where you can safely explore thousands of engineering choices, understand their consequences, and develop intuition much faster.

I don’t think AI will replace experienced engineers.

But I do think it can help us capture something that has always been difficult to transfer: engineering judgment.

The relationships.

The dependencies.

The trade-offs.

The reasoning behind decisions.

Maybe that’s the missing layer between documentation and experience.

And maybe that’s how the next generation of engineers will learn.

‍