June 28, 2026
Introducing Nexus Scholar Core
Nexus Scholar Core is a local-first C# kernel for audit-oriented research workflows. The goal is not to make one more paper search app. The goal is to make research work reconstructable.
Historical snapshot: implementation details in this article describe the June 2026 baseline. See the dated implementation status for current claims.
Modern research workflows are full of fragile transitions. A protocol becomes a spreadsheet. A search result becomes a deduplicated list. A screening vote becomes a final decision. A PDF path becomes evidence. An AI suggestion becomes text in a report. Each step may look harmless inside an app, but together they can erase the history needed to audit the work later.
Nexus Scholar Core is being built around a stricter rule: scientific state should be represented as explicit, reproducible, evidence-preserving records. A search observation is not corpus truth. A deduplication cluster is not deletion of raw evidence. A screening suggestion is not a human decision. A bundle is not a random archive. A protocol is not an editable note.
Working principle: strict inside, simple outside, AI-assisted everywhere, human-authorized science.
What exists today
The Core already has the skeleton of a real systematic review workflow. It can model deterministic digests, approved protocols, compiled workflow plans, provenance events, review bundles, shared scholarly identity, raw search traces, imported search evidence, deduplication results, screening decisions, and a full-text acquisition contract.
That does not mean the whole product is finished. There is no live scholarly provider integration, no production database layer, no cloud backend, no full AI governance layer, and no real PDF extraction/OCR implementation yet. The current value is the contract foundation: the parts that decide what counts as evidence, what counts as authority, and what must never be silently collapsed.
Why this is different
Many tools help researchers search, screen, summarize, map, or manage papers. Nexus is aiming at a lower layer: the audit-oriented kernel underneath those workflows. It is designed to let future apps, command-line tools, desktop workspaces, and AI assistants operate over the same strict records instead of inventing their own meanings for identity, evidence, and approval.
That is why the architecture separates Core from UI. Core stays deterministic and authority-aware. UI and CLI layers can make the work understandable, but they should not become scientific authority by accident.
The product shape
The first visible product wedge is practical: import search exports, preserve raw evidence, show warnings, review duplicate candidates, require human merge decisions, preview provenance, and export an auditable bundle. That workflow is narrow enough to build, but important enough to show the project’s direction.
Longer term, Nexus can become a research cockpit: a workspace where AI explains and drafts, typed blocks expose evidence and actions, and human decisions remain explicit. The cockpit is not chat-first. It is workflow-first.
What to watch next
The next Core implementation target is a local, no-network full-text slice. That means user-supplied full-text artifacts, raw-byte digest validation, source-reference evidence, and extraction records. It explicitly excludes provider APIs, HTTP downloads, publisher scraping, paywall bypass, shadow-library sources, OCR, and real PDF extraction until those boundaries are governed.
This project will move best if the community evaluates both code and claims. The question is not only “does it work?” The harder question is “can we reconstruct what happened, who authorized it, and which evidence supports it?”