A completed homepage can feel like the end of a large piece of work. Looking back through the planning and operating records for K-POP PULSE, I see how much of the project happened after that screen. Videos and announcements keep arriving. Schedules change. Articles need corrections. I needed a structure that would not make every update a fresh start.
The needs behind this site extended beyond reading the latest news. Someone might want videos about an artist, an upcoming date, or an explanation of an unfamiliar notation. A single round of page design cannot finish those jobs. This story follows the responsibilities I separated in the project, and the choices I would explain first to someone commissioning a website.
New updates and lasting explanations move at different speeds
Official posts keep arriving, but every collected post does not become a new article. One may be a short promotional clip for a release already covered. Another contains an actual schedule. An explanatory guide, meanwhile, can remain useful to the next reader long after the original post. Items that appear on the same website do not necessarily have the same lifetime or handling rules.
I separated incoming material, information to explain to readers and schedules that need continuing correction. The large video area, latest updates, shorts, comeback dates and guide links observed on the public homepage offer a starting point for reading those roles. Seeing those areas does not verify every interaction or prove an operating result. It does show which kinds of information require separate care.
Keep source records separate from the article
The initial design linked collected source items, issues grouping related material, published articles and the particular evidence used in each article. A source item records what was observed. An issue connects material about the same event. The article is the explanation delivered to the reader. Those responsibilities are related without being interchangeable.
A first announcement may be followed by a venue notice or a changed date. Continually overwriting one body of text makes it harder to trace why an earlier explanation was written. My approach was to preserve the original observations while choosing the evidence relevant to the current article. The diagram below was newly created to explain that relationship; it is not a screenshot of the historical application.
Collection and editorial judgment have different responsibilities
The operating procedure moved through reading an inbox, selecting a story, preparing facts, drafting, checking and verifying publication. A collector brings material in. Its classification hint cannot, by itself, decide whether a useful article should follow. The records include a story missed when classification relied too heavily on the form of a title.
When extending automation, I first distinguish a check that material exists from a decision about what a reader needs. Collecting an event notice, confirming that it announces a future event and choosing a useful headline are different steps. Remove those boundaries and a report of active collection can easily be mistaken for a report of good editorial output.
Narrow the facts before asking for a draft
The fact-sheet procedure collected fields such as publication time, artist identity, title and observed counts before drafting. The accompanying constraints prevented the writing step from adding new numbers or describing scenes that had not been watched. Making the voice friendlier was a separate decision from expanding the facts it could use.
This does not guarantee that a model always writes correctly. It narrows what I need to inspect. I must still compare the source, measurement time and date conversion. If a draft is blocked, I read the sentence and its evidence first. Better wording cannot replace missing evidence, and lowering a check merely to pass the draft does not fix the underlying problem.
Publication still leaves things to check
A saved manuscript, an approved publication and an article a reader can actually open are distinct states. The operating records include checking the public response after publication. Whether the article appears in its list, whether its body is right and whether dates carry the same meaning cannot be established by a successful save message alone.
Someone commissioning a site can ask what each administrative button claims to complete, as well as which buttons exist. Taking an article down may stop public access while preserving the original, or it may delete data; those are different promises. To keep maintaining the site, I need that difference recorded in both program state and the working notes.
When operations change, the instructions must change too
The initial architecture description and the later operating document do not describe an identical deployment. The September records reflect a move to local serving through Cloudflare Tunnel. They also describe correcting a publishing procedure that had written through two routes after both routes came to point at the same database.
I therefore do not merge an old design and a later operating procedure into a single diagram labelled current. The next person needs to know where an old command has stopped being valid. A growing website involves retiring incorrect instructions and recording the current connections, as well as adding features.
Questions to write down before building your own site
Not every website needs a newsroom or a collector. A product site has different source material. Bookings or member submissions introduce additional questions about access and personal information. What I would carry from this project is the method of separating decisions, rather than its entire feature list.
I would write actual answers to the questions below before commissioning the operating tools. If an answer is unknown, leave it open and decide who will check it. The page design and the operating program can then be discussed against the same promises.
- Where will new material come from, and how will its original form and observation time be retained?
- Which reader question should an article answer, and who will review its evidence and wording?
- Where will incorrect news or changed dates be corrected, and how can an earlier state be inspected?
- Which step is complete now: saving, publishing or checking the public result? Where can the next operator read that state?
Leave something the next task can use
Alongside this story, I wrote a small editorial board linking source material to a potential story. Selecting synthetic records reveals missing information, conflicting dates and outstanding review. It is a new teaching example, not a recovered copy of this project’s original program. It does not save or publish real articles. Its purpose is to make the structure tangible while considering the conditions another website would need.
More screens are useful only if the next correction has a clear starting point. Finding the original material, reading the changed decision and checking the actual result makes continuation easier for another operator or computer. This series will work through those choices one at a time. If you need help with a particular point, email me with the situation you are facing.