AI Publish Screen

Screens content against your site's own editorial policy at the moment an editor publishes it, shows what it found, and lets the editor decide.

What it does

When an editor saves a node as published, the module sends the content and your editorial policy to a chat model and asks what breaches the policy. If anything comes back, the save is blocked and the editor sees the list. They can fix the content, or tick a box to publish anyway. Ticking the box writes the flags into the revision log.

It is a gate, not a filter:

• It never edits content. The editor writes, the screen only reports.
• It never blocks a publish outright. Every flag can be overridden. A tool that can veto a publish becomes a tool people route around.
• The override is recorded. "We published it anyway" becomes something you can find later instead of a gap.

Nothing is screened until you configure it. A content type with no policy selected costs nothing: no panel on its form, no model call.

Why

Editorial policies get written and then not read. This puts the policy in front of the person publishing, at the moment they publish, without taking the decision away from them. What you get afterwards is a record: when something went out against policy, a named person decided that on a specific date, and the reasons are attached to the revision.

Requirements

• AI, with a working chat provider
• Context Control Center (ai_context), where the policy is stored
• Content Moderation is optional, and used if present

Install

composer require drupal/ai_prepublish_screen
drush en ai_prepublish_screen -y

Configure

1. Write your editorial policy as an AI context item at /admin/config/ai/context/items. Write it as conditions on finished text ("flag X", "never use Y"), not as advice for producing text. A generation style guide screened against finished pages will flag almost everything.
2. At /admin/config/ai/prepublish-screen, pick which content types are screened and against which policy.
3. Set the model. Screening means holding a policy and a piece of writing in mind at once, and small models are measurably worse at it, so do not leave this on a mini model:

What it does not do

• Form saves only. A node published through the API, programmatically, or by an agent is not screened. The gate is a conversation with a human.
• Nodes only.
• No queue or batch. There is no report across content you have already published.
• No defence against prompt injection. An editor can write "ignore the policy" into the content and talk the model out of a verdict. That is not worth hardening, because the same editor already has a checkbox that overrides every flag. Treat this as an aid to honest editors, not a control against hostile ones.