The article is approved. Why is it still not published?

The copy is good. The editor has finished. The verdict has been reviewed. The images exist.

And the article is still not live.

What remains is the work that rarely appears in the editorial calendar: map the sections to the website model, recover required fields, convert media, choose the right crop, write alt text, validate the structure, show the changes to a person, produce the final package and publish without losing the approved version.

For one client, IZZY turned that last mile into a system.

The Content Publication Framework does not replace the editor or soften a judgement so that it is easier to publish. It receives an article, analysis or research piece in the editor’s working format. It checks the required logical blocks, proposes the transformations needed by the website, prepares the media and guides the user through several validation stages. Once approved, processing and publication switch to automatic mode.

The most important rule is simple:

Never invent missing information in order to publish.

If a required element is absent, validation fails. The framework does not fill the gap with something plausible.

The answer in 60 seconds

• Source files can arrive in different formats, provided that the required logical blocks for the content type are present.
• The framework supports different editorial families, including news, analysis and research articles.
• It maps the source material into the website’s required structure.
• Images are converted to WebP and fitted to their destination.
• The system proposes alt text and other permitted editorial fields when they are missing.
• The user reviews proposed changes through several validation stages; after acceptance, import, processing and publication run automatically through the web interface.
• Content states are versioned and rollback is supported.
• Missing mandatory information blocks validation instead of being invented.

The framework automates the publishing workshop. It does not automate editorial authority.

In this article

1. Editorial work does not end at “approved”
2. Flexible input, strict output
3. The journey from import to publication
4. Treat media as content
5. Validate before switching to automatic mode
6. Why “do not invent” is a product feature
7. Version, publish and retain a way back
8. When this framework helps, and when a CMS is enough

1. Editorial work does not end at “approved”

An editorial team produces intellectual material. A website expects a technical object.

Between the two, the same piece may need to become:

• a title and introduction that fit the page model;
• a body divided into CMS-compatible blocks;
• a conclusion or verdict in a specific field;
• media in the right formats and dimensions;
• alternative descriptions;
• categories, metadata or a required file structure;
• a state that can be checked and released.

When editors work in different formats, this transition often depends on one person who knows the site’s conventions. They may not change the substance. They translate approved material into the grammar of publication.

That role becomes a quiet bottleneck. The article is “finished”, but production is not. Delay hides inside a sequence of short, repeated tasks: open the CMS, split, upload, convert, rename, fill, preview, correct and publish again.

The framework makes that translation explicit and executable. If the upstream problem is producing content consistently in the first place, start with how a small team can create content without a full-time operation.

2. Flexible input, strict output

Forcing every editor into one writing template would simply move the burden upstream.

The system therefore accepts non-fixed inputs. The source does not need to use one file layout. It does need to contain the essential blocks required for the content type: introduction, body, conclusions, verdict or other destination-specific elements.

This distinction is the core of the design:

Flexibility protects the editorial process. Strictness protects the website and its readers.

3. The journey from import to publication

The framework runs through a web interface.

1. Import the approved material

The user supplies the article, analysis or research piece and its media. The system identifies the content type and available blocks.

2. Check the minimum contract

Before transformation, the framework validates required elements. If the destination requires a conclusion and none exists, the system does not silently write one. It exposes a validation that cannot be closed.

3. Transform towards the website model

The material is reorganised into the destination structure. Elements can be mapped to fields, blocks, files and metadata expected by the site.

4. Prepare the media

Images are converted, fitted to their placement and accompanied by the permitted proposals, including alt text.

5. Present the changes

The user moves through several validation stages and accepts or corrects the proposed transformations. The workflow does not confuse “the system can change this” with “the system is authorised to decide this”.

6. Switch to automatic execution

Once the choices are approved, the framework completes the processing and publication without asking the user to repeat the technical operations they have already authorised.

editorial material + media
             │
             v
 identify content type and blocks
             │
       minimum validation ── required data missing ──> stop
             │
             v
 website structure + media + metadata proposals
             │
             v
 staged human validation
             │
             v
 automatic processing ─> final package ─> publication
             │
             └────────────────────────────> versioned state / rollback

4. Treat media as content

An image is not a decorative file that can be compressed and forgotten.

Its meaning needs to survive the destination format.

In this framework, images are converted to WebP, stripped of their metadata and fitted to the dimensions of their placement. A vision check then warns the importer when an image looks wrong for its slot, for example a chart in the wrong language or a caption that does not match, so the problem is caught at review rather than after publication.

The system also proposes alt text.

This stage needs a hard boundary. Alternative text should communicate the relevant purpose or information of an image in context. It should not invent a person’s identity, an unreadable value or a conclusion the media does not show.

The same principle applies to categories and metadata. Some fields can be sensibly proposed from the content. Others are mandatory editorial or factual inputs and must be supplied or confirmed.

5. Validate before switching to automatic mode

The objective is not to interrupt the user for every technical operation.

It is to put approval before the point at which the system can continue without ambiguity.

The journey therefore has two modes:

1. Proposal mode: the system shows how it understood, structured and enriched the source. The user accepts or corrects the decisions.
2. Execution mode: after approval, the accepted transformations, final package and publication run automatically.

This avoids two bad extremes:

• automation that publishes before a person understands the changes;
• pseudo-automation that asks someone to approve every resize and filename.

The useful approval unit is not a technical click. It is the editorial or structural decision that authorises a family of actions.

6. Why “do not invent” is a product feature

Publishing systems are often optimised to finish.

A system that finishes at any cost can release a piece that looks complete while being factually incomplete. A model only needs to write a missing conclusion, pick an unjustified category or describe an image it misunderstood.

Here, missing information is a designed state.

When a mandatory input is unavailable:

• validation does not pass;
• the missing field remains visible;
• the user knows which contribution is required;
• the system does not manufacture a value to reach “published”.

This is less theatrical than automatic generation. It matters more in production.

A reliable publication system is defined not only by what it can produce, but by what it refuses to fabricate. The same rule governs our own editorial work; see how we use AI.

7. Version, publish and retain a way back

Automatic publication without history turns every error into an investigation.

The framework versions content states. This makes it possible to distinguish:

• the imported source;
• the proposed transformations;
• the accepted choices;
• the package that was actually published;
• an earlier state to which the content can return.

Rollback is not a promise of perfection. It recognises that a transformation accepted at review may still need to be withdrawn after publication because of a corrected fact, the wrong media, a new constraint or ordinary human error.

CMS platforms are increasingly exposing content as an operational surface. Wagtail 8.0, for example, documents authenticated create, edit, publish, unpublish, revision and revert operations in its current API preview (Wagtail documentation). That confirms the direction of the infrastructure; it does not remove the need to define permissions and states for each site.

8. When this framework helps, and when a CMS is enough

This kind of framework becomes useful when:

• several editors or teams supply heterogeneous source files;
• multiple content types share stable destination rules;
• media and metadata preparation repeats frequently;
• a package must satisfy a technical contract before publication;
• approval, versions and rollback need to be traceable.

It is probably excessive when:

• one person publishes occasionally;
• the CMS already accepts the working format cleanly;
• the page model changes faster than the rules can be maintained;
• the team expects the framework to replace editorial work;
• nobody owns the validation and rollback policy.

Automation is not justified by click count alone. It becomes valuable when the same transformation decisions can be described, controlled and reused.

Conclusion: automate the workshop, preserve the byline

The Content Publication Framework does not begin with a blank page.

It begins where the editorial team has already done the difficult work: choose the subject, build the argument, establish the facts and approve the content.

The system then handles a different discipline: turn that material into a compliant, accessible, versioned and publishable web object. It proposes. A person validates. It executes. When mandatory information is missing, it stops.

That is a useful boundary for AI in content operations:

Accelerate production without claiming editorial authority.

Frequently asked questions

Sources and limits

• The framework description comes from IZZY’s own project knowledge, recorded in August 2026. The client, its editorial content and its infrastructure details remain confidential.
• The Wagtail 8.0 documentation provides a current example of a content API covering creation, editing, publishing, unpublishing, revisions and reverts. It does not describe the IZZY client framework.
• Wagtail also frames AI adoption as optional and focused on content quality and operations rather than indiscriminate generation (Wagtail CMS).
• No time saving, publishing volume, error reduction, SEO performance or commercial outcome is claimed.