A project is not preserved merely because an image of it still exists. It is not preserved just because its code may be sitting on an old drive either. For work to remain verifiable, four layers need to survive together: source, executable, evidence, and context.
That distinction became concrete while revisiting older portfolio projects. The government website that hosted the Bolsa Formação WebGL modules no longer exposes the link. The current archive preserves frames and a reel, but it does not yet include the Settings screen that demonstrated important accessibility features, nor does it confirm the recovery of the repository and a runnable build. The work existed; part of its proof is no longer immediately accessible.
The same pattern appears differently in Radgear, whose current documentation preserves the prototype while explicitly identifying the final build as missing, and in After the 7 Day, which still has a public trace on LinkedIn but needs its repository, build, and media to be located and cataloged. Those records are clues, not substitutes for the artifact.
Resonance provides a counterexample. Its Global Game Jam page preserves the first build, source files, team, and original premise. The current case also documents how that prototype evolved into a released campaign. Even this situation does not remove the risk of relying on an external service, but it shows how much a historical baseline improves future reconstruction.
A public link distributes; it does not archive
WebGL makes this problem especially visible. A game can depend on its host domain, browser security policies, a remote API, certificates, headers, and a service the team does not control. When the website disappears, its URL no longer proves that the product worked.
Posts, event pages, stores, and institutional portals remain valuable external evidence. They record dates, context, and reception. None of them should be the only recovery point. Public distribution and technical preservation perform different jobs.
The same is true of Git. A repository without a stable commit, engine version, dependencies, and execution instructions may preserve text without preserving behavior. A local folder full of untracked changes is not a recoverable delivery either. The history needs to reach an identifiable state.
The four minimum layers
1. Reproducible source
The repository should contain the authorized source, dependency manifests, engine version, required configuration, and short build instructions. The preserved state must be committed and identified by a tag, release, or hash. Secrets and private material remain outside Git, accompanied by a safe description of what must be reconfigured.
2. A known executable
Every meaningful milestone needs at least one build that was actually launched and verified: a desktop binary, mobile package, or complete WebGL export. The build should record platform, version, date, source commit, and checksum. “It compiled at the time” is not as recoverable as a known artifact.
3. Navigable evidence
Isolated screenshots rarely explain a system. Features such as high contrast, focus navigation, larger type, or narration need captures of the initial state, the setting, and its applied effect. Important flows need a short video, frame sequence, or replay script. Evidence should demonstrate behavior without relying on the implementer’s memory.
4. Context and provenance
A manifest connects project, version, commit, build, media, authorship, authorization, and external links. It also distinguishes what is preserved, what is merely documented, and what still needs recovery. Without that layer, files survive but lose meaning.
The recovery queue is documentation too
The current state can be described without hiding its gaps:
| Project | Available evidence | Recovery pending |
|---|---|---|
| Bolsa Formação | Frames and reel from the two WebGL modules | Repository, runnable build, and Settings screen showing accessibility modes |
| Radgear | Prototype frames and later visual direction | Missing final build and its corresponding source state |
| After the 7 Day | External record identified on LinkedIn | Repository, executable, and local evidence package |
| Resonance — Global Game Jam | Jam page with initial build, source, team, and concept; case documenting its later evolution | Locally mirror authorized artifacts to reduce dependency on the external service |
This table does not diminish the work. It prevents memory from being promoted to proof and turns future searches into bounded tasks.
“Done” needs to include preservation
For future projects, technical closure should not end at deployment. A delivery enters the archive only when:
- the relevant state is committed and identifiable;
- a runnable build is associated with that commit;
- primary flows have legible evidence;
- dependencies, platform, and execution instructions are recorded;
- authorship, authorization, and sensitive material are classified;
- external links are cataloged as references, not as the only copy;
- recovery has been tested away from the machine where the project was created.
The lesson is not to keep everything indiscriminately. It is to preserve a small, sufficient set that can answer, years later: what was it, what did it do, how did it run, which version shipped, and what evidence supports that claim?
When those answers depend only on memory, the debt already exists. Cataloging source, executables, and evidence at delivery time is inexpensive; reconstructing the same context after repositories, machines, and websites disappear costs far more — and is sometimes impossible.
