EZO Content Pipeline
For: Shoaib Hassan
From: Brent Bartosch
Date: 2026-08-05
You asked for the step-by-step with validation at each stage, what is locked, what is blocked, and where you can help. That is exactly the order below. One page per stage, five stages, and a straight answer on state for each.
Every number in this document is counted off disk at the moment it was generated. Nothing here is asserted from memory, and if a stage had produced nothing it would say zero.
3 of 5 stages are locked. 2 are still moving. 0 are blocked on anyone.
| Stage | What it does | State |
|---|---|---|
| 1. Pick the topic | Ranks what Qasim's research already surfaced, ordered by how many verified facts sit behind each topic. | LOCKED |
| 2. Write the brief or the blog outline | Pages get a brief in the PMM team's own Phase-5 shape. | LOCKED |
| 3. Write the draft | The draft is written into the SOP's own section structure from the start, so it does not have to be reshaped afterwards. | LOCKED |
| 4. Check it | Three separate checks, in order. | RUNNING |
| 5. Hand it over | The artifact lands as a comment on the Asana task the owner already has, with the document shared to them directly. | RUNNING |
Nothing in this process is blocked on you or on anyone at EZO. The two stages still moving are moving because of decisions that are genuinely yours and Qasim's to make, not because something is broken. Those are collected at the end.
What locked means here: the stage runs end to end, has produced artifacts you can open, and its rules come from your documents rather than from me. It does not mean finished forever.
State: LOCKED
What happens. Ranks what Qasim's research already surfaced, ordered by how many verified facts sit behind each topic. It does not invent topics and it does not do keyword research.
What gets validated before it moves on. A topic with no facts behind it is refused rather than drafted. That refusal is the validation - it is why nothing downstream has to guess.
Evidence on disk. 1,258 verified facts in the store, each with a source behind it.
Where you can help. Nothing needed. This one is done.
What is still open. Keyword research is not wired in. SEMrush is the v1 plan and Qasim's keyword prompt is extracted but not running, so today the ranking is fact-density, not search volume.
State: LOCKED
What happens. Pages get a brief in the PMM team's own Phase-5 shape. Blogs get an outline instead. The fan-out query method builds the question tree first, so the brief is answering real questions rather than a writer's guesses.
What gets validated before it moves on. Every claim in the brief carries its source. A brief that cannot source a number does not get to state it.
Evidence on disk. 32 briefs and 12 blog outlines produced.
Where you can help. Nothing needed.
What is still open. The fan-out prompt is Qasim's and runs on the model lineage he wrote it for. Confirmed, not an open question.
State: LOCKED
What happens. The draft is written into the SOP's own section structure from the start, so it does not have to be reshaped afterwards. It rewrites the brief's language rather than lifting it, and the FAQ section is generated by Qasim's own FAQ prompt.
What gets validated before it moves on. A sentence that survives verbatim from the brief is a finding, because Rida Fatima's standard is that the draft keeps the context and changes the grammar, structure and tone.
Evidence on disk. 27 drafts produced. The FAQ stage has produced FAQs through Qasim's own V2 prompt, verbatim, on 1 run(s). Open pipeline/runs/faqgen-proof-20260805-202526/faq-proof.md to read them.
Where you can help. Nothing needed to run it. Worth your eyes on whether the rewrite standard matches what your reviewers actually want.
What is still open. The rewrite rule and the FAQ stage both landed on 2026-08-04. Rida's own page has not been re-drafted through them yet, so the improvement is real in the code and not yet visible on her page.
State: RUNNING
What happens. Three separate checks, in order. The rule checker measures the 63 mechanical rules taken from your team's own documents - character counts, section order, how many items in a section. The AI reviewer reads for the things a rule cannot see. The human reviewer is the person who owns the page, and nothing skips them.
What gets validated before it moves on. A page needs 80 out of 100 and zero critical findings to pass. Every finding names the rule and the document the rule came from, so it can be argued with.
Evidence on disk. 63 rules across four page types, each traceable to a team document. Full inventory in the rule inventory document.
Where you can help. This is where you can help most. The severity of each rule - which failures should stop a page and which are advisory - was set by reading your documents, not by asking you. Qasim has the same question about weighting. An hour on the rule inventory would settle both.
What is still open. Scoring is unweighted: every rule counts once. That was a deliberate choice, not an oversight, and whether it stays that way is Qasim's call to make.
State: RUNNING
What happens. The artifact lands as a comment on the Asana task the owner already has, with the document shared to them directly. Pages go to the design and web team as a build package. Blogs land in WordPress as a draft, never published, and only when someone has explicitly armed that run.
What gets validated before it moves on. It refuses to guess whose task to post on. An ambiguous match posts nothing, because posting into the wrong person's task is worse than posting nothing.
Evidence on disk. 78 runs carry full provenance. 1 build package produced for design.
Where you can help. Tell me if the comment format is wrong for how your team actually reads a task. It has been rewritten once already on Rida's feedback and it can be rewritten again.
What is still open. No visual components yet. The build package lists the artwork design has to produce, but nobody on the design side has been walked through it. That handoff is a person, not a script.
Every rule and every prompt above traces to one of your team's own documents. Which means the whole thing quietly becomes wrong the moment one of those documents is edited and nobody re-reads it.
That already happened once. The blog QA process was pulled in July, Qasim revised his FAQ prompt to V2 afterwards, and the pipeline kept running the July version. Nothing looked broken. Rida Fatima found it from the output, not from a warning.
The fix, as of today, is a check that runs at 07:30 on weekdays without anyone remembering to run it:
Why it compares timestamps and not the text: an earlier version compared the pipeline's copy against the document, and both agreed with each other while the real document in Drive had moved on. A check that cannot fail is not a check.
One known gap, stated rather than hidden. A third file the blog rules depend on, blog-qa-process.md, has no Drive document recorded against it, so the check cannot watch it. It is very likely an earlier partial copy of Qasim's QA document, because it lacks the FAQ method that document carries. The check names it as unwatched on every single run instead of quietly covering 2 of 3 documents and reporting success. Qasim has an open task to tell us whether to point it at his document or retire the file.
Three, and none of them need a meeting longer than an hour:
Being straight about the edges, because you asked for validation at each stage and that cuts both ways:
Generated by scripts/build_process_view.py on 2026-08-05. Counts are read from the run history and the fact store at build time, so re-running this after more work produces a current document rather than a stale one.