Reframe AudioUnit as an AUv3 Estate Instrument
This chapter establishes the platform and promotion boundary for a Reframe AudioUnit: iPadOS AUv3 is the native runtime, AUM is the named demonstration host, and the Fountain Coach estate publishes only the contract and evidence that actually exists.
1. The platform decision
The native Reframe AudioUnit platform is an iPadOS Audio Unit Extension using AUv3. A desktop AUv2 plug-in is not the target. The AUv3 extension is the realtime audio and MIDI runtime that can be loaded by a compatible host. AUM is the named host for the first demonstration and acceptance cohort.
The companion application or enrollment browser owns device identity, key custody, configuration, update discovery, and network operations. Those concerns must not enter the AUv3 render callback. The render path must remain bounded, realtime-safe, and independent of a live network.
2. The estate boundary
Reframe remains the authoring and governance authority. FountainStore remains the durable evidence authority. The AUv3 package owns its portable instrument contract, realtime implementation, parameters, MIDI event handling, fixtures, and release metadata. AUM is an external host witness, not a second contract authority. The public Instruments site is a sanitized catalog projection, not a plug-in marketplace and not proof that a binary is released.
AUv3
Owns realtime audio/MIDI processing and declared parameters.
AUM
Witnesses that the named candidate loads and routes in the chosen host.
FountainStore
Persists the typed lifecycle, scenario receipt, and evidence correlation.
3. MIDI2 is a contract, not a claim by proximity
The instrument must declare its MIDI2 operation, topics, lifecycle, timing, budgets, and failure modes in the MIDI backplane IDL and generated facts. AUM visibility does not establish MIDI2 interoperability. A MIDI2 peer, typed terminal event, and matching Store receipt establish that claim.
MIDI 2.0 → MIDI 1.0 translation is a separate compatibility capability. Its mapping must be explicit about groups, channels, controllers, note identity, timestamps, precision loss, unsupported messages, and backpressure. A fallback that silently downgrades MIDI2 is not an accepted bridge.
4. Promotion path
- Declared. Stable instrument identity, IDL operation, owner, version, topology, and scenario exist.
- Implemented. A native iPadOS AUv3/container target builds from the committed graph; realtime-safety and contract tests pass.
- AUM demo-tested. The same named candidate is discoverable, loadable, routable, and controllable in AUM; host evidence is captured independently.
- MIDI2 accepted. The typed scenario reaches a terminal MIDI2 result correlated with FountainStore evidence.
- Compatibility accepted. MIDI2→MIDI1 round-trip, negative, timing, and unsupported-message tests pass.
- Catalog projected. Instruments.fountain.coach states the exact evidence and retains pending claims as pending.
- Released. An owning authority promotes a reproducible signed/named build. Catalog publication and release remain separate decisions.
5. Enrollment and configuration
Device enrollment is not performed by the AUv3 render process. A browser or companion client generates and protects the device key, receives the enrollment challenge, proves possession, and obtains a typed approval receipt. The AUv3 consumes only an admitted, versioned configuration through the host/container boundary. Private keys, SecretStore values, QR scanning, HTTP, and approval UI do not enter realtime audio processing.
6. Draft DoD
This chapter draft is ready for local preview when its route, illustration, metadata, and claim boundary pass the direct-static estate checks and the native FountainStore preview. Chapter 132 is not implementation DoD. The instrument DoD begins only when the AUv3 target, AUM witness, MIDI2 lifecycle proof, and MIDI2→MIDI1 compatibility evidence exist in one named evidence cohort.