AI-ASSISTED CONTENT SYSTEMS · CONTENT OPERATIONS · EDITORIAL STANDARDS FOR AI
A self-compiling messaging knowledge base
When I put AI into content work, the value is never the generation. It's the discipline around it: institutional memory built as infrastructure, designed within real constraints, with human review carrying the weight.
ROLE
Content Strategy Lead
TYPE
AI-assisted content system + rollout
STAGE
Proof of concept
OUTPUT
Schema · Manual · Seed set
HOW I THINK
How I think about AI in content ops
A few principles guide how I bring AI into content work. The system below is them, applied.
01
Compile, don't just retrieve
Treat institutional memory as infrastructure worth owning, not a query re-run from scratch every time.
02
Design around the constraint
Work within the approved tools instead of pretending they're something they're not.
03
Make review load-bearing
The human check isn't a workaround for a weaker tool. It's the discipline that keeps a shared base trustworthy.
04
Earn the rollout
Prove it in a sandbox, then move to shared infrastructure, then to a funded initiative. Each stage earns the next.
The thinking in action
A self-compiling messaging knowledge base, built inside real constraints.
Here's the problem, the reframe, and the system I shipped.
01 — THE PROBLEM
Everywhere and nowhere
Marketing's working knowledge of how we talk about ourselves lived in too many places at once. Positioning in decks. Approved language in messaging guides. Competitive read-outs in threads and one-off docs. Every time someone needed the current narrative, they rebuilt it from scratch — or pulled a version that had quietly gone stale.
The cost isn't dramatic on any single day. It compounds: inconsistent language reaching market, rework, and a slow erosion of the through-line from approved positioning to finished asset. I wanted to fix the root cause, not the symptom.
02 — THE STRATEGIC QUESTION
Retrieve the answer, or compile it?
A new pattern was circulating: instead of having AI retrieve from documents at query time, you have it compile and maintain a living knowledge base that accumulates over time.
RETRIEVAL
Re-derives the answer on every ask.
Fine when the answer lives in one document. For messaging — where the value is the synthesis across many sources — it starts from zero every time.
COMPILATION ✓
Builds the answer once and keeps it current.
The synthesis is the asset. Each new source makes the whole base smarter — exactly what messaging needs.
The reframe I brought: this isn't a clever tool trick. It's institutional memory as infrastructure — something worth owning, not a personal shortcut.
03 — THE CONSTRAINT THAT SHAPED EVERYTHING
Design around the limit, not against it
The published pattern assumes an autonomous agent that writes and files its own files. Our environment doesn't allow that. The only approved tool for company materials is Microsoft Copilot — built around grounded retrieval, not file maintenance. A naive adoption would have failed quietly: a retrieval bot dressed up as a wiki.
So I split the system into two layers — and made the human review step the load-bearing part.
WIKI LAYER
Compiled pages I own & maintain
The living, synthesized answer. Always current, always sourced.
SOURCE LAYER
Immutable source documents
Never edited. Always a clean record of truth to check against.
Copilot drafts→human reviews→human files
The review step isn't a workaround for a weaker tool. It's the compilation discipline that keeps the base trustworthy once other teams depend on it.
04 — WHAT I BUILT
A schema that turns an assistant into a maintainer
The core deliverable is a schema and operating manual: defined page types, a consistent template, an ingest workflow, and a maintenance cadence. Its load-bearing element is a steering instruction set — the rules that keep a general-purpose assistant honest.
The Compilation DisciplineHouse rules
▸ Every claim carries its source attribution.
▸ Contradictions get flagged, never silently overwritten.
▸ Unsourced language is never presented as approved.
catches the failure mode that kills shared wikis:
confident, organized wrongness that spreads fast.
Page types & template
Voice & Tone, Lexicon, Boilerplate, and more — one consistent shape.
Ingest workflow
How a new source becomes a sourced, reviewed page update.
Seed set
Starter pages, fully templated, ready to fill with real language.
05 — A ROLLOUT THAT EARNS ITS WAY
From solo sandbox to funded initiative
1
Sandbox first
A solo proof of concept in private storage. Nothing shared, fully reversible, with a defined success test set before any work began.
2
Shared infrastructure
Once value is proven, the wiki moves behind a Copilot Studio agent that Demand Gen, Product Marketing, and other teams query in natural language — access governed by existing permissions.
3
Council-ready
The proof of concept becomes the evidence for a funded, owned initiative — not a speculative pitch.
06 — TRUST, DESIGNED IN
Trust as a design requirement
Because this would eventually hold messaging that multiple teams act on, trust couldn't be an afterthought.
Immutable sources
Always a clean record of truth behind every compiled page.
Sources + approval status
Every page shows where its language came from and whether it's signed off.
Permission-aware
The agent never surfaces anything a given person couldn't already see.
Maintenance protocol
Built to catch confident, organized wrongness before it spreads.
07 — OUTCOME
What shipped
Schema & operating manual, adapted to enterprise constraints
Working seed set + a defined, testable success criterion
The success test is deliberately narrow: does each new source let the wiki answer a question it couldn't answer before? A sustained yes means the compounding effect is real at our scale.