Method note

Evidence Before Polish

A project becomes publicly legible through proof objects before it becomes polished. A routing diagram, latency capture, audio comparison, redacted screenshot, or maintenance photo can do more honest work than a finished-looking page with unsupported claims.

Polish is seductive because it makes the thing look settled. It gives the work a skin before the bones have learned how to carry weight. In this practice, the earlier evidence is often more revealing: a bench capture with awkward framing, a diagram that still shows its seams, a failed threshold test, a note that says the room was not ready yet. Those artifacts keep the work close to its conditions.

Evidence before polish does not mean anti-beauty. It means beauty should arrive with memory intact. The finished image should not erase the setup, the measurement, the refusal, the breakage, or the person who had to make the thing work twice.

What this changes on the site

Atlas pages use controlled status language and name the next proof object when evidence is still incomplete. That is not an apology. It is part of the method.

A node can be public before it is complete if it is honest about what kind of publicness it has earned. Prototype, study, public-safe excerpt, and needs proof are not weaker words. They are pressure gauges. They keep the project from borrowing authority from the interface.

This also changes the rhythm of the portfolio. Instead of waiting for every page to become a perfect case study, the site can show live work as live work: partial, tested, constrained, and still accountable. The visitor is not asked to believe in a finished object. They are invited to inspect a trail.

What counts as evidence

  • A short capture showing the behavior named in the claim.
  • A diagram that exposes routing, retention, latency, failure, or maintenance logic.
  • A repo, manifest, or schema when implementation details are the real proof.
  • A redacted screenshot when the live system involves students, participants, rooms, or private infrastructure.
  • A plain next-proof statement when the needed artifact does not exist yet.

What this protects

It protects the work from premature monumentality. It protects viewers from being asked to trust an atmosphere. It protects future collaborators from inheriting a myth instead of a setup. It also protects the maker from polishing around the unresolved parts until the unresolved parts disappear from language.

In older photographic terms, this is the contact sheet before the exhibition print. In sound terms, it is the dry signal before the chain. In teaching terms, it is the working note that lets someone else repeat the move. The unglamorous trace is not outside the work. It is where the work first becomes answerable.

Projects that make this visible

  • MOARkNOBS-42 keeps latency, mode feedback, and mapping evidence in view before enclosure polish.
  • frZone needs a short capture showing threshold state and MIDI or OSC output at the same time.
  • Horizon becomes legible through a before/after audio render before broader DSP claims.
  • live-rig needs a redacted routing diagram before any full-system confidence language.

Public reading rule

If the proof is partial, the page should say so directly. If the repo contains deeper implementation truth, the page should link there and narrow the public claim.

The site should never make absence look like certainty. A missing proof object can be named with dignity. The mark of rigor is not that every claim is complete; it is that every claim knows what would complete it.

Harvested from

These Atlas nodes cite this method directly in their public framing. The notes below are pulled from node front matter, so the method page stays tied to live project claims.