Writing about unfinished work can be useful when it makes the current question, proposed approach and remaining uncertainty clear. It becomes misleading when a plan is described as an implemented system or a promising idea is presented as a measured result. I want project writing to preserve those distinctions even when a more confident story would sound better.
This is an editorial standard I propose for my work as a founder and project manager. It explains how process notes and application guides should be read alongside project pages on this site.
Label the stage of the claim
A concept, prototype, implementation, live release and measured outcome are different stages. Each needs different evidence. A screenshot can demonstrate an interface exists, but it does not establish that real customers use it or that it produces a commercial result.
| Claim type | Appropriate support |
|---|---|
| Intention | A clearly labeled plan or design decision |
| Prototype behavior | A reproducible demonstration within its limits |
| Implementation | Inspectable functionality and relevant checks |
| Live availability | Verification of the published service |
| Usage | Defined observations from an appropriate source |
| Business impact | A stated method, period and limitations |
When the evidence supports only an earlier stage, the language should stay at that stage. “Designed to help” and “has improved” are not interchangeable statements.
Separate examples from project facts
Hypothetical numbers and workflows can explain a method. They should be explicitly identified as examples and should not be placed where a reader could mistake them for a customer result. The same applies to proposed measurement plans: defining a metric is not reporting its value.
For project-based articles, describe the intended problem and the method that could be used to investigate it. Do not invent user interviews, operational volumes, partnerships or revenue. Missing evidence is a boundary for the article, not an invitation to complete the narrative creatively.
Make limitations useful
A limitation should help the reader understand what they can rely on. For example, a public-page audit can describe observed HTML conditions while leaving private sales performance unknown. A prototype test can reveal task confusion without proving long-term retention.
Avoid turning every paragraph into a disclaimer. State the scope clearly, then write the practical method in enough detail to be useful. The portfolio evidence-ledger guide offers a structure for keeping claims connected to their support.
Date and update the record honestly
When the work changes, update the page with the relevant new evidence and date. Preserve a meaningful distinction between the original proposal and later observations. A future result should not make an earlier article appear to have known something that had not yet happened.
If a plan is abandoned or narrowed, explain the current status where it affects the reader. An old project page should not continue implying availability merely because it once described an ambitious direction.
Use sources for the claims they actually support
External documentation can support a platform behavior or a methodological reference. It cannot prove that a project implemented that behavior or achieved the same outcome. Place source links near the relevant claim and distinguish a documented fact from the author’s proposed application.
Similarly, a design reference can inform visual direction without becoming evidence of original client work. The reader should be able to tell what is inspiration, what is proposed and what has actually been built.
Prefer a precise unfinished story
A useful progress note can say: this is the problem, this is the current approach, this is the evidence available, and this is the next unresolved decision. It does not need an invented success ending.
The shipping-versus-learning article explains why incomplete work can still leave useful evidence. My aim is to make project writing trustworthy enough that later results add to the record rather than repair an earlier overstatement.