Method note

Documentation as Interface

Documentation is not only what remains after the work. In this practice, it is one of the interfaces people use to enter, operate, repair, refuse, or inherit a system.

A manual is a threshold. A diagram is a handle. A README is sometimes the first room a visitor enters. If the documentation is cold, vague, or hidden, the system has already made a decision about who belongs near it.

Documentation as interface means the explanation is not outside the artwork or tool. It is one of the surfaces. It shapes the body before the knob is touched, the file before it is opened, the class before the prompt begins, the machine before it is powered on. It can welcome, warn, slow down, redirect, refuse, or teach.

What documentation carries here

• Operating steps, failure recovery, and maintenance habits.
• Consent language, retention boundaries, and refusal paths.
• Teaching transfer: how a tool, scene, or lesson survives beyond one operator.
• Source trails showing where the live implementation truth actually lives.

The interface beneath the interface

Every public system has two interfaces. One is visible in the screenshot: buttons, sensors, lights, text fields, diagrams, boxes, rooms. The other is the path by which a person learns what they are allowed to do. That second interface is often documentation.

When documentation is treated as aftercare only, power gathers around the person who already knows the trick. The work becomes dependent on private memory: the one cable that has to be plugged in first, the sensor that drifts unless warmed up, the consent sentence that should be spoken before the camera turns on, the maintenance move that keeps the machine from becoming dangerous. Writing those things down redistributes access.

This is why runbooks, syllabi, mapping manifests, source trails, and refusal language belong inside the practice. They are not administrative husks. They are forms of public touch.

What good documentation feels like

• It names the first move clearly enough that someone can begin without guessing.
• It keeps risk, consent, and maintenance visible before the user is already committed.
• It tells the reader where live implementation truth lives and where the public page intentionally stops.
• It gives future stewards enough context to repair the work without turning the original maker into a permanent dependency.
• It leaves room for uncertainty without making uncertainty feel like failure.

Projects that surface the method

• machine-docs turns machine care into a public runbook and teaching object.
• live-rig treats setup and recovery as part of the scene system, not backstage residue.
• Syllabus keeps prompts, policies, and pathway structure portable across courses and workshops.
• Human-Buffer makes consent and privacy legible through workshop materials and interface logic.

Reader path

When an Atlas page says a repo is the source of truth, that is part of the interface too. The public site carries claims and proof objects. The repo carries the live build details.

Read documentation here as an ethics of continuation. The work should not become illegible the moment it leaves the hands of the person who built it. If a system asks to be shared, taught, repaired, or trusted, then the path into it must be part of the form.