Your Documentation Was Correct Six Months Ago

We did it.

We found the undocumented process.

We interviewed the people doing the work.

We traced the spreadsheets.

We identified the scheduled jobs.

We even figured out why Bob’s stored procedure from 2014 was still running.

The business reviewed everything.

The process owner approved it.

We published the documentation.

Someone probably scheduled a meeting to celebrate.

Six months later, it was wrong.

Of course it was.

Welcome back to Production.

Documentation Has a Shelf Life

Organizations love documentation.

Or at least they love the idea of documentation.

We create process diagrams.

Write standard operating procedures.

Build knowledge bases.

Document integrations.

Publish runbooks.

And occasionally, someone even remembers to update them.

But here’s the problem.

The business doesn’t stop changing just because we finished writing things down.

A vendor changes its file format.

A department changes its approval process.

Someone replaces a scheduled job.

A new application gets introduced.

A manual step becomes automated.

A business rule changes.

Jeannine finds a better way to accomplish something.

And somewhere, sitting proudly in SharePoint, is a document explaining exactly how things worked six months ago.

Technically, it’s documentation.

Practically?

It’s historical fiction.

The First Draft Doesn’t Have to Come From a Human

In the last article, we discovered that the actual business process was considerably more complicated than the official architecture diagram suggested.

Remember Bob?

Retired.

Still somehow responsible for half the integrations.

And Jeannine?

Apparently the organization’s undocumented enterprise service bus.

Now that we’ve discovered the process, let’s do something useful.

Let AI write the first draft of the documentation.

Why start with a blank Word document?

We’ve already gathered evidence.

We have system configurations.

Scheduled jobs.

Stored procedures.

Existing documentation.

File movement.

Logs.

And, hopefully, explanations from the people who actually perform the work.

Give AI the evidence it’s authorized to examine and ask it to construct a process description.

Not “Here is the definitive process.”

But, “Based on the available evidence, here’s how I believe the process works.”

That’s a very different statement.

And a much more useful one.

A Draft Humans Can Argue With

Imagine AI produces this:

Step 1: Vendor sends a CSV Monday afternoon.

Step 2: Jeannine downloads the attachment.

Step 3: Jeannine corrects invalid values in Column H.

Step 4: Jeannine renames the file and places it in a shared folder.

Step 5: SQL Agent loads the file Tuesday at 6:00 AM.

Step 6: A stored procedure transforms the data.

Step 7: Power BI refreshes.

Looks reasonable.

Until Jeannine reads it.

“We don’t change Column H anymore. The vendor fixed that last quarter.”

Then Finance reviews it.

“You’re missing the approval if the file contains more than 500 records.”

Then IT gets involved.

“That SQL Agent job was replaced with a Fabric pipeline two months ago.”

And Bob?

Well, Bob is enjoying retirement.

As he should be.

But apparently someone forgot to tell the documentation.

This is exactly what we want.

AI created something people could review.

The business corrected it.

IT verified the technical details.

And suddenly, instead of asking everyone to remember every step from scratch, we’re having a conversation about specific discrepancies.

A draft humans can argue with is often more valuable than a blank page nobody wants to fill.

But Who Gets to Say It’s Correct?

Here’s where governance enters the picture.

Again.

Because AI can propose documentation.

• Jeannine can verify what she does.
• IT can verify what the systems do.
• Finance can verify the business rules.

But someone needs to decide whether that represents the approved process.

And that’s not necessarily the person who wrote the document.

It’s the process owner.

A process owner should be able to say:

“Yes, this describes how the process works.”

And, separately, “Yes, this is how the process is supposed to work.”

Those are two very different statements.

Current Doesn’t Mean Correct

Suppose AI perfectly documents the existing workflow.

• Vendor sends file.
• Jeannine downloads file.
• Jeannine fixes data.
• Jeannine renames file.
• Jeannine uploads file.

Automated process continues.

Awesomeness.

We’ve captured reality.

But have we captured the process the organization actually wants?

Maybe Jeannine shouldn’t have to fix the file.

Maybe the vendor should correct its data.

Maybe the manual upload should be automated.

Maybe Finance’s approval belongs in a workflow system instead of someone’s inbox.

Maybe the entire spreadsheet should disappear.

Accurately documenting a bad process doesn’t make it a good process.

AI can help us discover what happens.

It can help draft the documentation.

It can identify apparent inconsistencies.

But the business still has to decide what should happen.

That decision belongs to the people accountable for the process.

Not the model.

Approval Isn’t the End

Now imagine we get everything right.

The business approves the process.

The documentation is published.

It has an owner.

A version number.

An approval date.

Maybe even a link from the data catalog.

Beautiful.

We’re done.

Right?

Of course not.

We’ve just started the clock.

Because every process document has a problem.

The moment it’s approved, reality begins looking for ways to make it obsolete.

Documentation Needs an Expiration Date

I’m not suggesting every document should automatically become invalid after six months.

But I am suggesting that important process documentation needs an actual review date.

A reason for someone to look at it again.

For example:

• Process Owner: Finance Operations
• Version: 2.3
• Approved: April 1, 2026
• Next Review: October 1, 2026
• Status: Approved

Now we know who owns it.

We know when it was last verified.

And we know when someone should look at it again.

But there’s another opportunity here.

Why wait six months if something significant changes tomorrow?

We Monitor Schema Drift. Why Not Process Drift?

In data architecture, we’re familiar with drift.

Schema drift.

Data drift.

Configuration drift.

Model drift.

We build monitoring to detect when something changes unexpectedly.

But what about process drift?

Suppose the approved process says:

Vendor File → Manual Review → Shared Folder → SQL Agent Job → Database → Report

Six months later, the actual process is:

Vendor API → Automated Validation → Fabric Pipeline → Azure Database → Report

That’s a significant change.

Maybe it’s a wonderful change.

We’ve eliminated manual work.

We’ve modernized the integration.

We’ve made the process more reliable.

But the documentation still tells Jeannine to download a CSV.

And now someone asks AI, “How does this process work?”

If AI retrieves the approved but outdated document, it may confidently describe a process that no longer exists.

We’ve seen this problem before.

Your AI is using the draft nobody approved.

Except this time, the document was approved.

It just stopped being true.

AI Can Help Detect the Difference

Imagine giving AI access to the appropriate evidence about the approved process and its actual operation.

The approved documentation says, “SQL Agent executes the load at 6:00 AM.”

But the SQL Agent job is disabled.

The Fabric pipeline now runs at 7:00 AM.

The old shared folder hasn’t received a file in months.

The new integration has been running successfully.

AI can identify those differences and prepare a review:

Potential Process Drift Detected

Approved Process: SQL Agent loads vendor CSV.

Observed Evidence: Fabric pipeline loads data from vendor API.

Last Verified: April 1, 2026.

Suggested Action: Request process owner review.

That’s useful.

Not because AI automatically knows the new process is correct.

But because it can help identify that the documented process and the observed process no longer agree.

Of course, this requires the relevant systems, metadata, and evidence to be available.

AI isn’t going to discover a job schedule change in a system that it cannot inspect.

Observed Behavior Isn’t Authority

This might be the most important point in the article.

Just because something is happening doesn’t mean it’s supposed to happen.

Imagine the approved process says, “Vendor files must pass automated validation.”

Then the validation fails.

Jeannine creates a temporary workaround to get the month’s reporting completed.

AI observes the workaround.

Should it immediately update the official process?

Absolutely not.

Otherwise, three weeks later, our corporate documentation might proudly announce, “Step 4: Email Jeannine and ask her to fix it manually.”

Congratulations.

We’ve automated the institutionalization of bad habits.

The observed behavior is evidence.

It may represent a legitimate change.

It may represent a temporary exception.

It may represent a control failure.

It may represent someone bypassing an approval.

AI should flag the difference. It shouldn’t automatically decide that the difference is the new standard.

That’s what process owners and governance are for.

A Process That Reviews Itself

Now we’re getting somewhere interesting.

Instead of treating documentation as a one-time project, imagine a continuous cycle.

Discover → Draft → Verify → Approve → Publish → Observe → Detect Drift → Reverify → Update

AI helps discover the process.

AI prepares a draft.

The people doing the work correct it.

The business owner approves it.

The authoritative version is published.

Systems and processes continue operating.

AI periodically compares available evidence against the approved process.

Potential changes are flagged.

The business reviews them.

Documentation gets updated when appropriate.

Then the cycle begins again.

That’s not just faster documentation.

That’s documentation with a maintenance strategy.

And it doesn’t require AI to make every decision.

In fact, the model is most useful when it knows which decisions belong to someone else.

The Sherpa’s Notebook

One of the most frustrating things about working with legacy systems is discovering that the documentation describes a world that no longer exists.

I’ve seen procedures that reference old servers.

Jobs that were replaced years ago.

Processes that depend on someone who left the company.

Comments that explain why something was done in 2014, even though the business rule changed in 2021.

And sometimes the documentation isn’t entirely wrong.

That’s almost worse.

Because 80% of it is accurate.

The other 20% is where the trouble lives.

You follow the runbook.

Everything looks reasonable.

Then you discover the step that changed two years ago.

Nobody updated the instructions.

And suddenly you’re troubleshooting a process that only exists on paper.

This is where AI-assisted comparison could save enormous amounts of time.

Not by pretending to understand every undocumented business decision.

But by identifying evidence that contradicts what we’ve approved.

“This document says the job runs nightly. The job has been disabled for eight months.”

That’s a conversation worth having.

Don’t Turn Every Change Into a Crisis

There’s a balance here.

We don’t need an emergency governance meeting every time someone changes a job description or renames a file.

Not every difference is meaningful.

Some changes are cosmetic.

Some are temporary.

Some are expected.

Some are already covered by the approved process.

What matters is whether the change affects the business outcome, control, ownership, dependency, or behavior.

A changed server name may simply require a technical documentation update.

A removed approval step?

That’s another conversation entirely.

AI can help prioritize these differences.

But the organization needs to define what constitutes a material change.

Otherwise, congratulations, you’ve created a documentation monitoring system that nobody reads because it generates 400 alerts every Tuesday.

And we’ve already discussed how well that works.

The Documentation Itself Needs Metadata

There’s another connection to our earlier articles.

Remember when AI retrieved the draft nobody approved?

That was an authority problem.

This is related.

A process document should carry enough metadata for both people and systems to understand its status.

• Who owns it?
• Who approved it?
• When was it approved?
• Which version is authoritative?
• When was it last verified?
• When should it be reviewed?
• What systems does it describe?
• Has it been superseded?

Without those details, AI may find five different process documents and have no reliable way to determine which one should be trusted.

Retrieval isn’t authority.

And now we can add:

Approval isn’t permanent proof of accuracy.

The document was correct when it was approved.

That doesn’t guarantee it’s correct today.

The Goal Isn’t More Documentation

We don’t need AI generating thousands of pages that nobody reads.

We already have enough documentation nobody reads.

The goal is to create documentation that people can actually trust.

• Documentation that reflects the process.
• Documentation that has an owner.
• Documentation that distinguishes observed behavior from approved behavior.
• Documentation that gets reviewed.
• Documentation that can be corrected when the business changes.
• Documentation that AI itself can use without accidentally treating a temporary workaround as corporate policy.

That’s a much more valuable outcome than simply producing documents faster.

The Sherpa’s Lesson

AI can help us discover the processes nobody documented.

It can help write the first draft.

It can help identify where the documentation disagrees with reality.

But it shouldn’t be the final authority on what the business is supposed to do.

• Let AI discover.
• Let AI draft.
• Let the people doing the work verify.
• Let the process owner approve.
• Let AI help identify when reality changes.
• Let the business decide what happens next.

Because documentation isn’t something you finish.

It’s something you verify.

Six months ago, your documentation may have been absolutely correct.

The question isn’t whether it was right when someone approved it.

The question is, do you still have a reason to trust it today?