Presentation availableLab · execution not yet released

From scientific information to computational experiments

Kannabium Virtual Lab

A development direction for students, researchers, and professionals exploring artificial intelligence and its potential applications in the cannabis industry, cannabinoid research, and membrane receptor modulation.

01 · Questions and work fronts

Start with a problem, not an algorithm

The website introduces students, researchers, and professionals to scientific foundations, data, and methods that prepare them for advanced work in the Virtual Lab. Kannabium grows through applied learning and BioDev development practice, toward the gradual creation of intelligent computational solutions. The three fronts below describe proposals, not operational services.

02 · Data and models

Inspect data and compare predictive models

Potential use cases include exploring cultivation records or research measurements and testing a clearly defined prediction target. Feasibility depends on access rights, data quality, sample coverage, and an evaluation plan.

Proposed inputs
Documented datasets with provenance, license, units, missingness, and a defined target; integrate modalities only when records can be meaningfully related.
Proposed outputs
An exploratory report, a simple baseline, model comparisons, and a record of metrics, errors, uncertainty, and interpretation limits.
Proposed workflow
Separate preparation, training, and evaluation; document the split and prevent data leakage. Compare models against the baseline before considering a more complex approach.

Current state: the website offers methodological learning content. An interface for uploading datasets or executing model training has not been published.

Read the machine-learning and governance guide →

03 · Optimization

Search for alternatives under constraints

The proposed optimization front would investigate problems such as selecting experimental conditions or allocating resources. Genetic and evolutionary algorithms are candidate methods to evaluate, not a default solution or evidence of a market-ready product.

Proposed inputs
Decision variables, feasible ranges, constraints, an objective function, and a reference strategy. State when the objective uses measured values or predictions.
Proposed outputs
Candidate alternatives, constraint checks, and comparisons of performance, computational cost, and sensitivity across repeated runs.
Proposed workflow
Test simple search strategies before more complex methods. For multi-objective problems, report trade-offs rather than claim a single universally best solution.

Prediction is not optimization. A predictive model estimates an outcome; an optimizer searches for alternatives according to stated objectives. An optimum under a model is not an experimentally validated result. No optimization executor is currently available.

Review the data-governance framework →

04 · Molecular bioinformatics

Inspect structures and formulate testable hypotheses

The molecular front connects plant enzymes, cannabinoid molecules, and vertebrate membrane receptors while preserving the distinctions between these systems. Research on receptor modulation needs a defined question and evidence appropriate to the method.

Proposed inputs
Identified structures and sequences, source accessions, ligands, experimental methods, and documented preparation steps.
Proposed outputs
Curated structural annotations and comparisons; for future executable workflows, versioned scripts, parameters, and reports of uncertainty and limitations.
Proposed workflow
Separate experimental observations, docking poses, simulations, and functional evidence. Do not treat a docking score as a measured affinity or a simulation as proof of clinical benefit.

Available now: molecular viewers, the THCA PyMOL script generator, and a curated CB1R–THC computational study. These resources do not constitute a general-purpose online docking or simulation service.

05 · Availability

What can you use today?

Availability of public resources and planned computational capabilities.
ResourceCurrent stateWhat the visitor can do
Scientific learning materialsEducational resources availableConsult source records, methods, and interpretation limits in the scientific portals and the ML guide.
Molecular visualization and THCA script generatorAvailable for a defined useInspect published structures and generate a PyMOL script for the documented workflow. Generated scripts run in the external environment described on the THCA page.
CB1R–THC computational studyEducational demonstrationRead the documented case, inspect reported outputs, and recognize its exploratory scope; the page does not launch a new simulation.
Data training and evolutionary optimizationPlanned; no executor publishedReview the proposed scope and methodological prerequisites on this page.

06 · Module maturity

Development stage is part of the information

The following labels will accompany modules as evidence of development becomes available. They are not endorsements or claims that all four stages have already been reached.

Educational demonstration

Explains a method or a documented case. It may use a restricted example and is not an operational service.

Analytical prototype

Implements an experimental workflow with stated inputs, outputs, and limitations. A prototype is not yet a validated product.

Under validation

Has a documented evaluation plan and recorded tests against explicit criteria. This label requires evidence; it is not applied merely because a module is planned.

Available for a defined use

Has a published version, reproducible instructions, appropriate tests, and an explicit permitted scope. This does not imply regulatory approval or suitability for clinical or production decisions.

07 · Governance and release

What must be documented before a module is released?

  1. A specific problem, intended audience, acceptable uses, exclusions, and an owner responsible for maintenance.
  2. Data provenance, license, version, quality checks, and privacy requirements; no confidential or personal data in the public static package.
  3. A first published version of reproducible code for the module, with environment versions, parameters, random seeds where relevant, and instructions to reproduce the workflow.
  4. An evaluation plan, baseline comparisons, suitable metrics, error analysis, uncertainty, and failure conditions.
  5. An example report identifying inputs, methods, outputs, development stage, and evidence limits; dated validation records before a validation claim.

This presentation publishes neither a data-upload service nor authentication, an API, or a commercial analytical service. Those capabilities require a separate implementation and validation stage.