Reference material for the BioNexus platform.

The workbench is organized around managed forensic recordsets.

Workbench is not a public catalogue page. It is the internal working layer used to assemble, inspect, and analyze barcode records inside projects and datasets. The same interface exposes counts, completeness signals, media, maps, downloads, analytical submission, and operational administration.

The practical effect is that users do not need to move between separate systems for review, submission, and retrieval. A working selection remains attached to the active recordset while the user moves through downstream tasks.

Access is attached to recordsets rather than to a single global permission level.

The application distinguishes between project access and dataset access. Each recordset carries its own ACL, and those ACLs determine who can read, edit, manage, or administer material in that scope.

Records are structured around the Biodiversity Community Data Model.

The Biodiversity Community Data Model (BCDM) is the native schema of the platform. It is not a generic laboratory schema adapted for biodiversity data — it was designed by and for the biodiversity genomics community. The schema covers 111 defined fields organized into seven groups.

Fields are typed: string, string:date, integer, float, geopoint (validated lat/lon pair), array, and json. Controlled vocabularies are applied at ingest validation so that invalid values are caught at the boundary rather than discovered later during analysis.

The recordset page is the main working surface.

Most work begins in a project or dataset recordset. The recordset summary exposes specimen counts, sequence counts, sequence coverage, image presence, coordinate coverage, and compliance levels before a user opens individual records or launches analyses.

From the same page, users can move into taxonomic and geographic breakdowns, open records, review completeness, and start downstream tasks without reconstructing the selection each time.

Batch specimen intake is built around generated templates and an uploads queue.

The services layer exposes batch specimen upload templates and field definitions for forensic extension intake, including both standard and advanced forensic extension panels. Those templates are meant to support structured offline preparation before submission.

Uploads do not disappear into a background process without visibility. They are surfaced through an uploads queue so that submission state, review needs, and downstream processing remain explicit.

Files attached to records are processed, verified, and archived through CAOS.

The Cloud Archive Object Store (CAOS) is the platform's file management service. Files are not just stored — each upload is processed through a validation and post-processing pipeline before being committed to the archive. Every file receives a verified MD5 checksum and a processing record.

The workbench sits within a broader forensic workflow.

Background material supplied with the platform describes a wider lifecycle that begins with specimen or sample collection and continues through data capture, synchronization, registration, data integration, lab reception, lab analysis, results approval, and later utilization. Workbench is the governed interface inside that chain rather than the whole chain itself.

In that same description, the barcode record can be extended with diagnostic images, chain-of-custody images, digitized documentation or statements, and, where required, additional individualizing material. The workbench is valuable because those materials can be assembled, reviewed, and interpreted together rather than as disconnected evidence fragments.

Record inspection is supported by several linked views.

Review in Workbench is not limited to a single table. The codebase exposes map, image, alignment, trace, FASTQ, FASTA, spreadsheet, and document surfaces tied to recordsets, together with record-level specimen and genomics views.

Method configuration is generated from structured definitions.

Analytical methods are described in JSON definitions that specify titles, descriptions, field types, defaults, and grouped parameter panels. That is why Workbench can present method-specific forms while still using a shared submission pattern.

• Identification: query selected sequences against the BOLD reference library using a two-tier BLAST search and return ranked matches with taxonomy and identity scores.
• Distance summary: calculate pairwise distances and summarize divergence at taxonomic levels such as species, genus, and family.
• Barcode gap: compare within-species and nearest-neighbour distances to characterize gap structure and overlap.
• Diagnostic characters: identify informative nucleotide positions that distinguish groups without relying on a distance cutoff.
• Phylogenetic tree: reconstruct tree outputs from selected sequences using several tree-building methods and view styles.
• Sequence composition and downloads: summarize base composition and generate specimen or sequence export packages.

New analytical tools follow a shared five-stage execution pattern.

On the interface side, the method definition determines the submission form. On the execution side, the job package is passed through a common staged scaffold. That structure keeps parameter handling, queue monitoring, packaging, and result retrieval consistent across methods.

Administrative visibility remains part of the same system boundary.

Platform management pages cover users, projects, datasets, analyses, and API keys. In practice that means operational oversight, access handling, and analytical oversight are not treated as separate applications.