Publishing with Guardrails: How pr3sso Protects Every Release

Automation is most valuable when teams can predict its boundaries. A writing model should help create a strong draft, but it should not be able to bypass review, publish malformed content, or leave a repository half updated.

pr3sso treats guardrails as part of the product rather than a final checklist.

Models return proposals, not repository changes

The AI layer produces a structured post proposal. pr3sso parses that response against the content schema before it can enter the saving workflow.

Required identity, editorial, taxonomy, timing, and SEO fields are checked as data. The article body is checked separately against a restricted Markdown surface. Imports, exports, JSX, scripts, event handlers, and JavaScript expressions are rejected.

This creates a firm boundary: a model can suggest content, but it cannot decide the file paths or execute a repository operation.

One canonical identity follows the post

The post ID, publication number, slug, status, and title must agree between the metadata index and MDX frontmatter. The slug is derived from the title with one canonical normalization rule and checked again during the production build.

These rules prevent subtle failures such as an article appearing in an archive but returning a missing page, or a renamed title leaving an accidental duplicate URL.

Related records move together

A pr3sso draft is represented by an MDX source, a metadata index entry, and a conversation record. The repository service commits these changes together.

If the proposal is invalid, a destination conflicts with existing content, or GitHub rejects the update, pr3sso does not intentionally leave only part of the draft behind. The editor gets a failure to resolve instead of an inconsistent publication to repair later.

Public visibility is a data rule

Draft, published, and archived are explicit content states. A post becomes publicly visible only when it is marked published and has a publication timestamp.

That same predicate governs:

• article routes
• archives and taxonomy pages
• site search
• the RSS feed
• the XML sitemap

There is no separate search rule or feed rule that can accidentally expose a draft.

Credentials stay on the service side

GitHub OAuth credentials and model API secrets are handled by the admin service. Access tokens are not included in browser session responses, and model keys are not returned to the interface after configuration.

The optional Codex connection runs its content-generation session in a read-only sandbox. Repository writes still pass through the existing repository service and its validation path.

Dependable automation is visible automation

pr3sso does not promise safety by hiding more steps. It makes the important transitions legible: proposal, review, validation, commit, state change, and public render.

That clarity gives editors confidence to use AI where it is helpful and to keep human judgment where it is essential. Every release remains reviewable in the studio, traceable in Git, and predictable on the public site.