Comparisons
Does Pico Neural replace your CMS? No — here's the split
Pico Neural doesn't replace your CMS. The CMS manages and publishes; Pico Neural prepares and approves a version. Here's how the two roles divide the work.
No. The CMS manages and publishes; Pico Neural prepares and approves a version. That is the whole distinction, and it is worth stating plainly before anything else.
In practice: you have an article ready in the CMS, but before it goes live you want a person to have signed off on a specific version. By default, Pico Neural requires human approval of a version. Automatic publishing is turned on per site, and even then it still goes through the checks. So the CMS does not disappear. It stays the place where content is managed and published. Pico Neural works earlier, on the version to be approved, and on whether automatic publishing is on or off for that site. The useful question is not who wins. It is who does what.
Preparation and publishing: two separate jobs
The distinction that matters is between preparing a version and publishing it. Pico Neural is not a CMS and does not take its place. The CMS remains the context where content is managed and published. Pico Neural works on the version to be approved and, where it is switched on for a site, on automatic publishing, which stays subject to the checks. We do not attribute a content 'destination' function to Pico Neural: the facts cover approval of a version and automatic publishing per site. Keep that wording in mind when you design the workflow.
A four-step procedure (Pico Neural's proposal)
This is an operational proposal from Pico Neural, not a universal standard. Its purpose is to make clear who does what between the CMS and Pico Neural.
- Name the version to approve. Identify in the CMS the content that has to go through human approval. Example: the article 'A guide to AI visibility' is sitting in draft in the CMS.
- Approve that version. A person approves that specific version. Example: the editor approves version 3 of the article.
- Decide automatic publishing per site. Check whether automatic publishing is on or off for that site. Example: for the 'main blog' site it is off; for the 'newsletter' site it is on.
- Publish in the CMS. The CMS remains the place where content is managed and published. Example: the approved version is published by the CMS on the 'main blog' site.
Filled in, it looks like this: approved version = version 3; CMS destination = main blog; who publishes = the CMS; automatic publishing = off for that site, so a manual step is needed.
The point that often gets lost is that approval covers a version, not content in general. If the version in the CMS changes after approval, the approval does not automatically cover the new version. That is why our operational proposal is to name the approved version and to check, site by site, whether automatic publishing is on. This is not a content 'destination' function. It is a check on approval and publishing. Automatic publishing also stays subject to the checks: it is not a switch that removes verification. Keeping the two roles separate stops you from asking the CMS to do things it doesn't do, and Pico Neural to do things it doesn't claim.
A limit you can verify
The limit is this: we can say that the default is human approval of a version, and that automatic publishing is turned on per site and still goes through the checks. We cannot say that Pico Neural replaces the CMS, or that it handles publishing in its place. To go deeper on the flow and the checks, see the features page.