SlowSystems

Evidence before compatibility claims

Proof Pipeline Readiness

A reviewer-readable proof page for non-medical cognitive-state SDK prototype work. It separates available architecture, draft schemas, pending live-device evidence, simulated fixture artifacts, and vendor-approval boundaries before any public compatibility claim.

Current proof status

Architecture, schema, manifest, and one simulated fixture run are available. A live device artifact is still pending.

No device-specific compatibility, endorsement, vendor partnership, or commercial deployment claim is implied by this proof page.

Available
Static reviewer-readable website content, review manifest, non-medical boundary, data-handling assumptions, signal pipeline architecture, and one clearly simulated fixture sample run.
Draft
Derived cognitive-state event schema for a future non-medical app/API output layer.
Pending
Public live-device runtime artifact, demo video, real device run log, screenshot, or open-platform prototype evidence.
Approval path
Muse / InteraXon use, including Muse S Athena and fNIRS stream clarification, plus Neurosity, EMOTIV, OpenBCI, and BrainFlow use remain subject to their respective rules, APIs, SDK paths, licenses, or clarification requirements.

Reviewer pipeline diagram

Input fixture / approved stream → Signal quality + feature extraction → cognitive_state_update event.

This diagram is intentionally narrow: it describes the reviewable proof boundary and does not imply live device access, vendor approval, clinical validation, or manufacturer compatibility.

SlowSystems Neuro reviewer pipeline diagram A three-stage flow from input fixture or approved stream, to signal quality and feature extraction, to cognitive state update output event. PROOF BOUNDARY Schema + fixture are reviewable. Live device artifact remains pending. INPUT Fixture or approved stream No vendor-specific source claimed FEATURE EXTRACTION Signal quality + derived features Relative band-power example OUTPUT EVENT cognitive_state _update Non-medical app/API event Status: architecture available · draft schema available · simulated fixture available · live device artifact pending

The diagram is backed by static review artifacts: sample-run-001.json, cognitive-state-update.schema.json, and review-manifest.json.

Reviewable prototype artifact

A technical review bundle structure, not a device-compatibility claim.

The artifact model follows a simple reviewer journey: verify the pipeline boundary, inspect the derived event schema, check what is available, and identify which proof items still require live-device evidence or vendor approval.

Artifact
Status
Reviewer meaning
Available
Machine-readable index of proof artifacts, requested reviewer actions, and pending runtime evidence.
Static proof page and SDK brief
Available
Readable without JavaScript and suitable for internal link preview or first-pass review.
Input → Feature Extraction → Output Event architecture
Available
Shows intended processing boundaries before any vendor-specific runtime claim.
Available
Static JSON fixture for schema and reproducibility review only; not a live-device artifact.
Draft
Draft API/event contract for a future non-medical app-layer output.
Live device run log / screenshot / demo video
Pending
Needed before public runtime proof or device-specific compatibility language.
Vendor-specific SDK stream access
Requires vendor approval
Any manufacturer-specific stream, brand, logo, compatibility, or commercial use depends on the relevant vendor path.

Pipeline artifact detail

The same proof boundary in implementation terms.

The diagram above is the reviewer-facing view. These cards describe the same boundary as implementation checkpoints.

Input

Fixture or approved stream

Simulator fixture, approved development source, or future device SDK stream. Vendor-specific sources are not claimed unless separately approved.

Feature extraction

Signal quality and derived features

Signal usability checks, preprocessing boundary, relative band-power features, session context, and artifact flags.

Output event

cognitive_state_update

Minimized non-medical app/API event for focus-oriented product review, not diagnosis, treatment, or clinical assessment.

Reproducibility notes

What the sample run represents and what it does not represent.

These notes prevent the fixture artifact from being mistaken for live device proof.

Input source

Simulated fixture only

The current sample run uses a named simulator fixture and does not include raw EEG. It does not represent BLE, Muse SDK / Muse S Athena, Neurosity, EMOTIV Cortex, OpenBCI hardware, BrainFlow runtime, or fNIRS access.

Sampling window

4,000 ms review window

The fixture uses a 4-second window with relative band-power feature values. The numbers are stable example values for schema review, not measured performance.

Environment

Static web artifact

The artifact is served as static JSON at /proof/sample-run-001.json. It is intended for link preview, reviewer inspection, and future comparison against real run logs.

Known limitations

Not runtime evidence

No live device stream, no vendor-specific source, no clinical validation, no compatibility claim, no endorsement, and no medical interpretation are represented by this sample.

Vendor approval matrix

Targets are handled as approval paths, not compatibility claims.

This matrix is designed to make reviewer intent explicit and avoid public claims before written approval, licensing, or a demonstrated open-platform runtime artifact.

Ecosystem
Current public claim
Intended review use
Needed from vendor / reviewer
Muse / InteraXon
No compatibility claim
Commercial SDK evaluation, Muse S Athena stream questions, and fNIRS availability clarification
Allowed streams, brand wording, screenshots, demo rules, beta and production approval path
Neurosity Crown
No compatibility claim
Prototype target discussion and app-layer event review
SDK terms, permitted derived metrics, storage expectations, and public wording constraints
EMOTIV
No compatibility claim
Cortex access evaluation and derived-event discussion
Access tier, permitted feature display, screenshots, and commercial usage requirements
OpenBCI
No endorsement claim
Open-platform runtime proof candidate
Hardware/runtime artifact later; no brand endorsement wording without permission
BrainFlow
No compatibility claim
Adapter architecture and board-runtime discussion
Supported board confirmation, runtime environment notes, and allowed public wording

Data handling boundary

Raw streams, derived features, AI summaries, and stored records are separated.

The current public artifacts describe the intended boundary. Product-specific privacy and security documentation must be completed before any production device integration.

01

Device / simulator

Approved SDK stream, open-platform runtime, or simulator fixture.

02

Local adapter

Stream validation, quality gates, and preprocessing boundary.

03

Derived features

Minimized feature values; raw EEG is not sent to third-party AI APIs by default.

04

Output event

Non-medical cognitive_state_update event for app/API review.

05

Storage / AI

Requires consent, deletion/export policy, and partner-specific requirements before production.

JSON event card

Draft cognitive_state_update event.

This sample is a non-medical derived-event format for technical review. It is not a Muse / InteraXon, Neurosity, EMOTIV, OpenBCI, BrainFlow, fNIRS, or runtime-access claim.

Draft schema example

{
  "event_type": "cognitive_state_update",
  "schema_version": "0.1-draft",
  "runtime_status": "simulated_fixture_only_live_device_artifact_pending",
  "input": {
    "source_type": "simulator_fixture",
    "vendor_specific_source": false,
    "sampling_window_ms": 4000
  },
  "signal_quality": {
    "status": "usable",
    "artifact_flags": []
  },
  "features": {
    "alpha_relative": 0.31,
    "theta_relative": 0.18,
    "beta_relative": 0.22
  },
  "output": {
    "state_label": "focused_calm",
    "confidence_mode": "prototype_only",
    "claim_boundary": "non_medical"
  }
}

Runtime boundary

Available now: architecture, schema, manifest, and simulated fixture. Pending: live device artifact.

  • The public page documents architecture, artifact status, draft event schema, review manifest, and a simulated JSON fixture.
  • No public live-device runtime proof is claimed yet.
  • No vendor-specific SDK stream access, brand use, or compatibility statement is claimed without the relevant approval path.
  • A future runtime artifact should include source, feature extraction output, event payload, timestamped run context, and reproducibility notes.

Non-medical boundary

What this page intentionally excludes.

  • No medical-device positioning or clinical accuracy claim.
  • No diagnosis, treatment, therapy, or guaranteed health outcome.
  • No sleep-learning, hypnosis, or subliminal intervention claim.
  • No official Muse, Neurosity, EMOTIV, OpenBCI, or BrainFlow partnership, endorsement, approval, or compatibility claim.
  • No raw EEG stream sent to third-party AI APIs by default.

Proof targets

Targets are grouped by proof status, not mixed into one compatibility claim.

Self-serve prototype track

Build proof first

Used for early proof where development can start without a commercial manufacturer approval path.

  • Open-platform or simulator fixture
  • OpenBCI-style development path
  • BrainFlow-compatible architecture review

Commercial evaluation track

Approval before claims

Handled as licensing or partner-review conversations, not as existing public compatibility claims.

  • Muse SDK / MuseHub Commercial discussion
  • EMOTIV Cortex / Premium access discussion
  • Release or beta pre-approval where required

Muse clarification track

Athena stream questions

Treated as official Muse / InteraXon clarification questions before any Muse S Athena or fNIRS-related product statement.

  • Muse S Athena
  • fNIRS stream availability
  • Commercial SDK scope and permitted use

Reviewer questions

Questions for SDK and device partners.

  1. Which streams are available under the commercial SDK path?
  2. May derived non-medical cognitive-state events be displayed to users?
  3. What wording is allowed for compatibility, integration, or “works with” language?
  4. Are screenshots, sample logs, or demo videos allowed before approval?
  5. Which privacy, security, and data-processing documents are required?

Reviewer contact path

Request or provide technical review guidance.

Use the contact form for SDK review package requests, stream availability clarification, brand/claim review, technical partnership review, or NDA-led follow-up. Include your ecosystem, review role, required artifacts, and whether screenshots or demo material need pre-approval.