Content Production System Setup

A content production system turns an approved opportunity into a reviewed, published, and measurable URL through shared specifications, roles, workflow states, capacity limits, evidence, and quality gates. It is not simply a calendar or a faster drafting method.

Phase: P10, Content Production System Setup. Stage: C — Build. Timebox: 5–10 working days to design and pilot one representative batch; allow 2–4 weeks when several brands, languages, regulated approvals, or CMS teams share the workflow. Owner: content operations lead or managing editor. The SEO strategist owns search requirements, the subject-matter expert owns factual review, the publisher owns implementation, and one named business owner approves release risk.

This is where all three playbook pillars become an operating system. The process controls movement and accountability. The post-type library supplies reusable page specifications. The element library supplies the answer blocks, tables, warnings, FAQs, sources, calls to action, and other components each page uses. Production starts only when those parts are joined.

Why this phase, and why here

P10 consumes decisions made earlier. The topical map supplies one page job, one intended URL, one post type, priority, and required link relationships. The content inventory and audit supplies the disposition of existing material: keep, improve, merge, create, or retire. Research supplies the audience language, prompts, queries, competitor evidence, and source candidates. Brand and technical discovery supply claims, restrictions, CMS constraints, and measurement requirements.

Those dependencies explain why the system is installed now. Before P10, the team decides what deserves to exist; afterward, it must produce approved pages consistently. Starting before node ownership and existing-page disposition are settled turns uncertainty into duplicate drafts. Designing the workflow before post types and elements are known creates stages that cannot test the page contract.

Skipping this phase replaces a visible process with private habits. Writers interpret briefs differently, editors repair recurring omissions, and reviewers enter too late. Adding writers or an AI agent then increases arrivals at the same review bottleneck until the queue fills with rework.

The core migration is from the one-off content brief to a versioned specification. A brief can still carry page-specific research. It should no longer redefine the format, required elements, metadata rules, evidence standard, link obligations, or acceptance test for every assignment. Those recurring decisions belong in shared post-type and element contracts.

Inputs and outputs

The next phase should receive a finished, traceable page, not reconstruct what “approved” meant.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

The checklist

1. Define roles, authority, and handoffs

• What: Name who writes, edits, verifies facts, reviews search requirements, approves claims, implements the page, runs QA, and authorizes publication. Define the AI agent’s bounded tasks separately.
• Why: A role label without decision authority creates review theater. Three people may comment while nobody can accept or reject the page.
• How: For each state, record the responsible operator, one accountable approver, consulted specialists, response time, and escalation path. For AI work, list allowed inputs and outputs, prohibited claims, required review, and human owner.
• Tool: Use the delivery tracker for ownership. Use AmICited agent configuration or connected AI-client instructions for machine boundaries; do not hide authority inside a prompt that reviewers cannot inspect.
• Done when: Every state has exactly one accountable human, no person is both sole author and sole approver for high-risk pages, every AI action maps to a human owner, and unanswered reviews escalate after a stated interval.

2. Turn post types and elements into versioned specifications

• What: Select the post types used in the next 90 days and adopt a controlled set of elements for each.
• Why: Teams cannot achieve consistency from examples alone. A specification makes structure testable and separates mandatory requirements from editorial choice.
• How: For each active post type, record its reader job, section order, required and optional elements, evidence, metadata, schema, links, CTA logic, and rejection conditions. Give each contract an owner, version, date, and change log. Reference shared element rules instead of copying them.
• Tool: Use the playbook libraries as the source contract and the CMS or issue template as the implementation surface.
• Done when: 100% of pilot items reference exactly one post-type version; every required element has an acceptance test; and two editors independently reach the same pass/fail result on a sample page.

3. Migrate useful brief material without carrying over brief debt

• What: Separate page-specific evidence worth keeping from repeated instructions that should be removed or centralized.
• Why: Copying old briefs into a new template preserves contradictions, stale advice, and keyword-driven headings. Discarding everything loses customer language, source work, and stakeholder decisions.
• How: Keep the audience problem, page job, URL, query and prompt evidence, useful competitor examples, sources, unique claims, product facts, links, conversion action, and risks. Move recurring tone and terminology into the style guide . Replace copied structure with the post-type version. Discard keyword-density targets, imitation requests, arbitrary word counts, boilerplate, unsupported statistics, and tool-suggested headings without a reader purpose.
• Tool: Use a migration worksheet with columns for keep, move to shared rule, validate, and discard; attach retained evidence to the production issue.
• Done when: Every pilot brief has been classified line by line, no global rule is duplicated in the issue, every retained claim has a source or owner, and the writer can identify the contract version without reading a legacy document.

4. Design the workflow states and entry criteria

• What: Define how work moves from an approved node to a published URL, including blocked and returned states.
• Why: Status names such as “in progress” conceal whether the page is waiting for evidence, writing, expert review, CMS work, or a decision. Hidden waiting time makes capacity impossible to plan.
• How: Use explicit states: ready, drafting, editorial review, expert review, approval, implementation, pre-publish QA, published, and blocked. Set entry evidence, owner, exit evidence, timing, and return path. Every return records a reason code.
• Tool: Configure the tracker; link drafts, sources, AmICited article IDs, CMS previews, QA records, and final URLs from the same issue.
• Done when: No state lacks entry and exit criteria, every item has one current state and owner, blocked work names the dependency and next action, and the pilot produces a complete timestamped history.

5. Plan throughput from the bottleneck

• What: Set a sustainable weekly release rate from the slowest required stage, not from drafting capacity.
• Why: If writers create 20 drafts while expert review can clear 6, the system produces 14 additional waiting items, not 20 units of progress. Queue age then forces rushed reviews and stale research.
• How: Divide available hours by observed handling time for each role and use the lowest stage capacity as the initial ceiling. Set work-in-progress limits and reserve 20% of specialist capacity for returns, urgent corrections, and maintenance. Release connected batches whose links can ship together.
• Tool: Delivery tracker plus a simple weekly capacity table showing demand, capacity, queue, age, and blocked count by state.
• Done when: Planned starts do not exceed the bottleneck’s weekly capacity, work-in-progress limits are visible, every priority item has capacity at all required stages, and a named owner decides what leaves the batch when demand exceeds capacity.

6. Configure AI ownership and human controls

• What: Assign AI agents bounded work such as gathering approved context, drafting specified elements, checking required fields, suggesting internal links, or preparing a first-pass QA report.
• Why: Generative AI can reduce repetitive assembly, but it cannot own organizational accountability or know whether a confidential, regulated, or newly changed claim is safe to publish.
• How: Define approved sources, retrieval date, specification version, output schema, prohibited actions, missing-data behavior, and mandatory review. Require exposed sources and uncertainty. Keep publishing, destructive CMS changes, legal approval, and novel claims behind an explicit human decision.
• Tool: Use SEO Agents at app.amicited.com/agents for configurable workflows, or SEO MCP to expose live AmICited context to an approved MCP client.
• Done when: Every automated step has test cases, audit output, permission boundaries, failure behavior, and a human owner; the pilot includes at least one forced missing-source or conflicting-instruction test that fails safely.

7. Wire the QA gate before increasing volume

• What: Make quality checks a required workflow state with blocking failures, evidence, and exception authority.
• Why: Retrofitted QA becomes cleanup because dates and stakeholder expectations are already committed. A gate designed on day one shapes the specification and exposes expensive requirements before the queue grows.
• How: Apply the pre-publish QA checklist to the issue template. Test page job, required elements, facts, originality, metadata, headings, links, media, schema, accessibility, canonical behavior, rendering, analytics, and CTA. Separate block, return, and warn outcomes. Exceptions need a risk owner, expiry, and remediation date.
• Tool: Tracker automation, CMS preview, link and schema checks, AmICited evidence views, and human review of meaning and claims.
• Done when: 100% of pilot pages carry a completed QA record, every blocking failure prevents release, every exception has approver and expiry, and no check exists only as an editor’s remembered habit.

8. Run a representative pilot and revise the system

• What: Process 3–5 varied items through the complete workflow before scaling: include at least one new page, one substantial update, one evidence-heavy page, and one AI-assisted draft where applicable.
• Why: A single easy article cannot expose expert-review delays, merge dependencies, CMS limitations, or permission failures. Variation tests the operating model rather than the writer.
• How: Capture handling and waiting time, returns, reason codes, missing inputs, first-pass acceptance, QA failures, and exceptions. Review the batch and change the system when evidence identifies a repeatable problem.
• Tool: Tracker timestamps, AmICited draft and agent records, CMS preview history, and QA evidence.
• Done when: Every pilot item reaches a final disposition; the team can explain all waiting and rework; repeated defects have a system-level fix and owner; and approvers sign off on the initial throughput ceiling.

Tools in AmICited

Save the prompts, content type, instructions, sources, agent or flow version, and review outcome with the issue.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Decision rules

These are launch controls. Replace a threshold only when pilot evidence supports a better one, and record the change before increasing volume.

Quality and role controls

• Because hidden ownership turns defects into arguments, bad means any workflow state has no responsible operator, no accountable human, or no escalation time. Production stops until ownership is assigned.
• Because structural consistency must be testable, bad means more than 5% of pilot requirements cannot be marked pass or fail from the specification. Rewrite ambiguous requirements before the next batch.
• Because a quality gate is meaningless when routinely bypassed, bad means any page publishes with an unresolved blocking failure, or more than 10% of a four-week release set uses exceptions. Review the specification, capacity, and approval pressure rather than normalizing waivers.
• Because facts require traceability, bad means any material factual, comparative, medical, legal, financial, security, performance, pricing, or product claim lacks an approved source and retrieval date. The claim is removed or returned for evidence.
• Because machine speed cannot assume human authority, bad means an AI agent can publish, delete, change permissions, or introduce an unsupported claim without a logged human approval appropriate to the risk.

Flow and capacity controls

• Start with no more than two active items per person per workflow state. A third item waits in ready status unless the owner records why parallel work reduces, rather than increases, cycle time.
• Flag a queue when waiting work exceeds one week of that stage’s demonstrated capacity. Freeze new starts into the queue and resolve the bottleneck first.
• Flag an aging item when it spends more than twice the state’s agreed service time without a recorded blocker. Escalate it to the accountable owner.
• Treat a first-pass acceptance rate below 80% across at least five comparable items as a system defect. Classify returns before blaming the writer: missing input, unclear specification, factual gap, brand mismatch, structure, implementation, or reviewer disagreement.
• Do not increase the weekly release ceiling by more than 25% from one completed batch to the next. Raise it only when blocking QA failures are zero, exceptions are below 10%, and the bottleneck has spare capacity.
• Reserve 20% of specialist review capacity until two consecutive batches show that returns and urgent corrections fit below that reserve. Unused reserve can serve refresh work; it is not permission to start unreviewable drafts.

Deliverable: the production system pack

Hand over one versioned folder or workspace backed by a tracker. It must contain the operating manual, not merely links to drafts:

System owner and effective date
Role / authority / escalation matrix
Workflow states with entry and exit criteria
Active post-type specifications and versions
Element rules and CMS implementation mapping
Specification-backed production issue template
Legacy brief migration record
AI agent instructions, sources, permissions, tests, and human controls
Capacity model, WIP limits, review service times, and batch policy
Pre-publish QA gate, evidence schema, exception policy, and expiry rules
Pilot items with timestamps, returns, approvals, QA records, and final URLs
Baseline metrics and change log

The authoritative production issue includes:

Node ID | Page job | Audience | Market / language | Post type + version
Target / canonical URL | Existing-page disposition | Queries and prompts
Required elements | Required evidence and sources | Claims requiring approval
Inbound and outbound links | CTA | Owner | Reviewers | Approver
AI assistance and run record | Current state | Due date | Blockers
QA result | Exceptions and expiry | Published URL | Measurement annotation

The handoff is accepted when a new operator can move one ready item through the workflow without asking which format, requirements, approval, or proof applies.

What goes wrong

The old brief gets a new filename

The document is renamed but still mixes reusable structure, page research, comments, and keyword suggestions. Separate contracts from evidence and version the contract.

Draft throughput is mistaken for production throughput

An AI tool creates 30 drafts, but experts can review 6. The extra 24 age in a queue. Plan releases from the bottleneck and cap work in progress.

Roles describe activity but not authority

“Marketing reviews” does not say who can reject a claim or resolve disagreement. Give each state one accountable human and an escalation boundary.

AI receives more access than the task requires

Broad credentials let a drafting agent modify live pages. Grant the minimum scope, test failure behavior, and keep risky actions behind approval.

QA is a final proofreading pass

Proofreading happens after CMS entry while intent, evidence, links, schema, accessibility, and analytics go untested. Wire them into specifications and block failures.

Editors repeatedly repair the same omission

If every draft lacks sources or a direct answer, update the specification, template, or agent instruction. Repeated defects belong to the system owner.

Exceptions become the normal path

When “publish now, fix later” has no owner or expiry, exceptions become the process. Above one waiver in ten releases, repair the conflicting capacity or requirement.

The system works only for easy articles

Easy new posts hide merge work, product claims, localization, expert review, and CMS constraints. Test representative variation before announcing capacity.

Next phase

The next phase, on-page optimization, receives published or implementation-ready pages whose purpose and structure are already settled. It needs the node ID, canonical URL, target queries and prompts, post-type and element versions, approved copy, evidence record, metadata, planned links, CMS preview, QA result, and measurement annotation.

On-page optimization should refine titles, descriptions, headings, body relevance, entity clarity, media, structured data, internal links, and conversion paths. It should not have to decide the page’s fundamental job, invent missing evidence, or resolve who can approve a claim. If those questions reappear, return the item to P10 rather than hiding a production-system failure inside optimization work.

FAQ

Is a content specification just a longer content brief?

No. A brief usually collects advice for one assignment. A specification defines a reusable page contract: the reader job, post type, required and optional elements, evidence, metadata, links, acceptance tests, and ownership. Keep useful research from the brief, but move repeatable rules into the shared specification.

Should AI-generated content go through a different review process?

It can have an additional provenance check, but it should not have a weaker quality bar. Every draft must pass the same accuracy, post-type, element, link, metadata, brand, and technical checks regardless of who or what produced the first version.

How do we increase content throughput without lowering quality?

Increase completed capacity only after measuring each workflow stage. Remove repeated decisions through specifications, reuse approved elements, limit work in progress, and relieve the actual bottleneck. Do not raise draft volume when review or approval already has a queue.

Who is accountable when an AI agent writes the first draft?

A named human approver remains accountable for publication. The AI agent may own bounded execution tasks such as assembling evidence, drafting specified elements, checking required fields, or proposing links, but it cannot accept legal, factual, brand, or commercial risk on behalf of the organization.

When is the production system ready to launch?

It is ready when a representative pilot batch can move from approved node to published page with named owners, versioned specifications, capacity limits, evidence attached, all QA gates passed, and no requirement that exists only in someone’s memory.