Neurotech & AI Platform Engineering

The pipeline has five layers:

• Ingestion: Mobile SDK sends EEG frames via WebSocket to API Gateway → Lambda producer → Kinesis Data Streams (1 shard per device). Raw samples at 250 Hz land in shards with sequence numbers for ordering.
• Processing: Lambda consumer (triggered by Kinesis) buffers 250ms epochs → applies notch filter (60 Hz) → Butterworth bandpass per band → FFT → band power extraction. Artifact thresholds reject bad epochs before persisting.
• Storage: Raw EEG → S3 (SSE-KMS); processed features + session metadata → DynamoDB (KMS-encrypted); patient identity stored separately with table-level encryption and IAM scope.
• Inference: Feature vectors sent to SageMaker real-time endpoint running ONNX model → brain state returned in <50ms.
• Compliance: CloudTrail logs every API call. VPC with private subnets. All services BAA-covered. CDK Aspects enforce encryption checks on deploy.

The separation of raw PHI (S3) from computed features (DynamoDB) is intentional — different retention periods and access patterns.

I implement Butterworth IIR filters — maximally flat passband, no ripple, standard for EEG. The approach: design filter coefficients using bilinear transform of the analog prototype, then apply as Direct Form II Transposed biquad sections for numerical stability.

• For each of the 7 bands (Delta through Gamma), I create a separate 4th-order bandpass filter at 250 Hz sample rate
• Coefficients are pre-computed at startup (not per-epoch) — they're fixed for a given sample rate
• I use Math.NET Numerics for filter design utilities, or implement the bilinear transform manually for .NET Lambda where NuGet packages must be minimal
• For real-time application: maintain filter state (zi) between epochs — do not reset per epoch or you'll get ringing artifacts at boundaries
• Notch filter at 60 Hz is always applied first, before bandpass, to avoid Beta band contamination

Butterworth is preferred over Chebyshev for EEG because the flat passband preserves amplitude relationships between frequencies — important for valid band power ratios.

TBR = absolute power in Theta (4–8 Hz) ÷ absolute power in Beta (15–30 Hz), measured at Cz.

It's the most clinically validated EEG biomarker for ADHD. The logic: ADHD brains show excess slow-wave (Theta) activity and insufficient fast-wave (Beta) activity at the central midline, resulting in a TBR typically >2.5 (normative adult range: ~1.5–2.0). The brain is in a low-arousal, daydreaming state instead of focused alertness.

Computation pipeline:

• Take a 1-second EEG epoch at Cz (250 samples at 250 Hz)
• Apply notch filter (60 Hz) → apply Butterworth bandpass for Theta (4–8 Hz) → compute RMS or sum of squared FFT magnitudes → Theta power
• Same for Beta (15–30 Hz) → Beta power
• TBR = ThetaPower / BetaPower

Neurofeedback protocol: Reward when Theta drops below threshold AND Beta rises above threshold simultaneously (two-channel threshold). Typical session: 30 minutes, 3×/week, 40+ sessions for clinical effect.

Important caveat: TBR is a screening biomarker, not diagnostic. Should be compared against QEEG normative databases (NeuroGuide, HBImed) for clinical validity.

Step 1 — Container: Package the ONNX model in a custom SageMaker inference container (Docker) or use the pre-built SageMaker ONNX Runtime container. The inference script: deserialize JSON input (feature vector array) → run InferenceSession.Run() → serialize output (class probabilities or brain state label).

Step 2 — Model artifact: Upload the .onnx file to S3 in the expected directory structure (model.tar.gz with model/model.onnx).

Step 3 — Endpoint deployment via CDK (C#):
new CfnModel → new CfnEndpointConfig (instance type: ml.m5.large sufficient for lightweight EEG classifiers) → new CfnEndpoint. Auto-scaling policy based on InvocationsPerInstance.

Step 4 — Lambda invocation: Lambda calls AmazonSageMakerRuntimeClient.InvokeEndpointAsync() with serialized feature vector. Target latency P99 <50ms — achievable with ml.m5.large for models under ~10MB.

HIPAA consideration: SageMaker is BAA-covered — use VPC mode for the endpoint so inference data never traverses the public internet.

Connection management: On $connect, Lambda stores connectionId + userId + sessionId in DynamoDB. On $disconnect, Lambda removes the record and flags session as ended.

Data flow (per 250ms EEG epoch):

• Device → Mobile app → POST /sessions/{id}/eeg → API Gateway HTTP → Kinesis producer Lambda
• Kinesis consumer Lambda (triggered per shard): filter → FFT → feature extraction → InvokeEndpoint (SageMaker)
• Brain state result → feedback Lambda → look up connectionId from DynamoDB → PostToConnection() via API Gateway Management API

Latency breakdown (achieving <100ms): Kinesis trigger ~5ms | Lambda cold start mitigated via provisioned concurrency | SageMaker inference ~30ms | DynamoDB lookup ~2ms | PostToConnection ~5ms. Total: ~50ms warm path.

Cold start mitigation: Provisioned concurrency on the feedback Lambda (it's on the critical path). Consumer Lambda can tolerate slightly higher latency.

Reconnection handling: Mobile app stores sessionId locally. On reconnect, new connectionId is written to DynamoDB — the feedback pipeline automatically uses the new connection. Session state (thresholds, protocol) loaded from DynamoDB.

The science: The prefrontal cortex shows hemispheric specialization for emotional motivation. Left prefrontal (F3) activity is associated with approach motivation and positive affect. Right prefrontal (F4) with withdrawal and threat vigilance. Alpha is inversely related to cortical activation — high Alpha = low activation.

In depression, the pattern is: high Alpha at F3 (left hypoactivation) and often low Alpha at F4 (right hyperactivation). The asymmetry index = ln(α-F4) - ln(α-F3). Positive values indicate left hypoactivation. Goal: shift index toward negative (left brain more active).

Protocol implementation:

• Compute 2-second epochs of absolute Alpha power (8–12 Hz) simultaneously at F3 and F4 using linked-ears reference (A1+A2)
• Reward criterion: Alpha_F3 < F3_threshold AND Alpha_F4 > F4_threshold simultaneously
• Thresholds set at patient's own rolling baseline (±1 SD) updated every 10 minutes
• Feedback: visual/audio reward signal sent via WebSocket when criterion met in ≥70% of the last 2 seconds

Artifact note: F3/F4 are frontal sites — highly susceptible to eye blink (EOG) artifacts that inflate Alpha estimates. ICA or strict blink rejection (>80 μV) is mandatory for valid asymmetry training.

The architecture: After each session (or batch of sessions), a Lambda function constructs a structured prompt containing the session's biomarkers and sends it to Bedrock (e.g., Claude Sonnet via the Bedrock Converse API).

Prompt structure includes:

• Current session metrics: TBR at Cz (2.8 vs norm 1.8), Alpha peak frequency (9.2 Hz), F3/F4 asymmetry index (+0.4), coherence deviations from NeuroGuide norms
• Session history: 12 sessions, TBR trend (improving: 3.2 → 2.8), subjective reports
• Treatment goals: attention/focus (ADHD protocol)
• Current protocol: Beta Up-Training / Theta Down-Training at Cz

Output parsing: Instruct Bedrock to return structured JSON: { "protocol_adjustment": "...", "new_thresholds": {...}, "add_sites": ["Fz"], "rationale": "..." }. Parse with System.Text.Json in Lambda.

HIPAA note: Bedrock supports AWS BAA. However, to minimize PHI exposure, send only aggregated numerical metrics (not patient name/DOB) and use patient alias IDs in prompts. Enable Bedrock model invocation logging only to HIPAA-compliant CloudWatch with appropriate retention.

How ICA works: Independent Component Analysis assumes the observed EEG signals are linear mixtures of statistically independent sources (neurons, eye muscles, heart, power line). ICA finds the unmixing matrix W such that S = W × X, where sources S are maximally non-Gaussian (independent). Sources corresponding to artifacts have characteristic signatures: eye blinks → large amplitude, frontal topography, slow time course; EMG → high-frequency, spatially localized near electrodes.

Offline (QEEG) workflow: Run ICA on an entire recording → manually or automatically classify artifact components → zero out artifact component activation → project back to sensor space: clean_EEG = A × mask × W × raw_EEG.

Real-time limitations:

• ICA requires large samples to converge (typically 20× channels × samples). For 4-channel BrainBit: ~80+ samples. This creates a buffering delay before ICA is valid.
• Standard approach: pre-compute ICA weights offline on baseline calibration data → apply fixed unmixing matrix in real-time. The unmixing matrix is learned once per session during a 2-minute eyes-open/closed calibration.
• Alternative for real-time with fewer channels: simpler methods work better — amplitude thresholding (reject epochs >100 μV), variance-based rejection, or regression against a dedicated EOG reference channel.

For a 4-channel device (BrainBit: O1, O2, T3, T4), full ICA with automated component classification is challenging — only 4 components. Simpler epoch rejection thresholds are more robust at this channel count.

Stack separation pattern — one stack per domain:

• ComplianceStack: KMS CMKs, CloudTrail trail, AWS Config rules, VPC, security groups, IAM roles. Everything else depends on this stack.
• IngestionStack: Kinesis Data Stream, API Gateway WebSocket, producer Lambda, DLQ (SQS). Imports KMS key ARN from ComplianceStack.
• ProcessingStack: Consumer Lambda, SageMaker endpoint, DynamoDB tables (PHI encrypted with CMK). Imports Kinesis stream ARN.
• FeedbackStack: Feedback Lambda, API Gateway Management API permissions, connection DynamoDB table.
• StorageStack: S3 bucket (SSE-KMS, versioning, lifecycle), DynamoDB tables (session history, patient records — separate tables with separate CMKs).

CDK Aspects for compliance enforcement:
Implement IAspect that visits every S3 bucket → throws if encryption is not SSE-KMS. Same for DynamoDB → throws if encryption is not AWS_OWNED_KMS or CUSTOMER_MANAGED. This runs on App.Synth() and blocks deployment if any resource violates policy. Compliance is enforced by the compiler, not by documentation.

Environments: CDK context variables per environment (dev, staging, prod). Prod uses separate AWS account (account-per-environment pattern recommended for HIPAA). GitHub Actions deploys to dev on every PR merge, staging on release branch, prod on manual approval gate.

Building from zero to production involves three categories of hard decisions: architecture bets, scope control, and team coordination.

The hardest architecture decision is always synchronous vs. asynchronous at the core data path. On a real-time AI platform (at Blitz), we chose event-driven Kinesis → Lambda over REST endpoints for the inference path. The payoff: horizontal scalability with zero application code changes as throughput grew 10×. The cost: increased operational complexity debugging the event chain. Worth it.

Scope control: the 0→1 phase always surfaces feature requests that feel critical but aren't. My filter: "Does this block the first 10 users from getting value?" If no, it waits. HIPAA compliance was non-negotiable from day one — not because we had users who needed it yet, but because retrofitting encryption and audit logging onto an existing data model is a rewrite, not a feature.

The specific lesson from the AI platform: the hardest thing isn't the code, it's agreeing on what "done" means for a real-time ML system. Inference latency benchmarks, model accuracy thresholds, artifact rejection rates — these need to be defined and agreed before the first sprint, not discovered at launch.