Submission and Support

Use this page when the integration is working and you are ready to hand it off for review, publication, or partner support.

What a Clean Handoff Includes

Item	What to include
Device scope	exact models and firmware versions tested
Platform scope	browsers, OS targets, and any unsupported surfaces
Transport notes	Web Bluetooth, bridge, or native helper requirements
Known limitations	disconnect caveats, unsupported signals, setup edge cases
Ownership	who maintains the integration going forward

Required Documentation

A usable integration should ship with a short public-facing note set.

Doc	Why it matters
Install and setup notes	tells teams how to get started quickly
Platform caveats	prevents unsupported browser rollouts
Device support matrix	clarifies model and firmware coverage
Known limitations	sets realistic expectations
Troubleshooting notes	shortens support loops

Suggested Submission Template

## Device integration summary
- Device model(s):
- Firmware tested:
- Transport path: upstream / separate package / app-local
- Browser matrix tested:
- Platform limitations:

## Protocol summary
- Primary service UUIDs:
- Streaming characteristics:
- EEG channel map:
- Sample rate:
- Timestamp source: device / local

## Reliability notes
- Reconnect behavior:
- Known limitations:
- Open issues:

If the Integration Is Contributed Upstream

Include these items in the same change set:

adapter code
mocked tests and packet fixtures
consumer-facing docs updates
support notes for the device and firmware versions covered

If the integration changes a published package, include the release metadata your team uses for package publication.

If the Integration Stays Vendor-Owned

Keep the partner handoff simple:

Deliverable	Why it matters
package or adapter entry point	gives app teams one clear integration surface
versioned support statement	avoids confusion across firmware lines
contact path for issues	reduces dead-end support loops
changelog or release notes	makes regressions easier to track

Support Expectations

A good support model answers these questions up front:

Question	Example answer
Who fixes protocol regressions?	vendor partner owns device-specific decoder changes
Who fixes app contract regressions?	SDK maintainers own shared transport expectations
How are firmware changes tracked?	each supported firmware line is documented explicitly
How do consumers escalate issues?	one issue path and one owner per release line

The best partner docs are short, accurate, and versioned. Do not overload the handoff with internal process detail that app teams do not need.

Final Review Questions

Before release or handoff, confirm:

does the integration use the shared transport contract correctly
are the supported models and firmware lines explicit
are browser and platform caveats stated clearly
can another team reproduce setup without private context
is the maintenance owner obvious

EEG BLE Getting Started

Review the current BLE integration flow and compare it with your device path.

EEG BLE Getting Started

Compare your device path with the current BLE flow.

Overview

EEG Web SDK

EEG BLE Web SDK

Camera Web SDK

Operations

Contributors

Maintainers

Submission and Support

What a Clean Handoff Includes

Required Documentation

Suggested Submission Template

If the Integration Is Contributed Upstream

If the Integration Stays Vendor-Owned

Support Expectations

Final Review Questions

Next

EEG BLE Getting Started

EEG BLE Getting Started

​What a Clean Handoff Includes

​Required Documentation

​Suggested Submission Template

​If the Integration Is Contributed Upstream

​If the Integration Stays Vendor-Owned

​Support Expectations

​Final Review Questions

​Related Docs

​Next

EEG BLE Getting Started

EEG BLE Getting Started

What a Clean Handoff Includes

Required Documentation

Suggested Submission Template

If the Integration Is Contributed Upstream

If the Integration Stays Vendor-Owned

Support Expectations

Final Review Questions

Related Docs

Next