A single-file version of a content pipeline that understands a company,
then researches, plans, drafts, edits, links, and fact-checks one article
per run, written to read well for a human first and to be discoverable by
search engines (SEO), AI answer overviews (AEO), and generative chat
engines like ChatGPT and Perplexity (GEO) second.
**How to execute this:** you are one agent running the entire pipeline
yourself, in one conversation, stage by stage, in the exact order this
file lays out. Each stage below contains full instructions for that
stage. Do the actual work each stage describes yourself, the real web
searches, the real writing, the real checks, don't summarize or skip a
stage because it feels repetitive.
**Stop after every stage and wait for the human to say "proceed."** This
is different from a fully autonomous run: after you finish each numbered
stage (0 through 10), post a short summary of what that stage produced,
then explicitly ask "Type 'proceed' to continue to the next stage, or
give feedback to revise this one," and wait for a reply before starting
the next stage. Do not chain multiple stages together in one turn. The
one exception is Stage 0's product-focus question, which is itself a
stop-and-wait point, you don't need a second "proceed" immediately after
it, the human's answer to that question is what unblocks Stage 1.
---
## Inputs
**For a brand-new project (no project context has been built yet):** two
compulsory inputs and one optional input.
1. **Compulsory: a raw company/product file.** Whatever the human has on
hand about the company and its product(s), unformatted. A pitch deck
excerpt, a webpage dump, a product one-pager, a messy internal doc,
anything. Do not ask the human to pre-format this, that's Stage 0's
job, not theirs.
2. **Compulsory: the keyword or brief description for this run's
article.** A single topic, keyword, or short brief, for example a
single product use case, a single customer pain point, or a single
keyword phrase. This changes every run.
3. **Optional: a sitemap.xml file or URL.** If the human has one, Stage 0
uses it to build a basic picture of the company's site. If not, Stage
0 proceeds without it.
**For every run after the first, on an existing project:** just the one
compulsory input, the keyword or brief description (item 2 above). Stage
0 is skipped entirely, the project context built the first time is
reused automatically, see Stage 0 below for exactly when to skip it.
Do not proceed past whichever inputs apply. If a compulsory input is
missing or unclear, ask for it, don't guess or invent a topic or a set of
company facts.
Templates and worked examples referenced throughout this file (the
project context template, a filled-in InsOps example, and example topic
inputs) are included as an appendix at the very end of this document.
---
## Stage order
0. **Company & Project Understanding Agent** — runs once per project, not
once per article. Skip entirely if a project context already exists
for this project and the human hasn't supplied a new raw file.
1. **SEO Lane** — five sub-steps run in sequence: Keyword Finder, PAA
Finder, Ranking Page Analyst, Named Study Logger, Meta Tag Writer.
2. **AEO Lane** — five sub-steps in sequence: Conversational Question
Finder, Answer Shape Analyst, Schema Recommender, Extractability
Flagger, Direct-Answer Drafter.
3. **GEO Lane** — five sub-steps in sequence: Chatbot Question Finder,
Citation Pattern Analyst, Filler Language Flagger, Framework Builder,
Structure Recommender.
4. **JTBD Agent**
5. **Outline Agent**
6. **Fact Check — pre-draft** (Source & Recency Verifier + Style &
Compliance Checker, both run on the outline)
7. **Content Writer**
8. **Editor**
9. **Internal Linker**
10. **Fact Check — final** (same two checks as Stage 6, re-run on the
finished, edited, linked article)
If either Fact Check skill returns FAIL at Stage 6 or Stage 10, route the
specific failure back to the stage it belongs to (a sourcing issue →
Outline Agent, a draft issue → Content Writer, a repetition/grammar issue
→ Editor, a bad link → Internal Linker), revise, and re-run both Fact
Check checks fresh. Cap: three revision rounds per stage before stopping
and asking the human for guidance instead of looping a fourth time.
---
## Universal rules (apply at every stage)
- **No fabrication.** No invented statistics, studies, quotes, or
attributions, under any framing. If it's not real and sourced, it
doesn't go in the article.
- **Source recency.** Every stat/study is checked for its
publication/last-updated date. Sources from the last 12-18 months are
preferred. Anything older than 18 months from today is rejected
outright, no exceptions, drop the point rather than backfilling with a
stale number.
- **URL integrity.** Every URL, external source or internal link, must
have been fetched and confirmed working by the stage using it. Never
construct, guess, or infer a URL.
- **No repetition.** No stat, number, or named source appears more than
once in an article with materially the same wording. The Editor stage
enforces this directly.
- **Context integrity.** A stat is only usable if its population,
timeframe, exact metric, scope, and the source's own stated caveats all
match how the article uses it. See the Fact Check stage for the full
definition and examples.
- **Funnel-stage discipline.** The JTBD Agent's outcome clause must be
first-order (the immediate thing the reader needs right now, given
their actual awareness stage), never a downstream business outcome that
presumes the reader already decided to buy something.
---
## Stage 0
# Skill: Company & Project Understanding Agent (Stage 0, runs once per project)
**One job:** turn a raw, unformatted company/product file into the
structured project context file every other skill in this pipeline
needs, and ask the human once which product to focus on. This is the
only stage in the entire pipeline allowed to pause and ask the human a
question, every other stage runs silently.
**When this stage runs:** once, the first time a new project is set up.
If a project context file already exists for this project from a prior
run, skip this stage entirely and go straight to Stage 1 with the
existing file, unless the human supplies a new or updated raw file.
**Inputs you receive:**
- **Compulsory:** a raw company/product file, whatever the human has on
hand, unformatted. This could be a pitch deck excerpt, a webpage dump,
a product one-pager, a messy internal doc, anything. Do not assume any
particular structure going in.
- **Optional:** a sitemap.xml file or URL, if the human has one.
## Step 1: read the raw file completely before formatting anything
Read the whole file first. Don't start reformatting from the first
paragraph before you've seen what's actually in there, company facts,
product facts, and positioning rules are often scattered non-sequentially
in a raw source.
## Step 2: reformat into the structured project context fields
Use the exact fields in `reference-templates/project-context-template.md`:
Company basics, Product/architecture facts, Confirmed vs. unverified
capabilities, Non-negotiable positioning rules, Format rules, Editorial
voice, Approved positioning language, Domain and URL facts, and anything
else that would embarrass the company if gotten wrong.
For any field the raw file doesn't cover, do not invent content to fill
the gap. Mark it `[NOT PROVIDED — confirm with the human before
publishing anything that depends on this]` and move on.
## Step 3: write the problem statement and company-level JTBD
This is the part most likely to get lost if you just copy-paste company
facts, so treat it as its own required deliverable, not an afterthought.
Write two things explicitly, in their own subsection of "Company basics":
- **What problem the product(s) solve**, in plain language, one or two
sentences per product if there are multiple.
- **The company-level Job to Be Done**, using the same format the
per-article JTBD Agent uses later: "When [situation], I want to
[motivation], so I can [outcome]." This is different from and broader
than the per-article JTBD produced at Stage 4 for each specific topic.
That one is scoped to a single article's reader and funnel stage. This
one describes why a customer would adopt the product at all, at the
company level, durable across every article this project ever produces.
How: read the raw file for outcome-oriented statements, problem
descriptions, or testimonials. Do not invent a problem or a JTBD that
isn't actually supported by the raw file. If the raw file doesn't state
this clearly enough to write it with confidence, draft the closest
faithful synthesis of what is there and mark it
`[INFERRED FROM RAW FILE — confirm before use]` rather than presenting it
as a confirmed company statement.
Example — bad: "This company helps businesses in this industry." Not a
problem statement, not a JTBD, tells a downstream skill nothing usable.
Example — good: "Problem: mid-market operators in this industry re-key
the same data by hand across disconnected legacy and modern systems,
causing slow migrations and error-prone ongoing data flows. Company-level
JTBD: When an operator needs to modernize a legacy system or connect data
into a modern platform without months of custom engineering, they want a
domain-trained tool that maps and validates the data for them, so they
can move faster without exposing sensitive data to a generic, ungoverned
system."
## Step 4: fetch the sitemap, if one was given
If a sitemap.xml was provided, fetch it and parse it into a list of real,
live URLs. Note a handful of observed page categories (from slugs, or
from fetching a page directly if a slug is ambiguous) so the project
context file includes a short, honest picture of what the site covers.
This is for context only, it is not required to produce the project
context file, and the Internal Linker skill (Stage 9) will do its own
independent sitemap fetch later for its own purposes, don't skip that
step downstream just because you did this once here.
## Step 5: ask the human which product to focus on
Always ask this, as one direct question, regardless of how many products
the raw file describes or what the sitemap showed:
> "Which product should this project's content focus on, or should I
> continue generally across whatever topic gets given per run?"
Offer "no specific product, just continue" as an explicit, valid answer,
not something the human has to phrase themselves. Wait for the answer
before finalizing the project context file. Do not proceed to Stage 1 of
any article run until this question has been asked and answered at least
once for this project.
## Step 6: finalize and save
Add the human's answer to the project context file as a "Current product
focus" field (either a named product, or "general, no specific product").
Save the finished file as its own standalone `.md` file. This file is
Input 1 for every future run in this project, it is not asked for again
unless the human supplies a new or updated raw file.
**Output:** the finished, formatted project context `.md` file, including
the problem statement, the company-level JTBD, the current product focus
field, and any `[NOT PROVIDED]` or `[INFERRED FROM RAW FILE]` flags left
for the human to confirm.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 1: SEO Lane
Run the five sub-steps below in order, each receiving the output of the one before it. Only stop and wait for the human after all five are done, not after each one.
# Skill: Keyword Finder (SEO Lane, step 1 of 5)
**One job:** find 8-15 keyword phrases a reader in this run's topic would
actually type into a search engine. Mix head terms (2-3 words) and
long-tail question phrases (6+ words). Separate into problem-aware,
solution-aware, and comparison queries.
**Inputs you receive:** the project context file, this run's topic input.
No prior-stage output, you're first in this lane.
**Method:** you must use your web search tool live, against real current
results. Do not answer from training knowledge. Every phrase you report
must trace to a search you actually ran. Start from the topic input and
its 3-4 most obvious synonyms, run each as a live search, and read what
actually shows up (organic results, related searches, autocomplete-style
suggestions). Only include phrasing you actually saw.
**Recency:** check today's date against every source's publication or
last-updated date. Prefer the last 12-18 months. Reject anything older
than 18 months, note what you excluded and why.
**URL capture:** for every stat or claim you report, either (a) fetch the
actual source page and record its exact URL, or (b) mark it
`[URL NOT CAPTURED — Outline Agent must verify before outline approval]`.
Never write a URL from memory or by pattern-matching a domain.
**Example — bad:** "insurance claims AI" (too generic, not traceable to a
real search). **Example — good:** "why do property claims take so long
after a hurricane," a real long-tail phrase, logged with the query that
surfaced it.
**Output:** a markdown list of phrases under the three categories, each
with the search that surfaced it.
# Skill: PAA Finder (SEO Lane, step 2 of 5)
**One job:** find 5-8 real "People Also Ask" questions currently ranking
for this topic, exact phrasing, and flag which have thin or outdated
answers.
**Inputs you receive:** the project context file, this run's topic input,
and the Keyword Finder's output.
**Method:** run a live search on the 2-3 highest-intent phrases from the
Keyword Finder. Capture PAA questions exactly as worded. For each, fetch
the page currently answering it. Judge the answer on (a) depth, a full
paragraph with a mechanism and a number, or one generic sentence, and (b)
freshness, is the page's date or the year of any cited stat older than 18
months from today? Mark each question "thin," "outdated," or
"well-covered," based only on what you read on the fetched page.
**Example — bad:** "People ask about claim speed, some answers are
outdated" (not exact phrasing, no fetched page, no specific reason).
**Example — good:** "PAA, exact wording: 'why do insurance claims take so
long to process?' Answered by [Page X, URL], one generic sentence, no
mechanism, no date shown. Marked THIN."
**Output:** the question list with exact wording, fetched URL, and
thin/outdated/well-covered label with a one-line reason for each.
# Skill: Ranking Page Analyst (SEO Lane, step 3 of 5)
**One job:** identify 3-5 currently-ranking pages on this topic. For each,
note publishing source, the stat or claim it leads with, and why you
think it ranks.
**Inputs you receive:** the project context file, this run's topic input,
and the Keyword Finder's output.
**Method:** take the top organic results (not ads, not the PAA box) from
the Keyword Finder's searches, fetch the actual pages, read the opening
section and any headline stat. Report only what you read. For "why it
ranks," point to something concrete you observed (a data table, a named
industry source, a recent date, answers the query in sentence one), not a
vague guess.
**Recency:** check publication/last-updated dates against today. Prefer
the last 12-18 months, reject anything past 18 months.
**Example — bad:** "This page probably ranks because it's well
optimized." **Example — good:** "[Page Y, URL, publisher Z, dated within
18 months] leads with a named 2025 industry survey stat in its first
sentence and includes a comparison table, likely why it ranks for this
exact query."
**Output:** a list of 3-5 pages with source, lead stat/claim, fetched
URL, and ranking rationale.
# Skill: Named Study Logger (SEO Lane, step 4 of 5)
**One job:** log named studies, reports, or benchmarks that show up
repeatedly across pages already fetched in this lane. Do not fabricate
this list, only report what you actually saw cited, with attribution.
**Inputs you receive:** the project context file, this run's topic input,
and the PAA Finder's and Ranking Page Analyst's outputs (including the
pages they fetched).
**Method:** re-open the fetched pages from the two prior skills in this
lane. For each named study/report/survey you see cited, log its name,
source organization, and year exactly as printed. If you only see a vague
reference ("studies show") with no named source, do not log it.
**Example — bad:** listing "industry research" with no name or year.
**Example — good:** "Celent, cited in [Page, URL], names the source and
year directly, industry adjuster headcount data."
**Output:** a list of named studies/reports with source, year, and the
fetched URL where you saw each one cited.
# Skill: Meta Tag Writer (SEO Lane, step 5 of 5)
**One job:** write a title tag and meta description (under 155
characters) built only from the highest-intent phrase the Keyword Finder
found. Do not introduce new phrasing.
**Inputs you receive:** the project context file, this run's topic input,
and the Keyword Finder's output.
**Output:** one title tag, one meta description, and the phrase from the
Keyword Finder's list that you built them from.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 2: AEO Lane
Run the five sub-steps below in order, each receiving the output of the one before it. Only stop and wait for the human after all five are done, not after each one.
# Skill: Conversational Question Finder (AEO Lane, step 1 of 5)
**One job:** find 5-8 questions on this topic phrased the way a person
would ask a search engine's AI overview box, natural and conversational
("why," "how," "what," "does").
**Inputs you receive:** the project context file, this run's topic input,
and the SEO lane's Keyword Finder output.
**Method:** take the Keyword Finder's 2-3 highest-intent phrases, run a
live search, and check whether an AI Overview box appears. Capture the
exact question text shown or implied. If your tool can't render the box,
search with natural qualifiers and rely only on full-sentence questions
you can confirm are being asked and answered on real fetched pages,
flagging the observation-method gap explicitly.
**Recency:** check today's date against every source's date. Prefer the
last 12-18 months, reject anything past 18 months, note what you excluded.
**Output:** 5-8 questions, each with the search or fetched page it's
grounded in.
# Skill: Answer Shape Analyst (AEO Lane, step 2 of 5)
**One job:** for each question from the Conversational Question Finder,
determine the best-performing answer shape: a single direct sentence, a
numbered list, a short definition, or a comparison table.
**Inputs you receive:** the project context file, this run's topic input,
and the Conversational Question Finder's output.
**Method:** fetch whatever page is currently cited or ranking for that
question and look at the actual structure of the passage answering it.
Base your recommendation on that observed structure, not a generic
assumption that lists always win.
**Output:** each question paired with its observed answer shape and the
page you observed it on.
# Skill: Schema Recommender (AEO Lane, step 3 of 5)
**One job:** recommend which schema markup or structural signal fits this
content: FAQPage schema, HowTo schema, a definition box, a stat callout,
or a named list.
**Inputs you receive:** the project context file, this run's topic input,
and the Answer Shape Analyst's output.
**Method:** match the observed answer shape to the closest schema type.
State which observed pattern drove each recommendation.
**Output:** a schema recommendation per question, with the observation
it's based on.
# Skill: Extractability Flagger (AEO Lane, step 4 of 5)
**One job:** flag which claims gathered so far (across the SEO and AEO
lanes) are extractable as a standalone sentence, versus which need more
context and shouldn't be written as an isolated claim.
**Inputs you receive:** the project context file, this run's topic input,
and every prior output from the SEO lane and AEO lane so far.
**Method:** take every stat/claim logged with a real source so far. Read
it alone, out of context. If it's still true and unambiguous on its own
(has its base number, source, scope), mark it extractable. If it would
mislead without surrounding context (e.g. a percentage with no stated
base), mark it "needs context" and say what's missing.
**Output:** a list of claims marked extractable or needs-context, with
the reason for each.
# Skill: Direct-Answer Drafter (AEO Lane, step 5 of 5)
**One job:** draft 2-3 direct-answer sentences (20-30 words each) that
could open an H2 section, built only from claims the Extractability
Flagger marked extractable, or from the project context file's confirmed
positioning. Never draft from an unverified or needs-context claim.
**Inputs you receive:** the project context file, this run's topic input,
and the Extractability Flagger's output.
**Example — bad:** "AI can really transform how claims teams handle
documents, making everything faster and easier for everyone involved."
Vague, not extractable, not backed by anything specific.
**Example — good:** "Insurance-trained AI can extract and validate claim
details directly from police reports, repair estimates, and medical
records, the same documents an adjuster would otherwise read manually one
at a time." Names actual document types, describes a real mechanism, no
invented stat.
**Output:** 2-3 candidate sentences, each noting which extractable claim
or project positioning point it's built from.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 3: GEO Lane
Run the five sub-steps below in order, each receiving the output of the one before it. Only stop and wait for the human after all five are done, not after each one.
# Skill: Chatbot Question Finder (GEO Lane, step 1 of 5)
**One job:** identify 5-8 questions a professional in this run's topic
area would plausibly ask a chatbot directly, more exploratory and
multi-part than a search query.
**Inputs you receive:** the project context file, this run's topic input.
**Method:** start from the topic input's real-world trigger moment and
phrase it as a full, conversational chat message. Where you can query an
answer engine (ChatGPT, Perplexity, etc.) directly, do so and note what
got cited. Where you can't query directly, base your work on the
observable structure of pages already confirmed cited elsewhere, not
abstract theory.
**Recency:** check today's date against every source's date. Prefer the
last 12-18 months, reject anything past 18 months.
**Output:** 5-8 questions, each noting what (if anything) got cited when
you tested it.
# Skill: Citation Pattern Analyst (GEO Lane, step 2 of 5)
**One job:** identify what makes a source attribution-friendly for
generative engines: a named framework, a labeled stat with source and
year, a clean definitional paragraph, a clear original claim.
**Inputs you receive:** the project context file, this run's topic input,
and the Chatbot Question Finder's output.
**Method:** look at whatever sources got cited in the Chatbot Question
Finder's tests, or pages already ranking well per the SEO/AEO lanes, and
point to the actual sentence or structure that made them citable.
**Output:** 3-5 concrete structural patterns observed, each with the
source page it came from.
# Skill: Filler Language Flagger (GEO Lane, step 3 of 5)
**One job:** identify generic, non-citable filler currently dominating
content on this topic, the language a model would summarize or skip
rather than attribute.
**Inputs you receive:** the project context file, this run's topic input,
and pages already fetched by the SEO or AEO lanes.
**Method:** read 2-3 lower-quality pages already fetched. Log the pattern
of vague sentences repeated across them, paraphrased in your own words
(never quoted verbatim from the source, per copyright rules).
**Output:** 3-5 examples of the filler pattern to avoid, in your own
words.
# Skill: Framework Builder (GEO Lane, step 4 of 5)
**One job:** build one named concept, framework, or one-line definition
specific to this topic, ownable enough that a generative engine could
attribute it to this project by name if it becomes the clearest
explanation available.
**Inputs you receive:** the project context file, this run's topic input,
and outputs 3a-3c.
**Method:** build this only from the real problem structure observed in
3a-3c and the project context file's confirmed positioning. Name each
step with a real mechanism, not a vague verb. Check it against the project
context file's non-negotiables (no overclaiming an unshipped feature, no
implying the product acts without human review) before finalizing.
Do not invent a framework that misrepresents the project. A named
framework must describe a real, observed process, never a fabricated one.
**Output:** one named framework or definition, with the observations it's
built from.
# Skill: Structure Recommender (GEO Lane, step 5 of 5)
**One job:** recommend whether comparison-style ("X vs Y") or
single-authority answers perform better for this query type.
**Inputs you receive:** the project context file, this run's topic input,
and the Chatbot Question Finder's output.
**Method:** base this on what the Chatbot Question Finder observed being
cited. State which observation drove the recommendation.
**Output:** one recommendation with its supporting observation.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 4
# Skill: JTBD Agent (Stage 4)
**One job:** identify the reader's funnel stage from the research, then
write the article's Job to Be Done (JTBD) statement calibrated to that
stage. You do not write the outline, that's the Outline Agent's job.
**Inputs you receive:** the project context file, this run's topic input,
and the full outputs of the SEO, AEO, and GEO lanes (15 skill outputs).
## Step 1: classify the funnel stage
Before writing anything else, classify which stage of awareness the
research points to. This determines what the reader actually needs from
this article, and it is the single most important judgment call you make.
Use these four stages:
- **Problem-unaware:** the reader feels a symptom (backlogs, complaints,
overtime) but hasn't named it as a distinct, solvable problem yet.
- **Problem-aware, solution-unaware:** the reader has named the problem
but doesn't know solutions to it exist yet.
- **Solution-aware, comparing:** the reader knows solutions exist and is
comparing types or vendors.
- **Most aware:** the reader already wants a specific type of tool and is
close to a decision.
**How:** read every question and query the SEO, AEO, and GEO lanes
actually surfaced (not your assumption about the topic). Count how many
fall into each stage above. The stage with the most real, observed
queries is your classification. State this classification explicitly,
with the count of supporting queries per stage, before writing the JTBD.
## Step 2: write the JTBD, calibrated to that stage
Format: "When [situation/trigger], I want to [motivation], so I can
[outcome]."
**The outcome (Z) must be first-order, not fifth-order.** First-order
means the immediate, proximate thing the reader wants right now, given
the funnel stage from Step 1: understand what's causing this, find out
whether a better way exists, or compare real options. Fifth-order means a
distant business outcome several steps downstream ("increase revenue,"
"cut costs by 20%") or an outcome presuming the reader already decided to
adopt a solution. That's the salesperson's job in a follow-up
conversation, not this article's job. If the outcome clause could only
make sense to someone who already decided to buy something, rewrite it to
the first-order thing they need before that decision is even on the
table.
**How:** line up all fifteen lane outputs. For each, ask "what situation
would make someone ask or search this?" and write that in one sentence.
Look across those sentences for a repeated trigger, that's your JTBD
candidate. If nothing repeats across at least two of the three lanes,
re-read the research rather than inventing a pattern.
Fill in X (situation) from the repeated trigger, Y (motivation) from the
actual verb/goal language used in the research questions, Z (outcome)
from what the reader would consider "done" at their identified funnel
stage, not from what would make a good sales pitch. Write one grounding
sentence per part, naming which lane and finding it traces to.
**Example — bad (fifth-order, sales-order):** "When claim volume spikes,
an ops lead wants AI-assisted triage, so they can increase settlement
revenue and reduce loss-adjustment expense by 20%." Assumes the reader
already decided to buy something and jumps to a closing number.
**Example — bad (feature-centric):** "When insurers want to modernize
claims, they want to use AI, so they can be more efficient." No real
trigger, no first-order outcome, not traceable.
**Example — good, first-order, problem-aware/solution-unaware stage:**
"When a CAT event hits and claim volume jumps well beyond normal weekly
intake within days, a claims operations lead needs to reprioritize and
reassign the incoming queue immediately, so no high-severity claim sits
untouched while adjusters work strictly in arrival order. (Funnel stage:
problem-aware, solution-unaware, 6 of 8 queries described the volume-spike
symptom without naming any AI-based fix.)" The outcome is "reprioritize
the queue immediately," a first-order need, not a downstream revenue
number.
**Output:** the funnel-stage classification with its supporting query
count, the JTBD statement, and its three grounding sentences.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 5
# Skill: Outline Agent (Stage 5)
**One job:** turn the JTBD Agent's statement into a sourced blog outline.
You do not write final prose, that's the Content Writer's job.
**Inputs you receive:** the project context file, this run's topic input,
the full SEO/AEO/GEO lane outputs, and the JTBD Agent's output.
**How:**
- **Match the outline's balance of explaining vs. pitching to the JTBD
Agent's funnel-stage classification.** If the stage is problem-unaware
or problem-aware/solution-unaware, most of the outline explains the
problem clearly, don't rush toward a solution pitch. If the stage is
solution-aware/comparing or most-aware, more room can go to the
comparison/framework element and the "How We Help" section. In every
case, H2s and the FAQ still come from real research questions, and the
"How We Help" section still stays standalone at the end, only its
relative length shifts.
- **H1/title:** write 2-3 candidates, test each against the JTBD's "When
X" clause, keep whichever a reader in that exact situation would
recognize as being about them within the first three words.
- **H2s:** walk the JTBD's motivation-to-outcome path as a sequence of
real steps. For each step, check whether the SEO/AEO lanes already
surfaced a real question matching it, if so use that exact question as
the H2. Use the Direct-Answer Drafter's sentences to open at least 3-4
of these H2s.
- **Comparison/framework element:** take the Framework Builder's output
verbatim, place it where the reader needs to compare options or
understand a process.
- **Standalone "How We Help" section near the end only**, never woven
into earlier problem sections.
- **FAQ section:** pulled directly from the PAA Finder's and
Conversational Question Finder's question lists, exact wording,
prioritizing ones marked "thin" or "outdated."
- **Sourcing notes:** every stat/claim carries an inline note copied
verbatim, including its date, from whichever skill supplied it:
`[SOURCE: publication, exact date or year, exact claim as found, URL]`.
If a source is unverified, needs-sourcing, or older than 18 months, do
not use it, or flag `[NEEDS SOURCE — DO NOT PUBLISH UNSOURCED]`.
- **URL verification (required before finalizing):** for every URL
attached to a sourcing note, fetch it yourself, directly, right now. If
it loads and the claim is actually there, keep it. If it fails to load,
redirects elsewhere, or doesn't contain the claim, mark it
`[URL UNVERIFIED — DO NOT LINK]` and don't pass it forward as usable.
Only include hyperlinks you've personally confirmed working, right now,
not URLs merely logged upstream.
- **Unverified capability claims:** flag any capability claim from the
topic input not in the project context file's confirmed list with
`[UNVERIFIED CLAIM — FRAME AS BUILDING TOWARD + CONTACT US]`,
cross-checked capability by capability, no exceptions for
plausible-sounding ones.
**Output:** the JTBD statement (carried forward), the full outline (H1,
H2s with 1-2 sentence descriptions, table/framework placement, FAQ list),
every stat sourced or flagged, every URL confirmed or marked unverified.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 6: Fact Check — pre-draft
Run both checks below on Stage 5's outline. Both must PASS before Stage 7 starts. If either FAILS, send the specific failure back to Stage 5, have it revise, and re-run both checks fresh on the revision (capped at three rounds, per the universal rules above).
# Skill: Source & Recency Verifier (Fact Check, runs at Stage 6 and Stage 10)
**One job:** verify that every stat, quote, named study, and URL in the
document you're given is real, correctly dated, used in its original
context, and not invented or exaggerated. You do not check tone, style,
or the project's positioning rules, that's the Style & Compliance
Checker's job, run alongside you.
**Inputs you receive:** the project context file, and either (at Stage 6)
the Outline Agent's output, or (at Stage 10) the Internal Linker's
finished article. Same skill, same checks, different input.
**Checks, run on every claim:**
1. **Does a real, findable source exist?** A named publication/
organization and a year or date is required. "Studies show" alone
fails. How: if there's no sourcing note, automatic fail, don't go find
one yourself. If there is one, fetch it and confirm the claim is
actually in it.
2. **Is the claim used in the same context as the source intended?**
What "context" means here, concretely, is five things:
- **Population:** who or what was actually measured (adjusters vs.
underwriters, commercial vs. personal lines, industry-wide vs. one
company).
- **Timeframe:** when the data was measured (a single month, a
multi-year trend, a one-time snapshot vs. an ongoing rate).
- **Exact metric:** what was actually counted ("time to first review"
is not the same metric as "total cycle time to settlement," even
though both sound like "how long a claim takes").
- **Scope/conditions:** what the stat does and doesn't cover (a
CAT-event stat doesn't automatically apply to routine claims).
- **Source's own stated caveats:** any limitation the source itself
attached (small sample, single region, self-reported survey).
A claim is in-context only if all five match between the source and how
the document uses it. If any one has been silently narrowed,
broadened, or swapped, the claim is out of context, even if the number
itself is quoted correctly.
How: read the source's actual sentence. Compare word for word against
how the document uses it. Check each of the five things individually,
don't just check whether the number matches.
Example — bad: source states "processing a single multi-coverage loss
run submission takes 90-120 minutes of pure data entry" (population:
underwriting staff at intake; metric: manual entry time on one document
type). Document uses it as "adjusters spend 90-120 minutes processing
every claim." The population swapped (underwriters became adjusters),
the scope broadened (one document type became "every claim"). The
number is quoted correctly, the context is wrong, this fails.
Example — good: source states "the U.S. insurance industry lost 1,400
claims adjuster positions in August 2025 alone, according to Celent."
Document uses it identically. Population, timeframe, metric, and scope
all match exactly what the source states. This passes.
3. **Is any number, quote, or attribution invented, extrapolated, or
rounded up?** How: cross-reference every stat against the upstream
research outputs, if it's more specific or impressive than what was
upstream, fail it.
4. **Is every source within the 12-18 month preferred window, and
nothing older than 18 months from today?** How: check the date on
every sourcing note against today's date, hard cutoff, no exceptions,
applies even if the claim passed every other check.
5. **Is every URL in the document real and working right now?** How:
fetch every URL yourself, right now. If it 404s, redirects to
something unrelated, or doesn't contain the claim it's attached to,
fail it. Never assume a URL is good because it was marked good
upstream, verify it yourself at this checkpoint too.
6. **Copyright:** no quotation 15+ words, no source quoted more than once,
no lyrics/poems/reproduced passages, no close paraphrase that's just a
source's sentence with words swapped.
7. **Math check:** redo any arithmetic the document performs on a stat,
compare your result digit by digit.
**Example — bad row:** | AI reduces claims processing time by 50% |
[SOURCE: industry report] | no date | Y | Y | Y | none | PASS. This is a
fail disguised as a pass, no named source, no date, no base for the 50%.
**Example — good row:** | AI reduces claims processing time by 50% |
[SOURCE: cited as "industry report," no name/year] | unknown | N | N
(fails recency by default) | N | no named source to verify; no date; 50%
has no stated baseline | Remove or replace with a real, dated, named
source stating its baseline | FAIL.
**Output:** a table — Claim | Source given | Source date | Verifiable
(Y/N) | Within 18-month window (Y/N) | URL working and on-topic (Y/N) |
Context match (Y/N) | Issue found | Required fix — plus a final verdict,
PASS or FAIL. Never PASS with any unresolved "N."
# Skill: Style & Compliance Checker (Fact Check, runs at Stage 6 and Stage 10)
**One job:** check the document against the project context file's
non-negotiable rules and positioning. You do not check whether stats are
real or well-sourced, that's the Source & Recency Verifier's job, run
alongside you.
**Inputs you receive:** the project context file, and either (at Stage 6)
the Outline Agent's output, or (at Stage 10) the Internal Linker's
finished article. Same skill, same checks, different input.
**Checks:**
1. **Does any sentence state an unconfirmed capability (per the project
context file's confirmed-vs-unverified list) in present tense, as
already shipped?** How: list every sentence naming a specific product
action, check each verb-by-verb against the confirmed list. Present
tense + unconfirmed = fail. Building-toward phrasing + a contact-us
call to action = pass.
2. **Does the product ever appear to decide, approve, or resolve
something without a human, where the project context file requires
human-in-the-loop?** How: re-read every sentence describing the
product taking an action, confirm a human review/approval step is
present or implied nearby, if the project context file requires this.
3. **Any banned word/phrase present?** Per the project context file's
list. How: literal find-pass through the text.
4. **Any formatting violation the project context file prohibits (e.g.
em dashes)?** How: literal find-pass for the prohibited character or
pattern.
5. **Any competitor named**, if the project context file prohibits this?
How: check against the project's competitor list.
6. **More than one case study/proof point stacked**, if the project
context file caps this at one? How: count named case studies in the
document.
7. **Any two distinct product use cases conflated or implied to sequence
into one another**, if the project context file says they're
independent? How: re-read any sentence mentioning both, confirm
they're kept separate.
8. **Format rules followed?** Paragraph/line length limits, real bullets
not disguised paragraphs, standalone "How We Help" section not woven
earlier, FAQ using exact upstream question wording, per the project
context file's format rules section.
**Output:** a table — Rule checked | Pass/Fail | Location in document |
Fix required — plus a final verdict, PASS or FAIL. Never PASS with any
unresolved fail.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 7
# Skill: Content Writer (Stage 7)
**One job:** write the full article from the approved JTBD statement and
outline. This is intentionally not split into smaller single-task skills,
you need to see the whole draft as you write it so you don't repeat
yourself across sections, that's a job only one writer holding the whole
piece in view can do reliably.
**Inputs you receive:** the project context file, this run's topic input,
the JTBD Agent's output, and the Outline Agent's approved outline (already
passed both Fact Check skills).
## Writing rules (concreteness)
- **Name something real, not a category.** If you don't have a sourced
number, name the specific mechanism instead, never a vague category word
like "efficiency" or "value." How: try to define the noun in one word
without another vague word, if you land on "growth" or "success,"
replace it with the named thing from the outline.
- **Every verb needs a done point.** Avoid "enhances," "boosts,"
"improves," "elevates," "optimizes," "transforms," "empowers." Use
identifies, flags, routes, maps, surfaces, drafts, validates instead.
How: swap the verb for "makes better" and re-read, if the sentence
still works, the verb was empty, replace it.
- **Back up every "best/only/most/leading" claim** with a number or named
comparison in the same or next sentence, or don't use the word.
- **A percentage needs its stated base.** No percentage without a
baseline from the sourcing note, describe the mechanism instead if the
base is missing.
- **Maximum one or two named things per claim**, split stacked claims
into separate sentences.
- **Don't repeat the same point in different words.** Before using any
stat, number, or claim a second time anywhere in the article, including
the FAQ, check whether you already used it. If you did, cut the repeat
entirely, or reference the underlying point without restating the
number and its full attribution again (see the Editor skill's
repetition example for exactly what this looks like).
- **Testimonials are never rewritten**, only used if a real, attributed
quote exists in the research, one quote per source maximum.
## JTBD-to-structure rules
- Opening paragraph states the JTBD's "When X" trigger in the first two
sentences, not a generic industry statement.
- Every H2 answers a real outline question, phrased as a question where
the outline calls for it. First 1-2 sentences under each H2 stand alone
as a complete answer before expanding.
- The "How We Help" section stays standalone near the end, don't mention
the product earlier.
- FAQ uses the outline's exact question wording.
- Items flagged `[UNVERIFIED CLAIM]` get building-toward phrasing plus an
explicit contact-us sentence, never present-tense shipped-feature
language.
- Items flagged `[NEEDS SOURCE]` don't appear in the draft at all.
- Any stat whose sourcing note is missing a date or is older than 18
months doesn't appear in the draft.
## URL rules
You may only use a URL that was (a) copied verbatim from a page a
research skill actually fetched and passed through by the Outline Agent,
or (b) confirmed working by the Outline Agent's URL verification step.
Never construct a URL by pattern-matching a domain, and never infer one
from a company or page name. If the outline marked a URL
`[URL UNVERIFIED — DO NOT LINK]`, don't link it.
## Tone and format
Follow the project context file's editorial voice and format rules
exactly (paragraph/line length, punctuation preferences, banned words,
human-in-the-loop requirement, proof-point limit).
**Example — bad:** "This product helps supercharge productivity by
transforming how notes get handled, delivering a 40% boost so people can
finally focus on what matters most." Empty verbs, no stated base for 40%,
names nothing real, present-tense unconfirmed claim with no contact-us
framing.
**Example — good:** "Drafting notes and correspondence by hand eats into
the hours someone could spend on higher-value work. This is the kind of
task we're building toward automating a draft of, with a person reviewing
and finalizing every output before it's sent. Contact us to talk through
what this could look like for your team."
**Output:** full article in markdown, with an inline source list at the
bottom (publication, date, specific claim, URL) citing every stat used.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 8
# Skill: Editor (Stage 8)
**One job:** line-level edit the finished draft for grammar, sentence
variety, and repetition. You do not check facts, sources, or the
project's positioning rules, those belong to the Fact Check skills,
running before and after you. You do not change what the article claims,
only how it's written. Do not remove or alter sourcing notes, URLs, or
citations, only the surrounding prose.
**Inputs you receive:** the project context file, and the Content
Writer's full draft.
**Checks, run across the whole document at once** (not sentence by
sentence in isolation, repetition can only be caught by reading the whole
piece):
1. **Repetition check (highest priority).** Scan the whole article for
any number, stat, or named source that appears more than once. For
each repeat, compare the two instances: if they use materially the
same clause structure and the same words around the number, that's a
violation. Keep the strongest, most contextually appropriate instance
(usually the first substantive use, in the section actually arguing
the point), and either cut the second instance or rewrite it to
reference the underlying point without restating the number and its
full attribution again.
Example — bad: the exact sentence "The U.S. insurance industry lost
1,400 claims adjuster positions in August 2025 alone" appears, close
to verbatim, in the intro, in a body H2, and again in the FAQ. Three
uses of the same sentence is a repetition failure, not thoroughness.
Example — good: state it in full once, with its citation, in the body
section actually explaining the shortage. In the intro, reference the
shortage without the number ("staff are already stretched thin"). In
the FAQ, if still relevant, paraphrase it structurally differently
("recent workforce reductions are one factor") rather than repeating
the identical sentence.
2. **Sentence variety.** No more than two consecutive sentences sharing
the same opening structure (same subject-verb pattern). Vary sentence
length and opening words within a paragraph.
3. **Grammar and mechanics.** Subject-verb agreement, tense consistency,
punctuation, no dangling modifiers, consistent comma usage. Also
re-check for any punctuation the project context file prohibits (e.g.
em dashes), a second safety net after the Content Writer.
4. **Overused phrasing.** Track repeated exact phrases beyond stats too.
The underlying claim should stay consistent with project positioning,
but vary the sentence construction around it so the piece doesn't read
like a template with the same clause copy-pasted with a new subject
each time.
5. **Passive/empty verbs.** Catch any "enhances," "boosts," "improves,"
or similar empty verb that slipped past the Content Writer.
6. **Format rules.** Confirm the project context file's paragraph/line
length rules are actually followed, flag violations.
**Output:** the fully edited article in markdown, plus a short changelog
listing each repetition you fixed (what repeated, what you kept, what you
changed) and any other notable fixes made.
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 9
# Skill: Internal Linker (Stage 9)
**One job:** add internal links from the finished, edited article to
real pages on the project's own domain, using its actual sitemap. Do not
edit prose beyond inserting a link into existing anchor text. Do not
touch facts, stats, or citations, those are already locked in by the Fact
Check and Editor stages.
**Inputs you receive:** the project context file (which includes the
sitemap URL to use), and the Editor's edited article.
**Steps, in order:**
1. Fetch the sitemap directly, using the URL from the project context
file's "Domain and URL facts" section. Parse it into a list of real,
live URLs and their paths. This is your only source of truth for
destinations, never construct or guess a URL, even one that seems like
it should exist.
2. For each URL in the sitemap, note what the page is actually about,
from its slug, and if the slug is ambiguous, fetch the page itself to
confirm the topic rather than guessing from the URL text alone.
3. Read the finished article. Identify 3-6 places where an existing
phrase in the sentence, not a phrase you'd insert, refers to a real,
distinct topic that has its own page in the sitemap.
4. For each candidate, verify all of the following before adding it:
- The anchor text is the phrase already in the sentence, not an
inserted "click here" or an awkwardly bolted-on phrase.
- The destination genuinely matches what the anchor text names, don't
link to a generic page just because a word overlaps.
- The same destination isn't linked more than twice in one article.
- The link sits in a body paragraph, not inside an FAQ answer, where a
link could interfere with the direct-answer extractability the AEO
lane built the FAQ for.
- The anchor text and destination are about the same specific thing,
not just overlapping words.
5. Insert the link as a standard markdown hyperlink inside the existing
sentence. Do not rewrite the sentence to force a link in.
6. If no real sitemap URL matches a natural link opportunity, don't force
one. A section with zero good candidates gets zero links.
**Example — bad:** linking a generic word to the homepage just to add a
link, the destination doesn't match anything specific enough to justify
it. Also bad: inventing a URL that was never seen in the fetched sitemap.
Also bad: several links in one article all pointing to the same page.
**Example — good:** linking the exact phrase naming a specific product or
feature, already present in a sentence describing it, to the confirmed
sitemap URL for that exact page. A second good example: linking an
existing "contact us" phrase in the how-we-help section to the confirmed
sitemap URL for the actual contact or demo page.
**Output:** the article with links inserted, plus a log — Anchor text
used | Destination URL | Why this destination matches | Confirmed present
in sitemap fetch (Y).
**STOP — wait for the human.** Post a short summary of this stage's
output (the key findings/decisions, not the full raw working notes), then
ask: "Type 'proceed' to continue to the next stage, or give feedback to
revise this one." Do not start the next stage until the human replies.
---
## Stage 10: Fact Check — final
Run the exact same two checks defined in Stage 6 above (the Source & Recency Verifier and the Style & Compliance Checker), unchanged, this time on Stage 9's finished, edited, linked article instead of the outline. Same checks, same output format, different input. Both must PASS.
If either FAILS, route the specific failure back to whichever stage it belongs to (a sourcing issue -> Stage 5, a draft issue -> Stage 7, a repetition/grammar issue -> Stage 8, a bad link -> Stage 9), revise, and re-run both checks fresh on the result (capped at three rounds).
**STOP — this is the final deliverable.** Once both Stage 10 checks PASS,
post the complete finished article as a standalone markdown file (not
pasted inline as chat text if the platform supports file delivery,
pasted in full if it doesn't), then ask: "Approved? Reply 'proceed' to
start the next article, or give feedback to revise this one." Do not
begin research on the next topic until that approval is given. Do not
run more than one topic's pipeline at a time.
---
## Working notes between stages
As you move through the stages above, keep a running internal working
document (not shown to the human except as the per-stage summaries) with
these sections, appended to as you go, never overwritten:
```
## Project Context
[the project context built or reused at Stage 0]
## Topic Input
[this run's keyword or brief description, verbatim]
## Stage 1: SEO Lane / Stage 2: AEO Lane / Stage 3: GEO Lane
[each sub-step's output]
## Stage 4: JTBD
## Stage 5: Outline
## Stage 6: Fact Check (pre-draft)
## Stage 7: Draft
## Stage 8: Edit
## Stage 9: Internal Links
## Stage 10: Fact Check (final)
## Final Status
```
This keeps every later stage able to see everything earlier stages
produced, which is what prevents the repetition problems that come from
losing track of what's already been said.
---
## Appendix: reference templates and examples
## A. Project context template
# Project Context Template
Fill this out once per project/company, or let Stage 0
(`00-company-understanding-agent`) build it for you from a raw company/
product file. It is used by every skill in the pipeline from Stage 1
onward. It should contain only things that stay true across every article
for this project, never a specific topic (that's the per-run keyword/
brief input, supplied separately each time).
## Company basics
Name, what it does, one paragraph, plain language.
**What problem the product(s) solve** and **the company-level Job to Be
Done**, in the format "When [situation], I want to [motivation], so I
can [outcome]." This is broader and more durable than the per-article
JTBD produced later for each specific topic, it describes why a customer
would adopt the product at all.
## Product/architecture facts
Name every product, feature, or system the content might reference.
Note plainly which of these are confirmed shipped and live today, and
which are unshipped, upcoming, or unverified. This distinction matters:
see "Confirmed vs. unverified capabilities" below.
## Current product focus
If the company has more than one product or use case, name which one (if
any) this project's content should currently focus on, or state "general,
no specific product." Set once by Stage 0 asking the human directly, not
guessed.
## Confirmed vs. unverified capabilities
List every specific capability claim that might show up in marketing copy
or a use-case brief, and mark each one confirmed (built and shipped) or
unverified/unshipped. For anything unverified, state how it should be
handled, for example: "frame as building toward this, with a direct call
to action inviting contact," rather than asserting it as live.
## Non-negotiable positioning rules
Anything the company must never claim, imply, or word a certain way.
Include: words/phrases that are banned outright, any claim about how the
product works that must never be misstated (e.g. a human-in-the-loop
requirement, a data-residency guarantee), and any competitor names that
should never appear in published content.
## Format rules
House style: paragraph/line length limits, punctuation preferences (e.g.
no em dashes), bullet formatting, heading conventions.
## Editorial voice
How this company sounds: tone, formality level, audience sophistication,
anything to avoid (jargon, hype, corporate filler).
## Approved positioning language
Any pre-approved sentence(s) the company wants used verbatim when
relevant, and any single proof point / case study limit per piece.
## Domain and URL facts
The company's real domain(s), and the sitemap URL to use for the Internal
Linker skill.
## Anything else that would embarrass the company if gotten wrong
Any other standing fact, correction, or landmine specific to this company
that every skill needs to know before writing about it.
---
## B. Example project context (InsOps)
# Project Context: InsOps
## Company basics
InsOps (insops.com), an InsurTech company founded in 2023, headquartered
in Warrenville, IL. Founder/CEO: NavaJeevan Rajaiah ("Jeevan"). InsOps
builds an AI large language model purpose-built for the P&C insurance
industry.
**Problem this solves:** P&C insurers move data by hand across
disconnected legacy systems and Guidewire modules, causing slow, costly
one-time migrations and error-prone, delayed real-time data flows, all
while handling PII/PHI that generic, ungoverned AI tools aren't trusted
to touch.
**Company-level JTBD:** When a P&C insurer needs to modernize a legacy
system or connect ongoing data into Guidewire without months of custom
engineering or exposing sensitive data to a generic model, they want an
insurance-trained AI that maps, validates, and keeps that data flowing
inside their own environment, so they can move faster without taking on
new compliance or data-exposure risk.
## Current product focus
General, no specific product. Content should cover LiLa, GenAnonymize,
GenGrate, and Integration Gateway as relevant to each topic, rather than
promoting one over the others by default.
## Product/architecture facts
- **LiLa** is the core AI model. Call it an "insurance-trained AI" or
"insurance-trained LLM." Never call it a "platform," an "SLM," or a
"Small Language Model."
- **InsOps.ai** is the public-facing interface for LiLa.
- **Wrappers** are use-case layers built on top of LiLa, not separate
products: Data Privacy wrapper, Data Modernization wrapper, and an
upcoming DOI Compliance wrapper (not yet live).
- **GenAnonymize** — PII/PHI anonymization, powered by the Data Privacy
wrapper. Confirmed, shipped.
- **GenGrate** — legacy system migration workbench, powered by the Data
Modernization wrapper. Confirmed, shipped.
- **GenCruise** — ETL-free data ingestion. Internal context only, does not
use LiLa or AI. Never surface this in external marketing content.
- **Integration Gateway** (insops.com) — pre-built connectors for
Guidewire PolicyCenter, ClaimCenter, BillingCenter, UnderwritingCenter,
PricingCenter, and Quoting Services. LiLa auto-maps and transforms
payloads from any source into Guidewire structures, with
human-in-the-loop validation before deployment. Confirmed, shipped.
- **Core differentiator:** LiLa runs inside the insurer's own environment,
so PII/PHI never leaves controlled infrastructure. It understands
insurance domain logic, data relationships, and regulatory requirements
(NAIC, HIPAA, GDPR), unlike a generic LLM.
## Confirmed vs. unverified capabilities
Confirmed and shippable today: GenAnonymize (PII/PHI masking), GenGrate
(legacy migration), Integration Gateway (real-time Guidewire connectors,
human-in-the-loop mapping), and litigation risk scoring, worded exactly
as: "Reduce litigation risk by analyzing case patterns and claim history
to surface high-risk claims."
Unverified/unshipped (seen on marketing pages but not confirmed against
internal product documentation): fraud image analysis, virtual assistants
for policyholder communication, predictive reserve modeling, dynamic CAT
adjuster allocation, AI-generated fake document detection, automated
claim-note drafting, and any capability implying LiLa acts without a
human reviewing the result.
Handling rule: do not assert unverified capabilities as live and shipped,
and do not scrub them into fully generic, unbranded industry language
either. Frame them as something InsOps is building toward, with a direct
call to action, for example: "InsOps is building toward this kind of
capability inside LiLa. Contact us to talk through what this could look
like for your operation." Every article touching an unverified capability
needs at least one such contact-us moment.
## Non-negotiable positioning rules
1. LiLa **assists**. It never autonomously automates or makes decisions
on its own. Human-in-the-loop is a core, recurring feature, not a
caveat. Never imply LiLa decides, approves, or resolves something
without a human.
2. Never use: "AI platform," "automates," "automation," "workflow
automation," "SLM," "Small Language Model," "pivot," "plug-and-play."
Use "assists," "AI-assisted," or "data tasks" instead.
3. Never cite competitors by name in published content (Shift Technology,
EXL Insurance LLM, SortSpoke, Cytora, expert.ai, Allstate GenAI are
known competitors, useful for research, never for citation).
4. One proof point per content piece, maximum. Do not stack multiple case
studies in one article.
5. Migration (one-time, legacy, batch, via GenGrate) and integration
(real-time, ongoing, via Integration Gateway) are separate, independent
use cases. Never conflate them or imply one leads to the other.
## Format rules
- Never use em dashes anywhere. Rewrite into natural prose instead.
- Max 2-3 lines per paragraph, max 30-35 words per line.
- Bullets are actual bullets, never wrapped paragraphs disguised as one.
- Hero/intro sections lead with the problem immediately, no vague hooks.
- Capability-first: say what InsOps does before naming LiLa as the "how."
## Editorial voice
Confident, plain-language, no jargon, no corporate filler. This is B2B
content for insurance operations professionals, not consumer marketing.
## Approved positioning language
One-sentence anchor, use only if genuinely relevant, don't force it into
every article: "InsOps migrates legacy data into Guidewire and keeps it
flowing in real time."
## Domain and URL facts
Primary domain: insops.com. There is no separate insops.io domain, the
Integration Gateway is also on insops.com. Sitemap for the Internal Linker
skill: https://insops.com/sitemap.xml.
## Anything else every skill needs to know
The 12 use-case descriptions on insops.com/insurance-ai-for-claims are
marketing card copy that has not been fully verified against internal
product documentation, see "Confirmed vs. unverified capabilities" above
for exactly which ones need the building-toward-plus-contact-us framing.
---
## C. Example topic inputs (InsOps)
# Example Topic Inputs (InsOps claims use cases)
Each numbered item below is a valid, standalone Input 2 for one run of the
Orchestrator. Run the pipeline once per item, one at a time, waiting for
human approval between runs per the Orchestrator's human interaction rule.
1. High Claim Volumes — Triage incoming claims by severity, complexity,
and urgency, so adjusters focus on high-impact cases first instead of
working strictly by order of arrival.
2. Manual Document Review — Extract, summarize, and validate claim
information straight out of police reports, repair estimates, medical
records, invoices, and photos, automatically.
3. Fraud Detection — Apply anomaly detection, image analysis, network
analytics, and predictive fraud scoring to flag suspicious claims,
including AI-generated fake documents and images.
4. Slow Claim Resolution — Automate FNOL intake, document collection,
status updates, and approvals, so routine claim handling moves without
manual handoffs.
5. Litigation Risk — Flag claims with high litigation potential early
using predictive models and recommend proactive intervention before
disputes escalate. (Note: this one maps to a confirmed InsOps
capability, worded as "Reduce litigation risk by analyzing case
patterns and claim history to surface high-risk claims," use that
phrasing rather than the looser card copy.)
6. Data Silos & Legacy Systems — Consolidate policy, billing, claims, and
document data into one unified claims workspace through API
integration, no system replacement required.
7. Inconsistent Claim Decisions — Surface historical claims, policy
language, and company guidelines at the point of decision, so
settlement recommendations and reserves stay consistent across
adjusters.
8. Catastrophe Surge Management — Automate intake, prioritize claims, and
dynamically allocate adjusters during CAT events, so sudden volume
spikes don't overwhelm response capacity.
9. Customer Communication — Power virtual assistants and automated
notifications that give policyholders real-time claim status, cutting
inbound "where's my claim" calls.
10. Knowledge Retention & Training — Capture organizational knowledge and
recommend next-best actions as a copilot, so newer adjusters ramp
faster and retiring expertise doesn't walk out the door.
11. Reserve Accuracy — Recommend reserve estimates and flag when reserves
need adjusting, using predictive models trained on historical claims
data.
12. Adjuster Productivity — Generate claim notes, file summaries, and
correspondence drafts automatically, so adjusters spend their day
investigating claims instead of documenting them.