Use a stable folder for each exact lab release, a separate folder for each attempt and an index connecting artifacts to their context. Keep changing status such as “in progress” in the note, rather than renaming the case folder every time the session changes.
This is a proposed convention, not a universally best system or a backup. Its acceptance check is practical: can you reopen an original artifact, identify the command and target that produced it, and follow the same link after exporting the note?
Start with a small, stable parent folder
Use a plain parent such as kioptrix-labs/. Under it, assign a stable case identifier for the exact release, and put the full release name and source URL in scope.md. Do not rely on a shortened level number to distinguish original Level 1 from Level 1.1.
Keep the folder independent of your current note app. Use the same case ID in the evidence index, report and any working notes. If the identifier must change, update and test its references deliberately.
Keep status in the record, not the path
A folder such as kioptrix-original-l1/ can remain stable while scope.md records status as planned, setup blocked, active, paused or reviewed. These are example labels; choose a small vocabulary you will maintain.
Putting “rooted” or “report done” in the path can require a rename when the status changes. That may affect relative links or scripts. If you already use status-based names, do not rename everything blindly: retain a reference record, update affected links and test retrieval.
Separate attempts and record their conditions
Use a new attempt directory when you need to distinguish a later session, restored state or changed environment. Record the attempt ID, start time and time zone, target identity, relevant settings and recovery checkpoint in its session note.
A date alone may not distinguish two sessions on the same day. A short sequence such as s01 and s02 provides another identifier. It does not claim that the two sessions had identical conditions.
A minimal layout to copy
kioptrix-labs/
kioptrix-original-l1/
scope.md
status.md
attempts/
20261023-s01/
session.md
evidence-index.md
raw/
working/
report-draft/
publication-copy/
The names and date are illustrative. raw/ holds retained original output; working/ holds annotations or transformed copies; report-draft/ holds the explanation for that attempt. publication-copy/ contains only files deliberately reviewed for sharing.
If one note and a few files are enough, start smaller. Add a directory when it solves an actual retrieval problem rather than because a template contains it.
Use names that identify the artifact
One possible formula is timestamp_attempt_evidence-id_description.ext. For example:
20261023T003000Z_s01_e001_initial-service-output.txt 20261023T004500Z_s01_e002_authentication-error.png 20261023T010000Z_s01_e003_working-summary.md
The Z indicates UTC. You can instead use a consistent recorded local time with an explicit offset in the session note. Do not mix local and UTC timestamps without identifying which is which.
Use an evidence ID such as e001 for references, and a short description of the observation rather than a conclusion you have not established. “Authentication error” is more accurate than “service secure” when only that error was observed. Keep the file extension appropriate to the actual format; renaming an extension does not convert a file.
Connect screenshots to an index entry
A filename helps retrieval, but cannot supply all the missing context. Beside each useful screenshot, record the source session, target context, relevant command or action, observed result and limitation. A cropped identity output alone does not establish the entire preceding sequence.
Keep the original capture privately when needed for review. Produce a separately named sanitized copy for publication and record that relationship. Review paths, credentials, tokens, unrelated addresses and personal details before sharing.
Keep original output and interpretations distinct
Retain the original output for each meaningful check under a unique name. Record the full command, tool/version when relevant, timestamp, confirmed target and coverage. A label such as “full scan” is not proof of which ports or protocols were checked.
Write interpretations in a working note rather than silently editing the raw file. If a tool creates several related formats, keep their common output identifier and list them together in the index. Do not overwrite the earlier output when repeating a check; record what changed and why the repeat was needed.
Keep context with evidence and restrict private material
A note can contain hypotheses, questions and assistance used. An artifact can contain an observation. The index connects them: it should say what the artifact supports and what it does not establish.
Do not place credentials or other private lab details in a folder you might publish wholesale. Keep sensitive material in an appropriately restricted private location and exclude it from reviewed exports. A folder named “private” is only a label; actual access and sharing settings still matter.
Use an index and test a copied note
For one representative artifact, complete this record:
Evidence ID: Attempt and time context: Original file path: Command or action: Confirmed target context: Direct observation: Interpretation and remaining uncertainty: Assistance or source used: Working/publication derivative, if any: Related report section:
Then copy or export the note using your actual workflow. Open the attachment from the exported copy, check whether links resolve and confirm which files are included. Record failures before relying on the structure for more sessions.
This retrieval test is separate from backup. A naming convention and a nearby archive folder do not prove that you can recover files after device loss or deletion.
Repair context before renaming everything
When an old file is unclear, first identify its session, target and producing command if those can be established. Mark unknowns explicitly. Renaming a file “root proof” does not supply missing provenance.
Use a small mapping note when you change paths: old path, new path, reason and references checked. Do not rewrite an uncertain historical record as if you know more than the retained output supports.
Avoid these maintenance traps
- Changing case-folder status names without checking dependent links.
- Overwriting earlier output with a later attempt using the same basename.
- Mixing time zones without recording the offset.
- Editing raw evidence while preparing a summary.
- Copying a whole private evidence directory into a public portfolio.
- Assuming a clean filename proves a result, a complete scan or a secure backup.
A filename “clarity score” cannot establish whether a report is ready. Check whether the required context is present and the attachment can actually be retrieved.
Adapt the convention to the task
This layout is for ordinary authorized lab notes, repeated attempts and report preparation. It does not establish evidence-handling requirements for a professional engagement, formal investigation or certification exam; follow the relevant requirements for those contexts.
For a broader note structure, use the portable documentation guide. For deciding what a claim needs, use the explanation review questions.
Common naming questions
Should the folder name include the current status?
A stable path with status inside the record avoids repeated renames. If you prefer a status-based path, update and test its references when it changes.
Do I need a folder for every testing phase?
No. Use the smallest structure that preserves your context and supports retrieval. A fixed phase tree is an option, not a prerequisite.
Can I rename an old screenshot to say what I think happened?
Keep the original relationship and record uncertainty. A descriptive name should not turn a suspected outcome into a verified result.
Is an archive folder a backup?
No. It organizes files within a location; it does not by itself establish a separate recoverable copy or a tested recovery process.
Test one artifact before scaling the system
Create one stable case record, one attempt note and one evidence entry. Open the linked artifact, then test it after an export. Repair the first broken reference before adding more structure.
Review scope
Editorial revision: October 23, 2026. Replaced conflicting status-based folder guidance with stable case identifiers, added a readable attempt layout and UTC filename examples, removed arbitrary filename scores and unverified time-saving claims, and separated retrieval checks from backup. No new filesystem test was performed for this editorial example.
Evidence index entry and export check
Working aid updated: October 23, 2026. Complete one entry for a representative artifact, then repeat the pattern as needed. Keep stable evidence identifiers when files move; record the old and new paths rather than silently losing the relationship.
The field stays on this page and clears on reload. This tool does not upload your text, read local files, create folders or automatically save changes. Download or copy the entry before leaving. Do not include passwords, tokens or personal data.
Download or copy the entry to keep it.
Try the real export: open your exported note with the app you intend to use, then follow its artifact reference. If the file is missing, inaccessible or no longer matches the entry, record that result and repair the reference. A path typed into this field is not checked by the website.
Keep the limits visible: a working link is a retrieval result, not proof of the technical conclusion, a separate backup or permission to publish. Review the actual sharing settings and the contents of any publication copy separately.
Use a portable note structure · Link a decision journal · Prepare a session handoff