Configuring Editorial Governance Around Existing Business Processes, Not the Reverse

Here is the failure mode enterprise content leaders know too well: legal signs off on a new disclosure requirement, but the CMS only supports a two-step approve-then-publish flow, so the compliance reviewer gets bolted on as an informal email step that nobody can audit. The tool dictated the process, and the process quietly stopped matching how the business actually works.

Configuring editorial governance around existing business processes means attaching the primitives you need (versioning, role-based edit, review gates, scheduled release, and rollback) to the workflow your organization already runs, rather than reshaping the workflow to fit the CMS. In Sanity, those primitives are configuration on a content model, not a code path only engineering can touch, so Brand, Product, Support, and Compliance each own their part without filing a pull request.

This article reframes governance as something that wraps your existing operating model instead of replacing it. The rule of thumb, borrowed from teams shipping governed AI behavior in production, is simple: author it like content, gate it like code.

Why does the CMS end up dictating your editorial process?

The CMS ends up dictating your editorial process because legacy platforms ship a fixed workflow engine, and the path of least resistance is to bend your organization to fit it. When a platform offers a single linear approval chain, every real-world variation gets forced through it: the regional legal reviewer becomes an out-of-band email, the brand check becomes a Slack thread, and the emergency correction becomes a direct-to-production edit that skips review entirely. None of those exceptions is captured, versioned, or audited, which is precisely the material an auditor asks for first.

This is upside down. In most teams, the rules that govern customer-facing content live where the wrong people can reach them and the right people cannot. The marketing team cannot read the governance logic, the compliance team cannot review it, and the support manager cannot update escalation language, so when something embarrassing ships, the fix is a pull request and the drift goes unnoticed for a sprint. The tool decided who could change what, and the answer was engineering.

The reframe is to treat your existing business process as the source of truth and the platform as configurable around it. Your approval chain already exists, encoded in who signs off on what and in which order. A modern system should let you express that chain as configuration on the content model itself: which roles can edit which fields, which changes require review, and when a batch of changes ships. Legacy DXPs stop at publishing. The goal is a system that operates content end to end, so the governance you designed on paper is the governance the platform enforces, without a reimplementation every time the process evolves.

What does 'author it like content, gate it like code' mean for governance?

"Author it like content, gate it like code" means the artifacts that govern your content (approval rules, brand voice guidance, escalation language, and forbidden-topics lists) should be editable by the teams who own them while still passing through validation and review on the way out. The real choice was never content-loose versus code-rigorous. It is governed, with the right people able to edit and a test gate on the exit, versus a string only engineering can touch. You want both, and you want them in the same system.

Consider a customer-facing policy statement. The old model puts it in a codebase, so a wording change from Compliance becomes a ticket, a pull request, a code review, and a deploy window. The content model that Compliance actually cares about is invisible to them, and the change is slow enough that people route around it. Authoring it like content means Compliance edits the statement directly in the Studio. Gating it like code means that edit still moves through drafts, validation, and a review gate before it reaches production, with full version history and rollback if it goes wrong.

The operational payoff is that governance stops being a separate discipline layered on top of publishing and becomes a property of the content itself. Drafts, scheduling, version history, permission gating, audit trails, and rollback are the same primitives you already use for a homepage change, now applied to the rules that govern behavior. The release that ships a homepage change ships a policy change. That collapses two review pipelines into one, which is fewer places for an unreviewed change to slip through and one audit trail to hand an auditor.

How do you split a governed artifact so the right team owns each part?

You split a governed artifact into fields, and you assign edit permission per field to the team that actually owns that part of the process. Splitting a governed document into fields is not cosmetic. It is access control. In a governed prompt or policy, Brand owns voice, Product owns how user context is used, Support owns escalation, and Compliance owns the never-say list. None of them files a pull request, and none of them waits for a deploy, because each field is theirs to edit inside the same document.

This maps directly onto Roles & Permissions in an enterprise editorial estate. Instead of a single blunt editor role, you model the ownership boundaries that already exist in your org chart. The compliance officer can edit the forbidden-topics list and nothing else. The brand lead can revise voice guidance without the ability to alter escalation logic. Every edit is attributed, versioned, and captured in Audit logs, so the question "who changed this rule, and when" has a first-class answer rather than a reconstruction from email.

This is not a hypothetical. It is what teams ask for once they have shipped something real. Vipps came to Sanity wanting the whole organization to contribute to prompt writing, with product managers owning it rather than engineers. That is the tell: once an artifact governs customer-facing behavior, it stops being code and becomes a thing many teams have a stake in. Field-level ownership lets each of those teams operate at once, safely, on the same document, which is the thing a code path fundamentally cannot offer because the codebase has exactly one gate and it belongs to engineering.

How do you stage and preview governance changes before they ship?

You stage governance changes the same way you stage a website: as a batch you can preview in full before you ship it, then release or roll back as a unit. This is what Content Releases provides. Rather than editing rules live and hoping the combination behaves, you assemble the whole set of changes (the new disclosure wording, the updated escalation path, and the revised brand voice for a campaign) into one release, preview the result, get sign-off, and ship them together on a schedule.

The enterprise problem this solves is the coordinated change. Real governance updates rarely touch one field. A regulatory shift might require new language in a policy, a new approval step, and a change to what content is even allowed to publish, all of which must land at the same moment or not at all. Editing them piecemeal in production creates a window where the estate is internally inconsistent, which in a regulated context is exactly the window an audit or an incident finds. Batching them into a preview-then-ship release closes that window.

This is the enterprise equivalent of git branching for editors, without asking editors to learn git. You get drafts, scheduling, history, permission gating, and audit trails, the governance you already use for the website, now applied to the rules layer. Preview before you ship, and if the released batch causes a problem, roll it back as cleanly as you shipped it. Legacy DXPs typically require a release window and a coordinated deploy to move a set of governed changes; the point of Content Releases is to make a coordinated governance change a scheduled editorial action rather than an engineering event.

How does governance apply when an AI agent or automation acts on content?

Governance applies to an AI agent or automation by having it inherit the security model you already run, rather than standing up a parallel set of AI-specific controls. When an agent acts on behalf of a user, it should carry that user's token, which means it gets the same row-level permissions, the same rate limits, and the same regulatory boundaries the human has. You do not build "AI security" as a separate discipline. You make sure the token flows, and the action is logged against the user, not the model.

This is the governance answer to the EU AI Act era of enterprise content: auditability of automated changes is not a bolt-on, it is a property of forwarding the existing identity. If a Function enriches a product description or a translation workflow updates a market variant, the edit lands in the same Audit logs, attributed and reversible, as a human edit would. The agent does exactly what the user could do and nothing more, so the permission model you designed for people governs the machines too. That is the difference between a CMS that bolts AI onto the side and a system built for it from the content model up.

The institutional framing matters here. Sanity, the Content Operating System for the enterprise, is designed to be the intelligent backend for companies building AI content operations at scale, which means automation is a first-class actor inside the governance model rather than an exception carved around it. Functions and the App SDK let you automate translation, moderation, and compliance checks, and because those automations forward the user's identity, every automated action is as traceable and as constrained as the manual one it replaces. Scale output through automation without scaling the number of people who can bypass a review gate.

How do you model a multi-brand, multi-market estate without cloning governance?

You model a multi-brand, multi-market estate by expressing shared governance once and layering the differences per brand or market, rather than cloning an entire workflow for each and maintaining them in parallel. Studio Workspaces let you model a multi-brand, multi-market estate in one place, so the common approval logic, the shared compliance rules, and the base content model are defined centrally, and each market configures only what genuinely differs, such as a local legal reviewer or a market-specific forbidden-topics entry.

The failure mode this avoids is governance drift across a large estate. When each brand runs a separate CMS instance or a duplicated workflow, the compliance update that lands in the flagship market takes weeks to propagate to the others, and the ones that lag are the audit exposure. A single modeled estate means the rule change is made once against the shared foundation and inherited everywhere, with per-market overrides where the business genuinely requires them. This is the "model your business" principle: the system matches how the enterprise operates, with real markets and real ownership, instead of forcing every market through an identical mold.

Content Lake sits underneath this as a multi-tenant, multi-region content store, which means data residency and regional hosting are a modeling decision rather than a separate infrastructure project you operate yourself. Combined with SSO for identity, Roles & Permissions for who-can-do-what, and Audit logs for traceability, an enterprise gets a shared governance foundation across markets without the silos that come from stitching together brand-by-brand installs. The governance is centralized where it should be consistent and delegated where it should be local, which is how the business actually runs.