Epic: DDLP, the Dynamic Device Learning Protocol: opt-in probes build an unknown device's adapter profile over time

This is an epic of design work, so start by reading the parent issue #208 (DPDP) and the existing transport-layer guard and whitelists it cites, since the never-sendable rules depend on them. The payload names no source files, so do not assume any. The smallest self-contained lane is the first one, the profile schema and generic MIDI adapter. Maintainer decisions on partial profiles and anonymous sharing are settled, so check them before proposing anything.

DDLP, the Dynamic Device Learning Protocol. DPDP (#208) discovers the device, DDLP learns the ones we do not know yet, and DDCP (the adapter contract) controls them. The opt-in session on a volunteer's unit is a DDLP probe process.

Part of DPDP (#208). DPDP downloads a module for a device it knows. This epic covers a device it does not know: a volunteer opts in, ToneCommand probes the unit systematically, and what it learns becomes a device profile in the repo for everyone. Each volunteer with the same device adds to the profile, until it is a working adapter.

Goal

Plug in an unknown processor, agree to help, and leave behind more than you found. The next owner of the same model gets a profile that already knows its identity, transport and parameters, and a little more after their own session.

Rule zero holds

Opting in covers the volunteer's time and every read. It cannot make an unproven write safe: a guessed message that overwrites presets or firmware is not undone by consent. So:

• Reads and listening are unrestricted within the probe: identity queries, documented read requests, and recording what the unit sends by itself.
• A write is sent only if it was first observed. It must be a message the unit emitted itself, or one a cited public document defines. Its first send is a single in-edit-buffer change on that volunteer's unit, then read back. It is promoted to "verified" only if the unit reports the change.
• Never sendable, by construction: store, firmware, bootloader and factory-reset messages, and anything unclassified. This uses the same transport-layer guard as today's whitelists.

What a probe can learn

• Identity: USB vendor and product IDs, and the MIDI Universal Device Inquiry reply (maker, family, model, firmware).
• Transport: class-compliant USB MIDI port, serial, HTTP, or vendor-only USB (like the FM3, which has no MIDI over USB). This alone says what kind of adapter is possible.
• Self-description: MIDI-CI Discovery and Property Exchange, for units that support them. A unit that publishes its parameters can get a near-complete profile in one session. Which guitar processors support MIDI-CI is not yet surveyed.
• Observed behaviour: a guided session ("switch to the next preset", "turn the gain knob all the way down") records what the unit sends for each action. The volunteer names the controls.
• Read-back: which documented reads answer, so a later write can be proven.

Profiles, not code

A profile is data, not code: identity, transport, observed messages, named parameters, and verified writes. Each entry carries its provenance (observed, documented, verified) and how many volunteers confirmed it.

Profiles go to the repo the way shared recipes do. They are submitted through the share service and opened as a pull request against the device catalog. A schema check and a human review gate every merge; nothing is committed automatically. Serial numbers and anything personal are stripped before upload.

Lanes, in order

• Profile schema and the generic MIDI adapter: an unknown class-compliant device gets program change and CC immediately, with unverified writes reported honestly
• The DDLP probe process, read-only and opt-in: consent screen, identity, transport, documented reads, MIDI-CI discovery; a local profile written
• Guided learn session: prompted actions captured and named, merged into the profile across sessions
• Write promotion: replay an observed message once, read back, mark verified; the never-sendable classes enforced at the transport
• Contribution path: submit a profile through the share service, open a catalog pull request, schema check and human review
• Profile to adapter: DPDP loads a reviewed profile as a device module; capabilities declared from what is verified

Decisions (maintainer, 2026-10-09)

• Partial profiles are shared. A profile that knows 10 percent of a device is published and built on as more is learned.
  • Every entry keeps its provenance (observed, documented, verified) and how many volunteers confirmed it, so the next owner sees exactly how much is known.
  • Rule zero still holds for whoever downloads it. Verified writes are usable. An observed or documented write is offered for promotion on that owner's unit: a single edit-buffer change, then read back. Store, firmware and reset stay unsendable.
• Anonymous sharing is allowed.
  • A volunteer can submit through the share service with no GitHub account.
  • The pull request is opened by the service, so the schema check and human review still gate every merge.
  • Anonymous submissions are rate-limited.
  • Personal data (serial numbers, user names in preset titles if asked) is stripped before upload.
• The LLM helps where its output is checked, never where it would decide what is sent.

Where the LLM helps

• Drafting from published documents: given a unit's identity and a public MIDI implementation chart or manual, draft profile entries. Every entry cites the page it came from and is marked documented, not verified, until observation or read-back confirms it.
• Naming observed messages: after a guided session, propose names for the captured messages ("this CC moved when you turned the knob labelled GAIN"). The volunteer confirms or corrects; nothing is named without them.
• Planning the guided session: pick the prompts that would teach the most about this kind of device, given what the profile already has ("we know presets and gain; ask about the effect bypass switches next").
• Spotting structure across volunteers: when several sessions captured the same model, point out patterns (an address range that looks like one block's parameters, a checksum style) for a human or a read-back to confirm.
• Reviewing submissions: summarise what a profile pull request adds or changes and flag conflicts with existing entries, for the human reviewer.

Where it may not decide:

• whether a message is safe to send;
• whether a write is verified, which only a read-back on a real unit decides;
• precise values or ranges no document or capture supports.

It never invents a spec.