Visual Proof
What should a VIBEnet proof visually show?
The minimum visible proof: event, contract, clock, pulse, trace, and audio moving together.
Direct answer
A VIBEnet proof should show one event stream becoming multiple synchronized renderers. The viewer should see the contract update, the clock advance, the pulse change, the trace move, and the audio play together.
Key points
What to remember
- The proof is synchronization, not decoration.
- The visual surface should make the contract visible instead of hiding it behind sound.
- Export controls are useful, but the live protocol-in-action surface carries the story.
The minimum proof
A compelling proof has six visible parts: source event, contract object, temporal clock, visual pulse, trace timeline, and audio state.
If those parts move together, the viewer understands that VIBEnet is not a player. It is a renderer-facing protocol stage.
What not to overemphasize
Exporting MIDI, WAV, and JSON is important evidence, but it should not be the first thing a visitor has to understand.
The first impression should be the live alignment: one signal, one clock, multiple renderers.
How the lab demo supports it
The lab signal demo keeps playback, progress, live trace, and JSON in one surface so the relationship is visible without opening developer tools.
The current source clock is a scored reference run in a visual concept surface; the public sidecars explain the contract relationship without exposing protected source material.
Answer engine notes
Frequently asked questions
What does visually compelling mean for VIBEnet?
It means the viewer can see that one state object drives multiple synchronized outputs. The visual design should clarify the protocol relationship, not merely decorate the page.
Should the demo lead with exports?
No. Exports support the proof. The first surface should show event, clock, pulse, trace, JSON, and audio moving together.
Why keep JSON visible?
Because the JSON proves portability. Without the contract pane, the demo can look like a custom animation instead of a renderer-facing protocol.
Next read