Prompt-Powered Content Assistant

The brief advanced

You have watched a "quick" LLM content experiment collapse before. Someone wires a prompt into a chat box, generates a blog post in thirty seconds, and the demo dazzles. Then it meets reality: the second post sounds nothing like the first, a founder spots the word "revolutionary" that your style guide bans, and a statistic in paragraph three turns out to be invented. The demo was easy; the product — consistent voice, structured output, and a truth check — is the hard part, and that is what this brief is really about.

Think of the difference between a talented freelancer and a newsroom. A freelancer can write one great piece; a newsroom ships hundreds a week that all sound like the same publication, because the voice lives in a style manual and every draft crosses an editor's desk before it prints. This project builds the newsroom, not the freelancer. The model is the fast writer, the template library is the style manual, and the human approval gate is the editor. Why frame it that way? Because the instinct — "just write a better prompt" — optimizes the one thing that was never the bottleneck. The bottleneck is doing it the same way a thousand times and never letting a confident falsehood slip through. The common mistake is to judge success by how impressive a single output looks, when the real signal is how little an editor has to change the draft before it ships. Read the scenario below with the newsroom in mind: the "brief" a human writes is deliberately tiny, because the leverage comes from the reusable machinery around it, not from a longer prompt.

"We need ten times the content, on-brand, without ten times the writers." Marketing needs blog posts, product blurbs, email subject lines, and social variants — consistently in the company voice, factually correct, and fast. A content assistant drafts all of it from a brief, a human edits and approves, and throughput jumps without sacrificing brand or truth.

1 · Discovery — what's slow about content? advanced

The seductive failure of any content project is automating the wrong step. It is tempting to point the model at everything a marketing team touches and let it rip. That is how you end up with an assistant that confidently publishes an unchecked claim — automating the exact step that most needs a human. Before you build, you have to know which parts of the work are genuinely slow-and-mechanical (great for a model) versus slow-and-judgement-heavy (must stay human). Getting that split wrong is the difference between a helper and a liability.

The discipline here is the same one a good consultant uses on their first day: don't ask "what could AI do?", ask "where does the time actually go, and how much of that is judgement?" A blank first draft eats an afternoon but needs almost no judgement — perfect leverage. Fact-checking a pricing claim takes two minutes but is pure judgement with a lawsuit on the downside — terrible leverage. The table below is that audit, and it is ranked deliberately: the model earns its keep on the boring, high-volume drafting and reformatting at the top, while the irreducibly human editorial call sits at the bottom marked low-leverage on purpose. The common mistake is to read a low-leverage row as a to-do ("let's automate fact-checking too") instead of what it is — a boundary you designed in. Read each row as a decision about where the human stays, not just where the model helps.

2 · Architecture advanced

When people first hear "content agent" they reach for the wrong shape. They imagine an autonomous loop that researches, drafts, revises itself, checks its own facts, and posts — a mini-employee. That instinct quietly imports all the fragility of a multi-step agent (loops that don't terminate, tool calls that fail, cost that spirals) into a problem that does not need any of it. The first architectural decision is therefore a subtraction: notice that this job is one input and one output, and build the simplest thing that does it.

The mental model is an assembly line, not a robot. Raw material goes in one end, passes through fixed stations in order, and a finished part comes out — no station decides to loop back, and a quality inspector stands at the exit. Here the stations are: fill a template with the brief, make one model call that emits every format at once, split that reply into named fields, then hand it to a human before anything goes live. That "one call, many formats" choice is worth pausing on: asking for the title, body, meta, and social posts together is both cheaper (one request, not five) and more coherent (the tweet is written knowing the headline), which is exactly why the diagram shows a single highlighted generate box rather than a chain. Why this matters: the boundary between the automated stations and the human inspector is the whole safety story, so the architecture is designed to make that boundary a hard wall — generation physically cannot reach "publish" without passing a person. The common mistake is blurring that wall to save a click; resist it. Trace the diagram left to right and watch where the arrow to "publish" comes from — it comes from the human, never from the model.

Deliberately simple: a brief fills a prompt template carrying the brand voice; the LLM generates all formats in one structured call; the output is split into body, metadata, and per-channel variants; a human reviews and approves before publishing. Tier 1 — a single well-engineered call, not an agent loop.

3 · Risk & safety model advanced

The dangerous thing about a content generator is that its failures are beautiful. A buggy calculator returns a number that is obviously wrong; a content model returns fluent, confident, perfectly-formatted prose that happens to contain an invented statistic. Nothing in the output looks broken — which is precisely why an unreviewed generator will, sooner or later, publish a falsehood in your company's name and no automated check will have flinched. Naming that failure mode out loud is the first job of a safety model.

Think of the model as a brilliant intern on their first day: quick, eager, produces polished work, and will state something completely made-up with total conviction because they would rather answer than admit they don't know. You would never let that intern publish straight to the company blog — not because they're bad, but because confidence is not the same as correctness. So the controls below are organized by who catches what: some risks (a banned word, a missing meta) are mechanical and a cheap deterministic check catches them for free; others (is this claim actually true? is this on-brand?) are judgement calls that route to a human. Why a whole section for this? Because the single most expensive mistake in content AI is treating the review gate as a nice-to-have you can drop under deadline pressure. The table pairs each risk with its control, but read it top-down for the pattern: the two red rows — a fabricated claim, and publishing without a human — both resolve to the same answer, a mandatory human editor. The common mistake is believing a clever enough prompt ("only state true facts") removes the need for that gate. It never does; a probabilistic writer cannot promise truth, so the human is not optional insurance, it is the design.

4 · The prompt-template library — the real product advanced

Every team that builds this makes the same early mistake: they scatter prompts. One prompt lives in the blog script, another in the email tool, a third pasted into someone's notes app. Each carries its own slightly-different version of the brand voice. Then marketing decides to drop exclamation marks, and now you are hunting through five files to change the same rule five times — and you miss one, so half your output is on-brand and half isn't. The fix is not a better prompt; it is a different structure, and that structure is the actual product of this project.

Borrow the idea from software engineering's oldest rule: don't repeat yourself. The brand voice is a single fact about your company, so it should exist in exactly one place — one string — and every template should reference it rather than restate it. Picture a brand style guide that the whole team links to: change the guide once and everyone is instantly working from the new rules. That is what a template library does. Each content type (blog post, product description) is a fill-in-the-blanks form that pulls in the shared voice and adds its own instructions and its own "return JSON with these keys" contract. Why this earns the label "the real product": the value your users pay for isn't a moment of prompt cleverness, it's the guarantee that draft #900 sounds exactly like draft #1 and that the voice can be tuned in one edit. The common mistake is optimizing the wording of an individual prompt while leaving the prompts duplicated — you can have the world's best prompt and still ship inconsistent content. The shape below is small on purpose; the discipline it encodes (voice in one place, one template per type, structured output) is the whole idea.

The value isn't one clever prompt; it's a reusable, parameterized library where brand voice lives in one place and every content type is a template.

templates.py (shape)BRAND_VOICE = """Warm, precise, no hype. Short sentences. UK spelling.
Never use: 'revolutionary', 'game-changer', exclamation marks."""

TEMPLATES = {
  "blog_post": """{brand_voice}
Write a {word_count}-word blog post on: {topic}
Audience: {audience}. Include an H1, 3 H2 sections, and a meta description.
Return JSON: title, meta_description, body_markdown, social_variants[].""",
  "product_desc": """{brand_voice}
Write a product description for: {product}. Key features: {features}.
Return JSON: headline, body, bullet_points[], seo_keywords[].""",
}

5 · Tool surface (optional) advanced

"Optional" is doing real work in that heading. The base version of this assistant needs no tools at all — it renders a template, makes one call, and returns a draft. So why list a tool surface? Because the moment you want to ground a factual piece in real sources, or store a draft in the CMS, or actually make something live, you are handing the system capabilities — and every capability is also a way for things to go wrong. Listing the tools up front, each tagged with its blast radius, is how you decide what the assistant may touch before you wire any of it.

The useful lens is to sort every capability by what it can break, the way you'd think about handing out office keys. A key to read the filing cabinet is low-stakes; a key to the front door that lets anyone in is not. Here the read-only tools — generate, brand_check, fact_sources — are the filing-cabinet keys: worst case they waste a few tokens, so they're green. save_draft writes, but only into an unpublished-draft state, so it's amber — a contained write. And publish is the front door: it makes content visible to the world, which is why the table marks it human-only and hands that key to no automated caller, ever. Why the color-coding matters: it turns an abstract "be careful" into a concrete rule you can enforce in code — green tools the model calls freely, the red one it literally cannot invoke. The common mistake is granting the publish capability to the agent "just to finish the loop," which quietly demolishes the entire safety model from section 3. Read the risk column as a permissions policy, not a warning label.

6 · Evaluation advanced

Ask a team how their content assistant is doing and you'll usually hear "it's great, the drafts look really good." That is not a measurement — it's a vibe, and vibes quietly rot. Six weeks later someone changes a template, the voice drifts, and nobody notices because nobody was counting. The reason evaluation gets its own section is that "looks good" cannot tell you whether a change helped or hurt, and content work is all changes: new templates, tweaked voice, a model upgrade. Without numbers you are flying blind through exactly the moments that matter.

The trick is to find measurements that are honest even though quality feels subjective. Some are easy: does every draft parse into the required structure? That's a hard yes/no you can automate. Others need a stand-in for taste — brand-voice adherence is fuzzy, so you use an LLM-as-judge scored against your exemplars, the same way a magazine has a style editor rather than a ruler. But the metric worth building the whole eval story around is quietly brilliant: edit distance to the published version — how much did a human actually change the draft before it went live? It is objective, it needs no separate grader, and it measures the one thing you actually care about, which is time saved. If that number falls over time, your templates and voice are genuinely improving; if it rises after a change, you just made things worse. Why this beats a quality score: a human editing less is the product working, with no interpretation required. The common mistake is chasing a subjective "quality" rating while ignoring the free, truthful signal sitting in your own edit history. Read the table as a mix of automatic gates (format, banned words) and judgement proxies (the judge, edit distance), and lean hardest on the one that costs nothing to collect.

7 · Phased rollout expert

The failure here is trying to ship the finished vision on day one. A team reads the architecture, gets excited, and attempts to launch grounded-and-optimized multi-format generation before a single human has ever edited a draft — before anyone even knows what "on-brand" concretely means for their exemplar library. It stalls, because the later capabilities depend on data and trust that only the earlier phases produce. A rollout ladder exists to stop you from skipping the rungs that make the top ones possible.

Think of it like earning trust with a new hire, not flipping a switch. On week one the intern drafts and you rewrite most of it — but every piece you approve becomes a teaching example. That is Phase 1, and it is not a throwaway: the heavily-edited drafts you approve are precisely how you build the exemplar library and learn your own voice well enough to encode it. Only once that foundation exists does Phase 2 (one brief fanning out to every channel, with a brand check before review) make sense, and only after you've collected edit-distance data does Phase 3 (grounding factual claims, tuning templates by that data) have anything to optimize against. Each rung buys the ingredients for the next. Why the ladder ends the way it does: the final rung is a Never, and that is deliberate — no phase, however mature, ever unlocks auto-publishing or presenting an unverified claim as checked, because those aren't advanced features, they're the two things that break the whole product's promise. The common mistake is treating "Never" as "not yet"; it is a permanent boundary, not a future phase. Read the rungs as a dependency chain where trust and data accumulate upward, and the ceiling is fixed on purpose.

Skills & course map expert

How to use this page expert

Do the steps in order, top to bottom. When you see a terminal block, type (or paste) those commands into your terminal and press Enter. When you see a file block, create a file with exactly that name and paste in the entire contents. Do not skip anything — each step depends on the ones before it. Expected output is shown after each command so you can confirm you're on track.

Step 1 · Create the project folder expert

Open a terminal. These commands make a new folder called content-assistant and move into it. The mkdir -p also creates a tests sub-folder we'll use later.

terminalmkdir -p content-assistant/tests
cd content-assistant

terminalpwd

/Users/you/content-assistant

Step 2 · Create and activate a virtual environment expert

A virtual environment keeps this project's packages separate from the rest of your system. Create one called .venv and activate it. After activating, your prompt will show (.venv) at the start of the line — that's how you know it worked.

terminalpython3 -m venv .venv
source .venv/bin/activate

terminalpy -m venv .venv
.venv\Scripts\Activate.ps1

(.venv) /Users/you/content-assistant $

Step 3 · Install the one dependency expert

We need the official Anthropic SDK. Install it with pip. (We won't call the API until Step 8, but installing now means the same code runs in both mock and live mode.)

terminalpip install "anthropic>=0.40" pytest

Successfully installed anthropic-0.69.0 pytest-8.3.4 ...

terminalpip freeze > requirements.txt

Step 4 · The brand voice and prompt templates expert

Create a file named templates.py in the content-assistant folder (the one you're in). Paste in everything below. This holds the brand voice in ONE place and one template per content type. render() fills a template with your brief.

templates.py"""Prompt templates + the single source of truth for brand voice."""

BRAND_VOICE = (
    "Voice rules: warm, precise, no hype. Short sentences. UK spelling. "
    "Never use the words 'revolutionary' or 'game-changer', and never use "
    "exclamation marks."
)

# One template per content type. {voice} is filled with BRAND_VOICE,
# the rest come from the caller's brief.
TEMPLATES = {
    "blog_post": (
        "{voice}\n\n"
        "Write a {words}-word blog post about: {topic}\n"
        "Audience: {audience}.\n"
        "Return JSON with keys: title, meta_description (max 160 chars), "
        "body_markdown, social_variants (a list of 3 short posts)."
    ),
    "product_desc": (
        "{voice}\n\n"
        "Write a product description for: {product}\n"
        "Key features: {features}.\n"
        "Return JSON with keys: title, meta_description, body_markdown, "
        "social_variants (a list of 3 short posts)."
    ),
}


def render(kind: str, **fields) -> str:
    """Fill a template. Raises KeyError if the template name is unknown,
    so typos fail loudly instead of silently producing nothing."""
    if kind not in TEMPLATES:
        raise KeyError(f"unknown template: {kind!r}. "
                       f"known: {list(TEMPLATES)}")
    return TEMPLATES[kind].format(voice=BRAND_VOICE, **fields)

Step 5 · The data model and the brand checker expert

Create content.py. It defines the Content object (what a finished draft looks like) and two pure functions: one that finds banned words, one that decides if publishing is allowed. Everything here is plain Python — no model, no network — so it's fast and testable.

content.py"""The Content data model + brand/publish rules (pure, testable)."""
from dataclasses import dataclass, field


@dataclass
class Content:
    title: str
    meta_description: str
    body_markdown: str
    social_variants: list[str] = field(default_factory=list)
    approved: bool = False            # only a human sets this to True

    def validate_shape(self) -> None:
        """Enforce the structural rules a CMS would need."""
        if not self.title.strip():
            raise ValueError("title is empty")
        if len(self.meta_description) > 160:
            raise ValueError("meta_description exceeds 160 chars")
        if len(self.social_variants) < 1:
            raise ValueError("need at least one social variant")


BANNED_WORDS = ["revolutionary", "game-changer", "!"]


def brand_violations(text: str) -> list[str]:
    """Return the banned tokens present in text (case-insensitive)."""
    low = text.lower()
    return [w for w in BANNED_WORDS if w in low]


def publish(content: Content) -> str:
    """The safety gate. Refuses unless a human approved AND the brand
    check passes. Returns a confirmation string when allowed."""
    if not content.approved:
        raise PermissionError("cannot publish: not human-approved")
    hits = brand_violations(content.body_markdown)
    if hits:
        raise ValueError(f"brand violation(s): {hits}")
    return f"PUBLISHED: {content.title}"

Step 6 · The engine (with a built-in mock, no key needed) expert

Create engine.py. It builds the prompt from a template, then either calls a mock generator (default — deterministic, no key) or the real Claude or OpenAI API (Step 8). It parses the JSON into a Content object. The mock lets you run and test the whole flow with zero setup.

engine.py"""Turns a brief into a Content draft. Mock by default; real API optional."""
import json, os
from templates import render
from content import Content

MODEL = "claude-opus-4-8"


def _mock_generate(prompt: str) -> str:
    """A deterministic stand-in for the model. Returns on-brand JSON so
    the whole pipeline runs without an API key. Note: no banned words."""
    return json.dumps({
        "title": "A Calm Guide to the Topic",
        "meta_description": "A short, clear overview written in plain language.",
        "body_markdown": "## Overview\n\nThis is a clear, on-brand draft.\n",
        "social_variants": ["Post one.", "Post two.", "Post three."],
    })


def _real_generate(prompt: str) -> str:
    """Call the real Claude API. Used only when USE_REAL_API=1."""
    import anthropic
    client = anthropic.Anthropic()      # reads ANTHROPIC_API_KEY from env
    msg = client.messages.create(
        model=MODEL, max_tokens=1500,
        messages=[{"role": "user", "content": prompt}],
    )
    return msg.content[0].text


def generate(kind: str, **brief) -> Content:
    """Render the template, get JSON, parse into a Content draft."""
    prompt = render(kind, **brief)
    use_real = os.environ.get("USE_REAL_API") == "1"
    raw = _real_generate(prompt) if use_real else _mock_generate(prompt)
    data = json.loads(raw)
    draft = Content(
        title=data["title"],
        meta_description=data["meta_description"],
        body_markdown=data["body_markdown"],
        social_variants=data["social_variants"],
    )
    draft.validate_shape()      # reject malformed drafts early
    return draft


if __name__ == "__main__":
    # Run this file directly to see a draft printed.
    d = generate("blog_post", topic="async Python",
                 audience="developers", words=600)
    print("TITLE:", d.title)
    print("SOCIAL POSTS:", len(d.social_variants))
    print("APPROVED:", d.approved, "(not live yet)")

engine.py"""Turns a brief into a Content draft. Mock by default; real API optional."""
import json, os
from templates import render
from content import Content

MODEL = "gpt-5.5"


def _mock_generate(prompt: str) -> str:
    """A deterministic stand-in for the model. Returns on-brand JSON so
    the whole pipeline runs without an API key. Note: no banned words."""
    return json.dumps({
        "title": "A Calm Guide to the Topic",
        "meta_description": "A short, clear overview written in plain language.",
        "body_markdown": "## Overview\n\nThis is a clear, on-brand draft.\n",
        "social_variants": ["Post one.", "Post two.", "Post three."],
    })


def _real_generate(prompt: str) -> str:
    """Call the real OpenAI API. Used only when USE_REAL_API=1."""
    import openai
    client = openai.OpenAI()      # reads OPENAI_API_KEY from env
    resp = client.responses.create(
        model=MODEL, max_output_tokens=1500,
        input=prompt,
    )
    return resp.output_text


def generate(kind: str, **brief) -> Content:
    """Render the template, get JSON, parse into a Content draft."""
    prompt = render(kind, **brief)
    use_real = os.environ.get("USE_REAL_API") == "1"
    raw = _real_generate(prompt) if use_real else _mock_generate(prompt)
    data = json.loads(raw)
    draft = Content(
        title=data["title"],
        meta_description=data["meta_description"],
        body_markdown=data["body_markdown"],
        social_variants=data["social_variants"],
    )
    draft.validate_shape()      # reject malformed drafts early
    return draft


if __name__ == "__main__":
    # Run this file directly to see a draft printed.
    d = generate("blog_post", topic="async Python",
                 audience="developers", words=600)
    print("TITLE:", d.title)
    print("SOCIAL POSTS:", len(d.social_variants))
    print("APPROVED:", d.approved, "(not live yet)")

Now run it. Because the mock is the default, this works immediately with no key:

terminalpython engine.py

TITLE: A Calm Guide to the Topic
SOCIAL POSTS: 3
APPROVED: False (not live yet)

Step 7 · Write and run the tests expert

Create tests/test_content.py. These six tests prove the safety-critical behaviour without a key. Paste the whole file.

tests/test_content.py"""Offline tests — no API key needed (engine uses the mock)."""
import pytest
from templates import render
from content import Content, brand_violations, publish
from engine import generate


def test_render_injects_brand_voice():
    prompt = render("blog_post", topic="x", audience="y", words=100)
    assert "UK spelling" in prompt        # the voice made it in


def test_unknown_template_raises():
    with pytest.raises(KeyError):
        render("nope", topic="x")


def test_generate_returns_valid_draft():
    d = generate("blog_post", topic="x", audience="y", words=100)
    assert d.title and len(d.social_variants) == 3
    assert d.approved is False              # never auto-approved


def test_meta_description_length_enforced():
    bad = Content(title="t", meta_description="x" * 200,
                  body_markdown="b", social_variants=["s"])
    with pytest.raises(ValueError):
        bad.validate_shape()


def test_publish_blocked_without_approval():
    d = generate("blog_post", topic="x", audience="y", words=100)
    with pytest.raises(PermissionError):
        publish(d)                          # not approved -> blocked


def test_brand_violation_blocks_publish():
    d = generate("blog_post", topic="x", audience="y", words=100)
    d.body_markdown = "This is revolutionary."   # banned word
    d.approved = True                          # even approved...
    with pytest.raises(ValueError):
        publish(d)                          # ...brand check still blocks

Run the tests from the content-assistant folder:

terminalpython -m pytest tests/ -v

tests/test_content.py::test_render_injects_brand_voice PASSED
tests/test_content.py::test_unknown_template_raises PASSED
tests/test_content.py::test_generate_returns_valid_draft PASSED
tests/test_content.py::test_meta_description_length_enforced PASSED
tests/test_content.py::test_publish_blocked_without_approval PASSED
tests/test_content.py::test_brand_violation_blocks_publish PASSED

6 passed in 0.05s

Step 8 · Go live with the real Claude API (optional) expert

Everything above ran on the mock. To use the real model, you need an API key and one environment variable — no code changes.

terminalexport ANTHROPIC_API_KEY="sk-ant-your-key-here"
export USE_REAL_API=1

terminal$env:ANTHROPIC_API_KEY="sk-ant-your-key-here"
$env:USE_REAL_API="1"

terminalpython engine.py

TITLE: A Measured Introduction to Async Python
SOCIAL POSTS: 3
APPROVED: False (not live yet)

Troubleshooting — every error you might hit expert

BRAND_VOICE = ("Warm, concise, expert. Active voice. "
               "Banned words: leverage, synergy, revolutionary.")

TEMPLATES = {
    "blog_post":   "Voice: {voice}\nWrite a blog post titled '{title}' for {audience}.",
    "product_desc":"Voice: {voice}\nDescribe {product} for {audience} in 2 sentences.",
}

def render(kind, **fields):
    fields.setdefault("voice", BRAND_VOICE)
    return TEMPLATES[kind].format(**fields)

print(render("product_desc", product="AcmeDB", audience="developers"))

from pydantic import BaseModel

class Content(BaseModel):
    title: str
    meta_description: str
    body_markdown: str
    social_variants: list[str]
    approved: bool = False

    def validate_shape(self):
        assert len(self.meta_description) <= 160, "meta too long for SEO"
        assert len(self.social_variants) >= 1, "need at least one social post"
        return self

c = Content(title="AcmeDB 2.0", meta_description="Faster queries, same API.",
    body_markdown="# AcmeDB 2.0\n...", social_variants=["AcmeDB 2.0 is here!"])
print(c.validate_shape().title)   # AcmeDB 2.0

# --- needs API key: fill Content from a brief in one pass ---
# c = client.messages.parse(model="claude-opus-4-8", output_format=Content,
#     system=BRAND_VOICE, messages=[{"role":"user","content":render(...)}]).parsed_output
# OpenAI: c = client.responses.parse(model="gpt-5.5", text_format=Content,
#     instructions=BRAND_VOICE, input=render(...)).output_parsed

BANNED = ("leverage", "synergy", "revolutionary", "game-changer")

def brand_violations(text):
    low = text.lower()
    return [w for w in BANNED if w in low]

print(brand_violations("Leverage our revolutionary synergy"))
# ['leverage', 'synergy', 'revolutionary']

# --- needs API key: LLM judge for tone (returns pass/fail + reason) ---
# judge = client.messages.create(model="claude-haiku-4-5", max_tokens=200,
#   system="Score tone vs this brand voice. Reply JSON {on_brand:bool, why:str}.",
#   messages=[{"role":"user","content":f"VOICE:{BRAND_VOICE}\nTEXT:{text}"}])
# OpenAI: judge = client.responses.create(model="gpt-5.5", max_output_tokens=200,
#   instructions="Score tone vs this brand voice. Reply JSON {on_brand:bool, why:str}.",
#   input=f"VOICE:{BRAND_VOICE}\nTEXT:{text}")
def on_brand(text):
    return len(brand_violations(text)) == 0    # + judge verdict in real code

print(on_brand("Fast, simple, honest."))       # True

def publish(content):
    violations = brand_violations(content.body_markdown + content.title)
    if violations:
        raise PermissionError(f"blocked: brand violations {violations}")
    if not content.approved:
        raise PermissionError("blocked: needs human approval before publish")
    return f"PUBLISHED: {content.title}"

c = Content(title="AcmeDB 2.0", meta_description="Faster.",
    body_markdown="Clean and honest.", social_variants=["hi"])
try: publish(c)                               # not approved yet
except PermissionError as e: print(e)         # blocked: needs human approval
c.approved = True
print(publish(c))                             # PUBLISHED: AcmeDB 2.0

def grounded(claims, sources):
    # every factual claim must appear (substring) in a source doc
    joined = " ".join(sources).lower()
    return [c for c in claims if c.lower() not in joined]   # -> unsupported

facts = ["query latency is 5ms", "made of unicorns"]
srcs  = ["AcmeDB query latency is 5ms at p50."]
print("unsupported:", grounded(facts, srcs))   # ['made of unicorns']

def edit_distance(a, b):
    dp = list(range(len(b)+1))
    for i, ca in enumerate(a, 1):
        prev, dp[0] = dp[0], i
        for j, cb in enumerate(b, 1):
            prev, dp[j] = dp[j], min(dp[j]+1, dp[j-1]+1, prev+(ca!=cb))
    return dp[-1]

# A/B: which variant drifts less from the approved baseline?
base = "Fast, simple, honest database."
print(edit_distance(base, "Fast, simple database."))      # small = closer
print(edit_distance(base, "Revolutionary synergy DB!"))   # large = off-brand

CHANNELS = {"twitter": 280, "linkedin": 3000, "email": 100_000}
AUDIT = []

def adapt(content, channel):
    limit = CHANNELS[channel]
    text = content.social_variants[0] if channel != "email" else content.body_markdown
    return text[:limit]                       # respect per-channel limit

def fan_out(content):
    if not content.approved:
        raise PermissionError("cannot fan out unapproved content")
    results = {}
    for ch in CHANNELS:
        out = adapt(content, ch)
        AUDIT.append({"channel": ch, "title": content.title, "chars": len(out)})
        results[ch] = out
    return results

c.approved = True
fan_out(c)
for entry in AUDIT: print(entry)

content-assistant/
├─ .venv/                 (virtual environment)
├─ requirements.txt       (pinned dependencies)
├─ templates.py           (brand voice + templates)
├─ content.py             (data model + publish gate)
├─ engine.py              (generate: mock or real)
└─ tests/
   └─ test_content.py     (6 offline tests)

Knowledge check check yourself