A source address may look sufficient while writing one article from one post. K-POP PULSE brought videos, announcements and schedules together around an event, while one source could produce several editorial questions. Putting everything in one manuscript file made individual claims harder to trace.
The early architecture separates collected items, issue groups, published articles and the sources those articles used. I am not presenting that plan as a copy of the current database. Reading it alongside later editing records explains why sources, judgments and sentences need different lifetimes on another website as well.
A newly collected item is not automatically a new article
A captured item records what was posted. An issue groups material an editor considers part of one event. An article chooses a question to explain to readers. These units are related, but they do not move through the same states or require a one-to-one relationship.
A video and a date announcement can be two sources for one issue. That issue may support a short update and a separate explanation of date notation. Filenames alone do not preserve why the editor considered something a duplicate, a useful addition or a different reader question.
Retaining evidence and revising prose are different operations
The early document treats the captured item as an evidence unit and proposes preserving the material used at publication. That is a historical design intention, not a current test of immutable storage. An implementation’s retention behavior still needs to be checked where it will actually run.
The transferable principle is that rewriting a sentence should not overwrite the reading that supported it. If a source later changes, retain the new reading time alongside the former capture. A subsequent revision should identify which reading it uses. Opening only today’s source address may conceal the reason for an older sentence.
Issue research can be broader than an article’s used evidence
Material inspected while judging a candidate differs from material supporting the final prose. A postponed title, repeated announcement or earlier contextual post should not silently become equivalent evidence for every statement. Otherwise a later reviewer cannot identify which claim requires another look.
I would connect required facts and used captures to each article revision. When several sources support one manuscript, it should be possible to find the announcement supplying a date and the post supplying a title. Authenticating a source and checking that it supports a particular claim remain separate questions.
A failed check makes the relationship useful
In an October 1 cycle, a year in the full description was absent from the shortened fact input, and the draft was blocked. Looking only at the manuscript might have led to deleting that year. The original description, retained evidence and construction rule were needed together to locate the missing material.
Separating source, fact sheet and draft is not classification for its own sake. It leaves routes for asking whether the sentence is wrong, the evidence is truncated or the observation time differs. I also retain a failed result with its input: keeping only passes removes the reason these relationships became necessary.
Start small while defining what each connection means
The model below is a new explanatory sketch, not recovered historical database code or an operational store. It distinguishes an issue reviewed using two captures from a manuscript actually using the first. The identifiers and revision relationships can be adapted to a team’s existing workflow.
The shared editorial board is another new example developed from this relationship. It provides code and a small independent interface for selecting evidence, required facts and conflicts. Core functions were checked; rendered browser interaction remains pending. A check mark in that board does not authenticate truth or establish permission to publish material.
Explore the implementation
New explanatory relationship model; not a current database or recovered schema.
{
"capture": {"id": "capture-a", "observed_at": "actual time", "source_revision": "retained version"},
"issue": {"id": "issue-a", "capture_ids": ["capture-a", "capture-b"]},
"draft": {"id": "draft-a", "used_capture_ids": ["capture-a"], "revision": 1}
}
// New relational sketch. No copied database or immutable-storage implementation.Leave enough context for the next editing session
Another AI or computer needs more than a finished body to continue the work. It needs to find what was read when, what remains uncertain and which manuscripts a change affects. That context lets the next session improve wording without quietly changing earlier facts.
I do not prescribe a fixed number of tables or a technology for every project. A small ledger can be enough at the start. Preserve the meaning of its connections and the time of changes. As the website grows, storing many articles is useful only if those articles can also be reviewed again.