FAQ
Common questions about BioNexus.
This page collects short answers to questions that come up most often when orienting new users to the platform. It covers access, recordsets, the BCDM data model, file types, analytical methods, and administrative scope.
Questions are written as orientation notes rather than full technical reference. For deeper context on platform structure use the documentation page; for operational issues use the support page.
Platform Scope
Questions about what the platform is for.
No. It is an operational interface used to manage, review, and analyze forensic barcode records inside controlled projects and datasets.
The platform supports specimen intake and management, DNA sequence data handling, file archiving (images, traces, FASTA, PDFs), taxonomic identification, phylogenetic and distance analyses, compliance scoring, governed access control, and audit logging. Workbench is the user interface for those capabilities.
Because the recordset is the main unit of work in the application. Counts, review views, submissions, exports, and access rules are all anchored to that context.
Access And Recordsets
Questions about projects, datasets, and permissions.
Both are recordsets, but they are managed through separate administrative structures and ACL rules. In practice they behave similarly as working containers, while their governance differs.
Not necessarily. Access is recordset-specific, so a user may be able to manage one project, read another dataset, and have no access to a third recordset.
Yes. Project and dataset ACL logic resolves to named levels such as Project Manager, Dataset Manager, Edit All, Read All, or read-only variants depending on recordset type and permission values.
The platform uses recordset tokens and recordset-specific routes so maps, downloads, media views, and analyses all stay attached to the same selection.
Review And Data Handling
Questions about uploads, review surfaces, and exports.
Yes. The platform exposes template and field-definition services for batch specimen intake, including forensic extension and advanced forensic extension panels.
Recordsets can open map views, image libraries, record browsers, alignment views, trace and FASTQ review, as well as spreadsheet, FASTA, and document exports.
Yes. Uploads are represented through an uploads queue, and analysis work is shown in a separate analysis-monitoring view.
Yes. The configured methods include specimen-download and sequence-download jobs, and the services layer also exposes spreadsheet, FASTA, and document-oriented retrieval routes.
Data Model And Files
Questions about the BCDM schema, field types, and file attachments.
Records follow the Biodiversity Community Data Model (BCDM), which covers 111 defined fields across seven groups: specimen, taxonomy, collection, sequence, forensic extension, individualization extension, and computed features. The schema was designed for biodiversity genomics and is the same model used by BOLD.
Yes. A complete mapping from BCDM fields to DarwinCore is maintained in the platform. DarwinCore is the exchange standard used by GBIF, iDigBio, and most biodiversity aggregators.
Yes. Fields have defined types (string, date, integer, float, geopoint, array) and controlled vocabularies are enforced at the ingest boundary. Invalid values are rejected before records enter the platform rather than being stored and discovered later.
The platform handles images (JPG, PNG, GIF, TIFF), electropherogram traces (AB1, SCF, FSA), sequence files (FASTA, FASTQ), PDF documents, spreadsheets (XLSX), and geospatial files (SHP, GeoJSON). Files are validated, checksummed, and processed before being archived.
Analyses And Outputs
Questions about analytical submission and results.
The configured catalog includes identification, distance summary, barcode gap, diagnostic characters, phylogenetic tree reconstruction, sequence composition, and specimen or sequence download jobs.
Parameter forms are defined from per-method JSON files. Those definitions describe titles, descriptions, field types, defaults, and grouped field panels.
Jobs follow a staged scaffold that validates inputs, filters the selected records, converts them into method-specific inputs, executes the analytical program, and packages the returned outputs.
Completed jobs return report pages, summary tables, figures, downloadable packages, and runtime information, while the queue history remains available for review.
The identification engine runs sequences from the selected recordset as queries against a pre-built BLAST database of BOLD reference sequences. Two passes are made: one at 96% identity for high-confidence matches and one at a configurable lower threshold (default 80%) for wider coverage. Results are ranked by identity and annotated with taxonomy. See the identification engine page for full details.
Administration And API
Questions about oversight and service references.
Yes. The public codebase includes platform-management pages for users, projects, datasets, analyses, and API keys.
Yes. This deployment publishes interactive API documentation at /api/docs.
User accounts authenticate with passwords (hashed using Argon2id) and multi-factor authentication via TOTP — compatible with standard authenticator apps. MFA is enforced at login. Programmatic access uses API keys, which support per-key request quotas and expiry dates. Accounts are created through a controlled invitation workflow rather than open self-registration.
No. It is an orientation aid. For route-level behavior and feature details, the documentation page, API docs, and internal operating procedures remain more authoritative.