# SOP — Field to Form: EMF, Oscillation, MIDI Geometry

**Version:** 1.0  
**Date:** 2026-07-16  
**Status:** Conceptual integration plan  
**Collection:** `field-to-form`

## Purpose

Define a staged, inspectable way to incorporate the EMF/oscillation architecture into the WAV → MIDI → Geometry pipeline. The result is a research concept in which environmental and musical signals are measured, interpreted, translated into oscillation, expressed as geometry, and returned as feedback.

The working loop is:

```text
field + sound → measurement → interpretation → oscillation target
→ MIDI / actuator / geometry → telemetry or scan → renewed interpretation
```

This document is a design plan, not a claim that EMF measurements are meaningful by default. Measurements, calibration status, interpretations, and actions must remain separate.

## Source concepts incorporated

1. The EMF architecture proposes a slow cognitive loop that emits frequency, phase, amplitude, and damping parameters, plus a fast firmware loop that executes them and returns telemetry.
2. The MIDI geometry architecture maps time to horizontal position, pitch to height, velocity to marker size or mass, duration to width, and sequence to a connecting contour.
3. The anthrocybernetic principle is that the body is a partner in the loop: drift, lag, resonance, noise, and failure are observations rather than hidden defects.

## Safety and epistemic boundaries

- Treat 7.83 Hz as a reference or design seed unless an instrument and calibration procedure establish a measurement.
- Do not present RTL-SDR, audio, heartbeat, weather, or other sensor fluctuations as intentional messages without controls and repeated observations.
- Never drive a physical actuator from an unknown or unbounded target. Apply frequency, amplitude, temperature, current, travel, and emergency-stop limits.
- Never run generic G-code on an unknown printer. Re-slice with the actual printer, material, and safety profile.
- Preserve raw inputs and timestamps. Do not overwrite source recordings or raw sensor captures.
- Keep human review between concept output and physical actuation.

## Data contract

Every cycle should preserve four distinguishable layers:

```json
{
  "measurement": {},
  "interpretation": {},
  "action": {},
  "feedback": {}
}
```

### Measurement

Raw or minimally processed observations: source, timestamp, sample rate, units, calibration, noise estimate, and capture settings.

### Interpretation

The nine-structure routing result: structure, prescription, confidence, repetition count, salience, valence, and uncertainty. A real measurement may still have an uncertain interpretation.

### Action

The bounded target: mode, omega, phase, amplitude, damping, MIDI mapping, actuator limits, and approval state.

### Feedback

What actually happened: telemetry, timing error, frequency error, physical response, scan or photograph, operator notes, and comparison with the intended geometry.

## Staged execution plan

### Segment 1 — Documentation and contract

Create the collection directory and write:

- this SOP;
- a plain-language incorporation concept;
- a fractal seed containing the architecture, mappings, boundaries, and next experiments;
- an HTML presentation of the concept.

**Exit criteria:** all files exist, source URLs are recorded, and the concept clearly distinguishes measurement from interpretation and action.

### Segment 2 — Static concept validation

Validate the JSON syntax, inspect the HTML structure, confirm that every referenced artifact is named consistently, and check that the SOP's safety boundaries appear in the public-facing material.

**Exit criteria:** JSON parses, HTML has a title and readable sections, no placeholder paths remain, and no physical execution is implied as complete.

### Segment 3 — Collection packaging and publication

Add a README that explains the collection, list the final files, and sync the directory to the `field-to-form` zo.pub collection.

**Exit criteria:** the collection is publicly reachable and the reported URL is recorded for handoff.

### Segment 4 — Future experimental implementation

Only after the concept is reviewed:

1. Select and calibrate sensors.
2. Capture a clean audio and sensor baseline.
3. Implement a slow loop that writes bounded targets.
4. Test a simulated fast loop before connecting hardware.
5. Close the loop with telemetry.
6. Render geometry with confidence and perturbation layers.
7. Re-measure the physical output and record the return signal.

**Exit criteria:** a reproducible experiment log exists, raw inputs are preserved, safety checks pass, and conclusions are limited to what the measurements support.

## Proposed signal-to-form mappings

| Input or state | Spatial or motor expression |
|---|---|
| Audio time | X position |
| Audio pitch | Z height |
| Audio velocity / amplitude | radius, thickness, or brightness |
| Note duration | width or extrusion length |
| Sequence | connecting contour |
| EMF or other perturbation | surface texture or radial displacement |
| Heartbeat phase | rotation or phase offset |
| Damping ratio | taper, curvature, or settling behavior |
| Confidence | transparency, branching, or layer separation |
| Silence or absence | gap, void, or missing column |
| Telemetry error | visible deviation between intended and actual form |

## Completion checklist

- [ ] SOP written before execution
- [ ] Concept document created
- [ ] HTML presentation created
- [ ] Fractal seed created
- [ ] Measurement/interpretation/action/feedback layers separated
- [ ] Safety and uncertainty boundaries stated
- [ ] JSON validated
- [ ] HTML checked
- [ ] README created
- [ ] Directory synced to zo.pub
- [ ] Public collection URL reported

## References

- https://wemeanyounoharm.com/emf/
- https://zo.pub/swirl2012/midi-geometry
- https://zo.pub/swirl2012/midi-geometry/WAV-to-MIDI-to-Geometry-SOP.md
- https://zo.pub/swirl2012/midi-geometry/midi-geometry-fractal-seed.json