111 fields across specimen, taxonomy, collection, sequence, and forensic extension groups — designed for biodiversity genomics.
About
BCDM-native data model
Governed access
Integrated analysis
A platform for forensic and biodiversity genomics data management.
BioNexus is a multi-service platform for managing DNA barcode records, running bioinformatics analyses, and governing access to specimen and sequence data. It is built natively around the Biodiversity Community Data Model (BCDM) and designed to meet the audit, security, and data quality standards of forensic casework — requirements that exceed what most research or laboratory information systems provide out of the box. Workbench is the user-facing layer of that platform.
Recordset-level ACLs, MFA, API key management, and audit logging support institutional and regulatory requirements.
Identification, phylogenetics, distance analysis, compliance reporting, and more — each job follows the same execution scaffold.
From platform view to recordset view
HQ-level activity and recordset-level work remain closely connected in the interface.
Purpose
The platform handles the full lifecycle from intake to analysis.
BioNexus manages barcode records from the point of specimen intake through sequence data management, file archiving, bioinformatics analysis, and governed access by collaborators and institutional partners. The platform was built around forensic requirements — legally defensible audit trails, multi-factor authentication, record-level access control, and reference-grade data quality — which are a strict superset of what most research workflows require.
Workbench is the user-facing layer of that platform. It brings recordset review, intake, analytical submission, and administrative oversight into a single working environment so that users do not move between separate systems as they work through a case or dataset.
Access control and audit trails are built into the platform, not added on top.
The platform implements multi-factor authentication (TOTP) at login, Argon2id password hashing, session management via signed JWT cookies persisted in Redis, and automated brute-force protection. Programmatic access uses API keys with per-key quotas and expiry dates.
Access is governed at the recordset level, not globally. A user may manage one project, read another dataset, and have no access to a third — and those rights are enforced in the data layer on every retrieval, not just in the interface.
- Invitation-based onboarding: accounts require an explicit administrator-issued invitation, keeping every account traceable to an institutional relationship.
- Audit logging: three tiers — administrative actions, data events (who loaded what, when), and login history — support post-hoc investigation and reproducibility.
- Forensic extension fields: chain of custody, reference grade (Platinum–Bronze), and biobank catalog are available as first-class record fields.
Projects and datasets act as the main containers of work.
Most work begins inside a project or dataset recordset. That page exposes counts, compliance, coverage, taxonomic breakdowns, and downstream actions before the user opens records or launches analyses.
The effect is practical rather than decorative: recordsets anchor what the user is looking at and what they are allowed to do next.
Evidence review extends beyond tables.
The workbench includes map, image, alignment, trace, FASTQ, and record-level views tied to the same recordset context. That matters because analytical interpretation often depends on the ability to return to the underlying evidence quickly.
Instead of separating those views into unrelated tools, the application keeps them in the same operational frame.
Method-specific forms are paired with a shared execution scaffold.
Analytical methods are described in JSON definitions that determine the fields and grouped options shown in the interface. On the execution side, those jobs move through the same staged structure for validation, filtering, conversion, execution, and packaging.
That combination makes it possible to add method-specific tools without reinventing submission, queue handling, or result retrieval every time.
Platform Components
The platform is composed of independent services with a shared data layer.
BioNexus is a multi-service system. The workbench handles user sessions and the UI. A data API handles record CRUD, search, and caching. An analysis API manages the job queue. A file service (CAOS) handles all uploaded objects. Each service runs as a Docker container and can be updated independently. Shared infrastructure — PostgreSQL, Redis, and Azure Blob Storage — is used across services with strict isolation between environments.
Records are stored in PostgreSQL across separate databases. Redis provides multi-tier caching for record retrieval and session state.
Each analysis job type runs inside its own Docker container. The environment of every analysis run is version-controlled and recoverable.
Files are validated, checksummed, and processed through an asynchronous pipeline before being committed to Azure Blob Storage.
Documentation
Platform reference: data model, access model, analyses, file management, and administration.
Identification EngineHow the tiered BLAST identification engine works and what results it produces.
FAQShort answers to common questions about data formats, access, analyses, and authentication.
SupportOperational guidance on how issues are routed and what identifiers to include.