Beyond the Prompt: Building a Proposal-Based Workflow for AI Content Updates

AI should propose changes. Systems should decide whether those changes become reality.

Most AI systems are designed to generate content.

The problem is that production systems rarely need content generation.

They need content maintenance.

And maintenance is where AI becomes dangerous.

When you're building software for regulated environments, the challenge isn't creating version one.

It's safely updating version one after it's already been approved, deployed, audited, referenced, and relied upon.

That's where we started rethinking how AI should interact with content.

The Problem With Regenerate

Imagine you have a compliance training course containing:

• Regulatory references
• Knowledge checks
• Real-world scenarios
• Internal procedures
• Approval history

A regulation changes.

You need to update a single section.

Most AI systems approach this by sending the lesson to an LLM and asking it to regenerate the content.

Technically, it works.

Operationally, it creates a new problem.

The AI might:

• Rewrite surrounding content unnecessarily
• Change instructional tone
• Remove important references
• Alter lesson structure
• Introduce subtle inaccuracies

The update itself might be correct.

The rest of the lesson might no longer be.

In high-stakes environments, that's not acceptable.

Content Is Not A String

One of the design decisions we made while building CPDForge AI was to stop thinking about content as large blocks of text.

Instead, we treat content as structured documents.

A simplified model looks like this:

Course
 └── Module
      └── Lesson
           └── Section
                └── Content Block

That structure allows updates to be targeted precisely.

Instead of telling AI:

Rewrite this lesson

We can tell it:

Update this section

That distinction turns out to be surprisingly important.

Because once content becomes structured, AI no longer needs to touch everything.

It only needs to touch the thing that changed.

From Generation To Proposals

The next decision was even more important.

The AI never directly edits production content.

Instead, it generates a proposal.

Production Content
        ↓
AI Analysis
        ↓
Proposed Change
        ↓
Validation
        ↓
Human Review
        ↓
Approved Update

The model suggests.

Humans decide.

That simple shift dramatically improves trust.

Instead of treating AI as an author, we treat it as a contributor.

Granular Path Targeting

Because content is structured, updates can be scoped to specific locations rather than entire lessons.

Conceptually:

{
  "path": "modules[2].lessons[0].sections[4]",
  "action": "update",
  "reason": "regulatory_change"
}

The AI receives the affected section rather than the entire document.

This reduces content drift, limits unintended changes, and makes updates easier to review.

More importantly, it keeps the blast radius small.

The Preservation Problem

Even targeted updates create risk.

An AI can still:

• Remove required knowledge checks
• Drop regulatory references
• Break expected structure
• Change instructional intent

So every proposal must be validated before it reaches a reviewer.

Deterministic Validation

LLMs are non-deterministic.

Compliance systems shouldn't be.

Before a proposal can be approved, it must pass validation checks such as:

Schema Validation

Does the proposal still conform to the expected structure?

Required Component Validation

Are mandatory elements still present?

Citation Validation

Have required references been preserved?

Structural Integrity Validation

Does the update still fit within the expected hierarchy?

The objective is simple:

Prevent the AI from damaging content while attempting to improve it.

Human Review Still Matters

There is a temptation to automate everything.

We've found the opposite works better.

The AI identifies potential improvements.

The platform validates the proposal.

Humans make the final decision.

For regulated content, that distinction matters.

Not because humans are perfect.

But because accountability still matters.

AI As A Pull Request

The more we developed this workflow, the more it started to resemble modern software development.

Developers don't usually push unreviewed code directly into production.

They create pull requests.

Those pull requests are reviewed, validated, tested, and approved before being merged.

We're increasingly treating AI-generated content updates the same way.

The AI creates the equivalent of a pull request.

The platform validates it.

Humans decide whether it should be merged.

That model feels significantly safer than allowing direct mutation of production content.

The Bigger Lesson

This pattern extends far beyond compliance training.

The same principle applies to:

• Documentation systems
• Knowledge bases
• Legal content
• Internal policies
• CMS platforms
• Enterprise workflows
• Any system where correctness matters

The most valuable AI systems won't necessarily be the ones that generate the most content.

They'll be the ones that help organisations maintain complex information safely.

Content generation is rapidly becoming commoditised.

Content governance is not.

As builders, we spend a lot of time thinking about generation.

Increasingly, I think we should be thinking about maintenance instead.

Because once version one exists, the real challenge begins.

Questions For Other Builders

If you're building AI into a production system:

• Are you allowing direct mutation of live content?
• How are you validating AI-generated changes?
• What safeguards exist when the model gets it wrong?
• Are you treating AI as an author or as a reviewer?
• Have you adopted a proposal-based workflow similar to pull requests?

I'd be interested to hear how others are approaching this problem.