A rejected brief is a record, not a deletion
Delete a rejected idea and it becomes indistinguishable from an idea nobody ever had. The next generation run will derive it again, from the same evidence, and propose it again.
A rejected content brief is kept and listed rather than deleted, because it is the record that this query was already considered and turned down. That record is what stops the next generation run proposing the same query again. Deleting a rejection destroys the only evidence that a decision was ever made: an absent brief and a rejected brief look identical to anything reading the database, and the process that produced the first proposal will happily produce it a second time from the same inputs.
Deleting a rejected proposal is expensive because the thing that generated it is deterministic enough to generate it again. A brief is derived from stored search results for a query, so the same stored results produce the same reading, the same suggested artefact and the same outline. If nothing durable says a human looked at that and said no, the next run does the work again, a reviewer reads the same page again, and the same verdict is reached at the same cost. Repeat that weekly and the review queue becomes a treadmill.
The failure is worse when several people are involved, because there is no way to distinguish "nobody has looked at this yet" from "somebody looked at this and said no". A queue that cannot express the second state trains people to re-litigate decisions, and eventually to approve something previously rejected simply because nobody remembered.
In Market4 a content brief carries one of four statuses. DRAFT means it was generated and nobody has looked at it. APPROVED means a human read it and said write this. REJECTED means a human read it and said no, and the brief is kept so the next generation run can see that this query was already turned down. USED means a post was created from it, and the brief points at the post. Every one of those is a positive statement, including the negative one.
Because rejection is a state, it can be filtered and counted. Listing briefs by status turns "what have we already decided about" into a question with an answer, which is not something a folder of deleted rows can offer. It also means the queue of live work is honest: a live brief is one that is neither used nor rejected, so rejecting something genuinely removes it from the queue without removing it from the history.
Nobody usefully reviews two thousand words they did not ask for. A brief is one page that says what the article will be, and it exists before the writing does.
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
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.
| Handling | What the next run sees | What a person can find out later |
|---|---|---|
| Delete the proposal | Nothing; it proposes the query again | Nothing |
| Leave it sitting as a draft | An unread item, indistinguishable from new work | That somebody has not got to it |
| Mark it rejected and keep it | A query already decided; it does not re-propose | That it was considered, and on what evidence |
A rejection is worth keeping because the brief around it already contains the reasoning. The record names the query with its country and language, the intent read from the search results, the artefact that intent called for — which may be that nothing should be written at all — the sections that were proposed, the terms that would have had to be covered, and the domains that keep appearing for that query with their positions. Somebody reading the rejection six months later is not reading a bare no; they are reading what the search results looked like when the no was given.
That matters because a rejection is a decision about a moment, not a permanent truth. A query turned down because one competitor owned the entire first page can become winnable when that page changes. The brief holds the competitor table as it stood when the verdict was given, written into the record rather than looked up when it is read, so the comparison against today is a real comparison rather than two readings of the same live data.
Any system where an agent proposes work and a person accepts or declines it needs declines to be durable, for the same reason. An agent that generates candidate actions from the current state will regenerate the declined ones on the next pass unless something in the state records that they were declined. This is why a rejection has to be written where the generator can see it, rather than in a chat message, a meeting or somebody's memory. A decision that lives only in a conversation is not available to the process that caused the conversation.
It also gives the review step a measurable output. If rejections vanish, the only visible product of reviewing is the things that got approved, which quietly makes saying no look like doing nothing. When a rejection is a row, the reviewer who turned down nine bad subjects has nine records to show for it, and the ninth one is not proposed again next week.
Because a deleted idea is indistinguishable from an idea nobody has had yet, and the process that proposed it works from data that has not changed. The next run derives the same plan and offers it again, and a reviewer spends the same time reaching the same conclusion. Keeping the rejection costs one row and removes that entire repetition, which is the cheapest trade available in a review workflow.
Not if the queue is defined as work that is still live. In Market4 a live brief is one that is neither used nor rejected, so rejecting something removes it from the working set while keeping it in the history. Listing by status is what makes both views possible from one collection. The clutter people fear comes from leaving decided items in the DRAFT state, not from recording the decision.
Yes, and the record is what makes revisiting sensible. Search results change, competitors lose pages, and a query that was not winnable can become winnable. Because the brief holds the competitor positions as they stood when the verdict was given, building a new brief and comparing the two is a real comparison. What you should not do is quietly edit the old verdict, because that erases the fact that a considered no once existed.
Whoever is accountable for what gets published, which in a small team is usually one person. The important property is not seniority but that the verdict is recorded against the brief rather than expressed somewhere the generating process cannot see. A rejection delivered in conversation is invisible to the next run, so it does not do the job that a rejection exists to do.
It applies to any queue where something proposes work and somebody accepts or declines it. If declines are not written into the state the proposer reads, the proposer will offer the same work again, and the review loop never converges. Recording a decline is what turns a review from a filter that runs forever into a process that reduces the amount of work over time.
Both can hand a model a block of JSON, so the choice looks cosmetic. It is not. A tool call is a decision the model makes with arguments it invents; a resource read is a fetch the client performs against an address it already holds.