Approve or reject a brief before two thousand words exist
The review that matters happens on one page, not on a finished draft. Approve, reject or mark a brief used, and the rejection is kept so the query is not proposed again.
Read one page and give a verdict before anybody writes the draft. A content brief states the artefact the search intent calls for, a suggested title, the sections page one already covers, the terms every winner mentions, and who owns the query today. Approving or rejecting that page takes a few minutes and reverses nothing; rejecting a finished two-thousand-word draft throws away an afternoon and usually gets waved through instead. The review is worth having at the point where the decision is still cheap.
A content brief in Market4 is built from search-result snapshots the app already paid for, so generating one spends nothing and buys nothing. When there are no stored snapshots for the keyword the tool refuses rather than going shopping, which keeps research spend a separate, deliberate decision. The brief itself holds five things a writer would otherwise reconstruct by hand.
A review placed after the draft measures the wrong thing. By then the reviewer is looking at prose, and prose invites line edits: a heading rewritten, a paragraph moved, an example swapped. The question the brief asks — should this page exist for this query at all — has already been answered by the fact that somebody spent the afternoon. Sunk effort is a poor argument and a persuasive one, which is why the decision moves upstream of it.
Placing the review before the draft also changes what a rejection means. Rejecting a brief is a research finding: this query was considered and turned down, for a reason that can be written on the record. Rejecting a draft is a failure with an author attached to it, and teams learn quickly to avoid producing those, usually by lowering the bar rather than by improving the choice of query.
A prompt composed in an agent's head disappears when the context window rolls. A brief is the same reading written down: one record per query per result page, replaced in place with a revision number, reviewable in one page.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
A Market4 brief carries three possible decisions, and each of them writes something down that is read later. Approve marks it as an instruction a post may be written from. Reject keeps it, listed, as the record that this query was already turned down. Used links a specific blog post to the brief it came from, and it is refused unless the brief was approved first — a draft nobody read is not an instruction, and letting a post claim one would turn the review into decoration.
| Decision | What it records | What it prevents |
|---|---|---|
| Approve | This brief is an instruction a post may be written from | A post claiming a review that never happened |
| Reject | This query was considered and turned down, with the reason | The next research run proposing the same query again |
| Used | This blog post was written from this brief | The reasoning behind a shipped post going missing |
Regenerating a brief replaces the live one for that keyword and bumps its revision rather than creating a second near-identical page. A brief already marked used is refused instead, because it is the statement a published post was written from, and rewriting it would rewrite the reasoning behind something already shipped.
It is kept and still listed. A rejected brief is the record that the query was already considered and turned down, which is what stops the next research run proposing it again. Deleting rejections looks tidy and costs the team the same discussion every few weeks. The reason written into the rejection is the part that does the work, so it is worth a sentence.
No. Marking a brief used requires it to be approved, because used means a specific post was written from an instruction somebody reviewed. Allowing a draft to claim an unreviewed brief would make the review decorative while still producing a record that says a review happened. If the post exists and the brief was never approved, approve it on its merits or leave the link unmade.
Not in Market4. A brief is built from search-result snapshots already stored for that keyword, so the generation is a read. When no snapshots exist the tool refuses rather than buying any, which keeps the decision to spend on research separate from the decision to write. Buying the snapshots is its own step with its own estimate.
Regenerate the brief. Regeneration replaces the live brief for that keyword and bumps its revision, so there is still one brief per query rather than a pile of near-duplicates. A brief already marked used cannot be regenerated, because it describes the reasoning behind a post that has already shipped. Write a new brief for the new attempt instead.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.