While preparing Woong Works, I went back through old project folders: drafts, code, test records, and emails I had sent. Some work had led to a published paper or a public dataset that its provider had actually replaced. Much of it had stopped after submission or implementation. I want these accounts to show what I tried and which results I could verify.
The decisions behind a result are worth keeping too. The choice of data, the comparison I made, or the conditions under which a calculation differed from the expected result can help someone working on a similar problem. Reusable code and passed tests belong in that account, without turning them into sales, sustained use, or a published paper.
Reading several files as one project
Drafts and code for the same problem can be scattered across folders, and a later review may change an earlier judgment. Rather than choosing the latest version by its filename, I trace which inputs produced the result and what changed afterward, then check how much of that work reached the public version.
A file named FINAL may have been followed by another revision. A published article may also contain a correction or resource missing from the local manuscript. I bring the valid parts together while preserving the earlier records for comparison. I write the Korean and English accounts separately, but count the project they describe once.
Before using a number, I check what it counts. In the herbal-data correction account, “333 changed cells” means fields whose values differ between the files before and after replacement by the National Institute for Korean Medicine Development. It does not establish that 333 errors were all correctly repaired. Results from code or another tool also need an account of the inputs, the check, and the extent of the review, so that someone else can make a comparison within that scope.
A stopping reason, or something still unknown
When I return to a project that stopped, I distinguish a reason documented at the time from my interpretation now. I do not fill gaps with plausible feelings or conversations. Where I have not established a reason, I leave it unconfirmed.
The same care applies to reader numbers. Writing zero for a count I have not measured would say that nobody read the work. I use unknown when the count has not been established, and zero only when the evidence supports zero. Work without a confirmed external outcome may still leave reusable code or a useful comparison method; I describe those assets separately from the final outcome.
Checking evidence does not by itself make the material suitable for publication. Unpublished manuscripts, peer-review correspondence, personal information, and conversations without permission for public use stay out of the article. For papers or code already made public, I check and link to the relevant version. Public access alone does not grant permission to redistribute it.
Connecting later changes
When a provider corrects a file or the original project credits a contribution, I connect that follow-up to the earlier account. The event date, the date I checked the evidence, and the article's revision date can differ, so I record them separately. A material correction should remain findable.
I hope someone working on a similar problem finds material to compare, and someone considering working with me can examine the decisions I made. I am continuing to revise the accounts so that a brief reading explains the problem and its current state, while a closer reading leads into the data and implementation.