Most company blogs die the same way. Someone writes enthusiastically for a few months, the posts get further apart, and the last one is dated two years ago. It is not a lack of ideas. It is that writing well, regularly, on top of a full job, is repetitive work given to the busiest person in the building.
EPC Path, a property data product my team at B4Mind built, takes a different approach. It publishes an article every two days, on London's EPC C 2030 deadline and what the data says about it, and nobody writes those articles by hand. This essay describes how the pipeline works, the failures it is designed to catch, and the one place a human still looks. It is a small example of a bigger idea: give repetition to systems and keep judgement for people.
Why a blog, and why this one
EPC Path exists because of a regulation. From 1 October 2030, privately rented homes in England must reach EPC C. Landlords, agents and installers search for answers about that rule, and increasingly they ask AI assistants too. A steady stream of accurate, data-led writing is how a new product becomes the source those searches and assistants trust.
It also suits automation unusually well. The underlying data is structured and public: millions of energy certificates, ownership records, borough-level patterns. The rules are written down. And the readers care about accuracy above style. A beautifully written article with a wrong date or an inflated number would do real damage to a compliance product. So the system was designed around checking first, writing second.
The pipeline
There are four stages, and each one produces something a person can inspect.
First, the topic and the data. The system picks a question that is worth answering, such as how a particular borough compares with the London average, or what share of homes in a segment are close to a C. It then pulls the relevant figures from the same database the product uses. The article starts from numbers, not from a blank page.
Second, the draft. The system writes the article from those figures, following a style guide: plain British English, answer first, no exaggeration, cost figures described as indicative ranges rather than quotes. It writes for both people and machines, with clear headings and a short summary at the top, because the same article needs to work for a landlord reading it and for a search engine or AI assistant deciding whether to cite it.
Third, the check. This is the stage that matters most. Every factual claim in the draft is compared against the data it came from and against a written rule set. Does each number match the database? Is the 2030 date stated correctly? Is any cost presented as a quote rather than an estimate? Does the article make a claim about the law that the rules do not support? Does it name anyone it should not? A draft that fails any check is not published. It is either rewritten and checked again, or set aside with a note explaining why.
Fourth, the chart and the publication. Charts are generated directly from the data rather than drawn by hand, so the picture and the numbers cannot drift apart. Then the article is published, and the system records what it did.
Accuracy is not a final read-through. It is a stage of the process, with rules, that every piece must pass.
The failures it is designed to catch
Systems like this fail in predictable ways, and the design starts from those failures rather than from the happy path.
The most dangerous is the confident wrong number. Language models are good at producing fluent text and can be careless with figures. The fix is structural: numbers come from the database, and the check compares every figure in the text with its source. A number that cannot be traced is treated as an error.
The second is regulatory drift. A rule changes, or guidance is updated, and older content quietly becomes wrong. The rule set is the single place where the current position is written down, so updating it updates what every future article is checked against. Regulation is tracked as part of running the product, not as an afterthought.
The third is tone. A compliance product that sounds alarmist, or that promises outcomes it cannot guarantee, loses trust quickly. The style rules forbid exaggeration and require estimates to be labelled as estimates. These are checked just as the facts are.
The fourth is repetition. A system that publishes every two days can easily say the same thing again and again. Topic selection takes into account what has already been published, and favours questions the data can answer in a new way.
The one place a human still looks
It would be wrong to describe this as a blog with no people involved. It is a blog with no one doing the repetitive part.
A person owns the rule set. Deciding what counts as accurate, what the product will and will not claim, how the law should be described and what tone is right are judgement calls, and they belong to someone accountable for them. When the rules change, a person changes them.
A person also reads the system's report. Every cycle produces a short record: what was published, what failed the check and why, what was set aside. Reading that report takes minutes, and it is where problems are spotted early. If the same check keeps failing, the process needs improving. If an article performs unusually well, it suggests where readers' questions are. The human role has moved from editing posts to improving the process that makes them.
What this generalises to
I find this pipeline useful less for what it says about blogs than for what it says about work. Almost every company has tasks like this: regular, structured, important to get right, and quietly given to whoever is most capable. Reports to clients, compliance updates, follow-ups, monthly summaries.
The pattern that works is the same each time. Start from the data, not the blank page. Write the rules down. Make checking a stage, not a hope. Have the system report on itself. And keep a person in charge of the rules and the decisions that genuinely need judgement.
Done that way, the work gets done every time, to a standard you have written down, without depending on anyone having a free afternoon. That is what a system that doesn't need you looks like in practice. It still needs a team. It just does not need any one person to remember to do it.