About NeuroMaven

The assistant is provider-neutral. Connect your own OpenAI, Anthropic or Gemini key and model from your profile, or use server-configured credentials where an operator provides them. Provider resolution is user key, then configured server key, then an explicit unavailable error. Stored credentials are never returned to the browser; the platform reports a masked hint, the connection state, the chosen model and the last validation time.

Response levels change what an answer emphasizes. Levels 1 and 2 keep educational explanations and close with a Summary. Level 3 leads with diagnosis, cause, fix and verification. Level 4 answers with commands first, followed by assumptions, reproducibility checks and failure conditions.

Answers stream over server-sent events, and the browser receives a validated answer instead of unvalidated partial text. Each record keeps source identifiers, provider and model, policy version, token usage and timing.

Every request assembles a bounded context: the project abstract and linked-paper selection, recent conversation history, scoped memory, retrieved passages from indexed research records, and results from the research tools selected for that request. Memories are durable in Supabase and semantic in pgvector, scoped to user, project and thread; clearing memory preserves chat history, and disabling project memory stops memory injection and summary updates.

One policy builder supplies identical base, style and level rules to every provider, so switching models does not silently change how the assistant is instructed. Research tool failures appear as unavailable stages and never silently become evidence.

The versioned pipeline graph is the single canonical format shared by persistence, chat artifacts, debugging, source interpretation, templates, validation, recommendations, the tool interfaces and code generation. The visual editor is an adapter over that format, not a second pipeline format.

In the editor you connect typed, directional ports; search categorized blocks; complete schema-driven parameter forms; validate; review confidence; undo and redo; pan, zoom and minimap; and work with templates, versions, comparisons, restores and forks. Unsaved drafts belong to you, and a stale draft can be downloaded or recovered independently without overwriting a newer server version.

Importing source is static. Shell and AFNI scripts, Python files, notebooks, multiple files, folders and ZIP packages are interpreted without executing any of it. The interpreter reconstructs filename dependencies across files, retains configuration and source provenance, and marks uncertain blocks and edges for you to confirm.

Code generation validates first, then produces Python code, a shell entrypoint, the graph, parameters, requirements, an environment specification, a README and provenance. Intermediate files live in a temporary directory and final outputs are copied to a persistent output directory before cleanup. Embedded graph metadata allows lossless export and import, and modified code is detected and preserved for review.

Public project pages expose read-only pipelines, parameters, the permitted code, provenance and paper or DOI metadata. Signed-in visitors can fork a published pipeline into a project they are authorized to write to.

Eight immutable v1 templates ship with the platform: AFNI basic fMRI preprocessing, AFNI resting-state pipeline, AFNI task GLM, AFNI surface analysis, ridge regression baseline, nested cross-validation, classification workflow, and a minimal reproducible analysis. Duplicating a template creates an independent project pipeline.

Seventeen reviewed tool definitions are registered today, and nine MCP tools share the same core services: get_pipeline, search_pipelines, find_similar_pipelines, validate_pipeline, get_tool_definition, search_tools, get_tool_documentation, interpret_pipeline_source and generate_pipeline_code. The registry is deliberately small at launch, and required dataset paths and analysis parameters must be supplied before an executable export.

Sign-in and account identity use Supabase, while application reads, writes and authorization run in a FastAPI backend that verifies the session before acting with service-role access. Private branches remain private to their owner even among project collaborators, and reading a branch also requires access to its ancestors. Sharing changes also restrict access to derived representations.

Provider keys are stored server-side with a persistent encryption key and are never exposed to the browser. MCP subprocesses receive neither provider keys nor the Supabase service-role key, and unscoped processes cannot reach private pipelines.

Uploaded PDFs are private to the uploader, limited to 4 MB per file and 8 MB total per user (up to 500 pages), with text extraction and paragraph-aware chunking. There is no OCR and no unrestricted remote URL fetching, and uploaded code is interpreted statically rather than executed. Deleting a source conversation cascades to the pipeline derived from it so branch privacy is preserved.

Reuse is reauthorized rather than assumed: cached response identifiers and retrieved workflow records are checked again before they are returned, and public discovery, the sitemap and public project pages cover only content that was intentionally published.

Please read this section before relying on output. AI responses, generated code and suggested graph edits can be incomplete or scientifically incorrect, so verify results, parameters, provenance and suitability independently.

The interface is a Next.js App Router application written in TypeScript, with @xyflow/react powering the Playground editor. The backend is FastAPI over a Supabase PostgreSQL database. The vector extension keeps retrieval derivatives next to the relational data, Redis caches short-lived results, and a local Ollama embedding model produces embeddings independently of the generation model. A private stdio MCP server provides the research tools, and the hosted backend can also run as a single serverless Python function.

No model training or fine-tuning is part of this application.

Create an account or sign in, connect and test a provider key from your profile, then create a project with an abstract and ask your first question. To build or import an analysis, open the project Playground, start from a template or import your scripts and configuration, review the detected stages and provenance, and validate before generating a package.