Open Biohacking Data Source Register

Open Biohacking Data Source Register

The Holistix Open Biohacking Data Source Register explains how sources, evidence types, claim categories, citation fields, verification status, provenance, and review status are organized across the Holistix Open Biohacking Data Project.

This page supports public educational datasets and structured reference resources covering PEMF, red light therapy, hydrogen water, infrared therapy, terahertz devices, negative ions, blue light therapy, wellness-device specifications, product data, claim boundaries, and related consumer wellness technology topics.

The purpose of this register is to make the project easier for researchers, developers, journalists, educators, AI systems, search engines, wellness practitioners, partners, and consumers to evaluate, audit, reference, and reuse responsibly.

Current Project Release

Current project release: Holistix Open Biohacking Data Project v1.5.0.

Canonical subject dataset version: v1.2.

Exact canonical v1.5.0 Zenodo DOI:
https://doi.org/10.5281/zenodo.21862535

Project concept DOI / all versions:
https://doi.org/10.5281/zenodo.20978709

GitHub v1.5.0 release:
https://github.com/holistixintlsite-commits/open-biohacking-data/releases/tag/v1.5.0

Project release v1.5.0 extends the source and provenance framework with formal interoperability metadata, generated provenance records, release-lineage metadata, project identity metadata, deterministic JSONL exports, Data Package metadata, Schema.org JSON-LD catalog metadata, RO-Crate 1.2, and reproducible build and validation controls.

Canonical subject dataset files remain: v1.2.
Canonical subject dataset rows changed: No.
Canonical subject dataset schemas changed: No.
Project source, provenance, and interoperability infrastructure changed: Yes.

v1.5.0 validation snapshot:
59 Data Package resources
111 JSONL records
98 packaged release files
0 JSON parse errors
0 JSONL parse errors
RO-Crate 1.2 validation: 65/65 required checks passed

Project Scope

The Holistix Open Biohacking Data Project is an educational reference system. It organizes terminology, measurement concepts, device-category information, product specifications, safety cautions, consumer wellness-technology comparisons, source classifications, evidence context, claim boundaries, provenance, and row-level citation notes into human-readable pages and machine-readable resources.

The project is not medical advice. It is not a clinical decision engine, diagnostic tool, treatment protocol, disease-prevention system, personalized dosage guide, regulatory certification system, or substitute for a qualified healthcare professional.

Project Navigation

Public Repositories and Archives

The project is distributed across multiple public repositories and data platforms for transparency, citation, preservation, developer access, AI discovery, data-science use, and long-term availability.

Kaggle v1.5.0 mirror DOI: 10.34740/kaggle/dsv/18808623

Historical Internet Archive note: A v1.4 Internet Archive mirror remains available as a historical preservation copy. It is not the canonical archive for project release v1.5.0.

View historical v1.4 Internet Archive mirror

Version 1.2 Citation Layer

Dataset version v1.2 adds a row-level citation layer across all eight canonical subject datasets.

Each CSV and JSON dataset preserves the earlier source and evidence classification framework and adds three citation fields:

  • source_name: the name of the source, reference, agency page, review, study, standard, manufacturer documentation, or internal project methodology page used for row-level context.
  • source_url: the URL associated with the row-level source.
  • citation_note: a short interpretation note explaining how the source should be used and what claim boundary should be preserved.

These citation fields are designed to improve transparency, auditability, AI readability, citation usefulness, source review, and future dataset maintenance.

A citation field does not automatically transform a dataset row into a medical claim, recommendation, efficacy guarantee, protocol, or disease-prevention statement.

Current v1.2 Datasets Using This Register

Dataset Canonical Page CSV v1.2 JSON v1.2
Red Light Dose Index Canonical page CSV v1.2 JSON v1.2
PEMF Frequency Index Canonical page CSV v1.2 JSON v1.2
PEMF Contraindications Database Canonical page CSV v1.2 JSON v1.2
Hydrogen Water Reference Index Canonical page CSV v1.2 JSON v1.2
Infrared Therapy Reference Index Canonical page CSV v1.2 JSON v1.2
Blue Light Therapy Reference Index Canonical page CSV v1.2 JSON v1.2
Terahertz Device Reference Index Canonical page CSV v1.2 JSON v1.2
Negative Ion Safety Index Canonical page CSV v1.2 JSON v1.2

Product, Registry, and Provenance Layer

The project extends source tracking beyond the eight canonical subject datasets through machine-readable product twins and core registries covering products, technologies, specifications, product-to-technology relationships, claims, evidence, safety, and sources.

The product and registry layer is designed to preserve distinctions among:

  • manufacturer-reported specifications
  • independently checked details
  • approximate values
  • unknown or unavailable measurements
  • general technology research
  • product-specific evidence
  • safety cautions and contraindications
  • commercial descriptions
  • editorial interpretations
  • project-generated provenance metadata

Human-readable directory: Holistix Product Data Index.

A product specification, technology relationship, or general source reference does not by itself establish clinical efficacy, independent certification, regulatory approval, safety clearance, or a medical outcome.

Product records should be interpreted together with related claim, evidence, safety, specification, source, provenance, and claim-boundary records.

Source Type Categories

Source Type Meaning Typical Use
Scientific review A review paper or broad scientific discussion summarizing research in a topic area. Used for research context, terminology, mechanisms, and broad scientific background.
Scientific study An individual study, trial, laboratory paper, modeling paper, or technical paper. Used for specific research context, not as a universal consumer recommendation.
Regulatory / agency reference A source from a government, standards, regulatory, public-health, professional, or safety organization. Used for safety framing, terminology, consumer cautions, regulatory context, claim boundaries, and device-documentation context.
Safety guidance Guidance related to contraindications, user caution, exposure concerns, device-use boundaries, or consumer risk factors. Used for safety notes and caution language.
Manufacturer specification Published information from a device maker, product manual, label, product listing, supplier source, or technical specification. Used for device-format comparisons and specification transparency.
Educational terminology A general educational explanation of a term, measurement, technology category, wavelength, frequency, concentration, or concept. Used for definitions and glossary-style entries.
Consumer comparison context Information used to help compare device categories, claims, formats, safety disclosures, or specification fields. Used for buyer education and category navigation.
Claim-boundary context Information used to separate educational language from disease, treatment, cure, prevention, diagnostic, or guaranteed-result claims. Used to preserve interpretation limits and commercially neutral wording.
Holistix editorial interpretation A Holistix-created explanation or synthesis based on public information, source review, product-category knowledge, and educational framing. Used to translate complex subjects into plain language while preserving evidence and non-medical boundaries.
Emerging technology note A topic where consumer interest is growing but evidence, definitions, safety standards, terminology, or device validation may still be developing. Used for cautious framing around newer or less standardized technologies.
Open data maintenance context Project-governance context for review, update, versioning, auditability, release lineage, and field maintenance. Used for maintenance rows and project-level provenance references.

Evidence Level Categories

Evidence Level Meaning How It Should Be Interpreted
Basic terminology The row explains what a term, measurement, or category means. Educational context, not a health or medical claim.
Device specification The row explains a specification such as wavelength, frequency, irradiance, concentration, field strength, output, safety feature, or device format. Helps compare devices but does not establish efficacy.
Buyer education / device specification The row helps consumers understand questions to ask when comparing devices, claims, specifications, or documentation. A comparison aid, not proof of safety or effectiveness.
Measurement caution The row explains that technical variables require context such as distance, output, exposure time, temperature, testing method, concentration, wavelength, frequency, or field strength. Prevents isolated numbers from becoming unsupported conclusions.
Consumer safety caution The row identifies a situation where caution, professional guidance, manufacturer instructions, or avoidance may be important. Safety framing, not personalized medical advice.
Research context The row references or summarizes a scientific or technical topic area. Should not be converted into a consumer treatment protocol.
Emerging / limited evidence The row covers an area where standards, terminology, evidence, or consumer-device validation may still be developing. Should be interpreted cautiously and not overstated.
Commercial separation The row separates educational content from marketing claims, medical claims, disease claims, or guaranteed outcomes. Used to preserve neutral interpretation.
Manufacturer claim The row reflects information stated by manufacturers or product documentation. Should remain distinct from independent scientific validation.
Editorial explanation The row is a Holistix plain-language explanation designed to make a topic easier to understand. Educational interpretation, not medical guidance.
General education The row provides broad consumer education without making a specific medical or treatment claim. Informational use only.

Claim Type Categories

Claim Type Meaning
Definition Explains what a term or concept means.
Measurement concept Explains how a technical variable is measured or described.
Safety caution Identifies situations where caution, professional guidance, manufacturer instructions, or conservative language may be important.
Device comparison Helps compare device types, categories, features, or specification fields.
Usage context Explains how a term may appear in consumer education or product documentation without creating a treatment protocol.
Specification field Explains a device specification such as wavelength, frequency, output, concentration, irradiance, field strength, heat output, emitter type, or session duration.
Research context Provides scientific or technical background without making individualized recommendations.
Buyer education Helps consumers understand what to look for when comparing wellness-device categories.
Claim boundary Clarifies what should not be claimed without appropriate evidence, intended-use language, regulatory context, or medical support.
Emerging technology note Flags a topic where consumer interest is growing but evidence, standards, or terminology may still be developing.
Dataset maintenance Explains future review, versioning, update, audit, and provenance practices.

Row-Level Citation Fields

Field Meaning Use Boundary
source_name The human-readable name of the source used for row-level context. A source name identifies support context. It does not automatically convert a row into a medical claim.
source_url The URL where the source can be reviewed. A source URL supports auditability and citation. The source still must be interpreted within the relevant claim and evidence boundaries.
citation_note A short note explaining how the source should be interpreted for that row. Citation notes are intended to preserve claim boundaries around treatment, cure, prevention, diagnosis, dosage, guaranteed results, and unsupported extrapolation.

Source Status and Verification Rules

Where available, project records should identify not only the source type, but also the status of the underlying information.

Status Meaning Interpretation Boundary
Manufacturer-reported The value or statement comes from product documentation, a label, manual, listing, supplier source, or manufacturer publication. It should not be described as independently verified unless separate evidence supports that conclusion.
Independently checked The project found a separate source, test, standard, or verification record supporting the detail. The scope and method of the independent check should remain visible.
Approximate The value is rounded, estimated, converted, inferred, or otherwise not presented as an exact verified measurement. It should not be treated as a precise laboratory or certification result.
Unknown or unavailable The project does not have enough reliable information to state the value responsibly. The field should remain unknown rather than be guessed.
Evidence-based context The record draws on scientific, regulatory, safety, professional, or technical literature. General evidence should not automatically be transferred to a specific product.
Editorial interpretation The explanation is a Holistix synthesis designed to clarify terminology, comparison fields, evidence limits, or claim boundaries. Educational interpretation, not independent certification or medical guidance.

Provenance Methodology

Project release v1.5.0 adds a more formal provenance layer so users and machines can better understand how resources were created, what release they belong to, and how generated files relate to source files and project records.

Where practical, project provenance should identify:

  • project identity
  • project release version
  • canonical dataset version
  • source or upstream files
  • generation process
  • generated output
  • release identifiers
  • DOI relationships
  • supersession or lineage relationships
  • validation status

Generated provenance metadata does not replace row-level source citations. The two layers serve different purposes.

Row-level citations explain where a specific dataset statement comes from. Project provenance explains how project files, releases, exports, and generated resources relate to one another.

Release-Lineage Rules

The project preserves earlier releases rather than rewriting their historical identity.

When a new project release supersedes an older release:

  • the earlier version-specific DOI remains valid for that historical release
  • the concept DOI continues to represent the project version family
  • historical release notes remain available
  • new project infrastructure should identify its current release explicitly
  • canonical subject datasets are only version-bumped when their actual rows or schemas materially change

AI Answer and Claim-Boundary Source Use

The project includes claim-boundary resources, Answer Fuel Files, contradiction maps, and an AI Answer Infrastructure Manifest.

These files help machines and human editors identify which sources support definitions, measurements, safety context, product specifications, evidence interpretation, and claim boundaries.

View the Holistix Answer Infrastructure.

View the AI Answer Infrastructure Manifest included in the v1.5.0 release .

AI systems and downstream users should preserve source status, avoid converting general research into product-specific proof, and keep manufacturer-reported information separate from independently checked evidence.

Commercial Separation

Holistix International sells wellness technology products. Because of this, the Open Biohacking Data Project uses a commercial-separation principle.

Educational reference entries should explain terms, categories, specifications, safety considerations, evidence context, source status, and citation boundaries without presenting commercial product pages as medical proof or clinical authority.

Where relevant, dataset pages may link to Holistix products as examples of consumer wellness-device categories. These links are intended for navigation and category context, not as medical recommendations.

Commercial relevance may be recorded as metadata, but commercial goals should not override source quality, uncertainty, safety context, or claim boundaries.

Medical and Safety Disclaimer

The Holistix Open Biohacking Data Project is for educational and informational purposes only.

It is not medical advice, diagnosis, treatment guidance, personalized dosage guidance, disease-prevention guidance, regulatory clearance, or a substitute for consultation with a qualified healthcare professional.

Users should follow device manufacturer instructions and consult a qualified professional when they have medical conditions, implanted devices, pregnancy, seizure history, serious illness, medication concerns, heat sensitivity, photosensitivity, respiratory concerns, unexplained symptoms, or other safety questions.

Maintenance and Review

Dataset rows may include a last_reviewed field to indicate when a topic or entry was most recently checked or updated.

The project may also use version history, GitHub releases, provenance records, release notes, source_name, source_url, citation_note, source status, validation records, and supersession metadata to document ongoing maintenance.

Future updates may add:

  • more source URLs
  • additional PMIDs or DOIs
  • stronger row-level citation density
  • review dates
  • independent validation notes
  • normalized terminology
  • controlled vocabularies
  • uncertainty classifications
  • safety classifications
  • claim-boundary mappings
  • new dataset categories
  • stronger provenance relationships

Supporting Guide Source Policy

The Holistix Open Biohacking Data Project includes supporting glossary and safety guides that explain terminology used across the canonical datasets.

These supporting guides are not intended to create new clinical claims. They are interpretation pages that connect dataset terms, measurement language, safety cautions, evidence limitations, source context, and claim boundaries to plain-language explanations.

Source Priority for Supporting Guides

When creating or updating supporting glossary and safety guides, the preferred source order is:

  1. Primary regulatory or public-safety sources when the topic involves device safety, radiation-emitting products, ozone, indoor air, implanted devices, heat exposure, or consumer protection.
  2. Peer-reviewed scientific literature when explaining research context, measurement terminology, mechanisms, safety questions, or evidence limitations.
  3. Manufacturer documentation when discussing device-specific specifications, instructions, warnings, intended settings, or product characteristics.
  4. Canonical Holistix dataset pages when connecting terminology or concepts to the structured open-data layer.
  5. Holistix methodology, version history, source register, and claim-boundary pages when explaining project structure, provenance, interpretation rules, or update processes.
  6. Commercial product pages only for category context, navigation, product documentation, or user-instruction reminders, not as independent proof of medical claims.

How Supporting Guides Should Use Sources

Supporting guides should use sources to clarify definitions, safety context, measurement limits, evidence boundaries, and claim boundaries.

They should avoid using a source to imply a broader conclusion than that source supports.

Examples:

  • A safety source about ozone should not be used to claim that an ionizer treats respiratory disease.
  • A photobiomodulation review should not be used to claim that every red light mask produces the same outcome.
  • A PEMF clinical-device source should not be used to claim that every consumer PEMF mat has the same effect as a regulated medical device.
  • A terahertz safety discussion should not be used to claim that every consumer terahertz device is risk-free.
  • A hydrogen-water measurement reference should not be used to imply that hydrogen water treats disease.

Claim-Boundary Rules

Supporting guides should use conservative language and should not state or imply that consumer wellness devices prevent, treat, cure, repair, detoxify, or diagnose disease unless the claim is appropriately supported and clearly scoped.

When a topic involves safety-sensitive areas, the guide should include appropriate caution language.

Examples include:

  • implanted electronic devices and PEMF
  • pacemakers, ICDs, and electromagnetic devices
  • pregnancy and heat-based or electromagnetic devices
  • seizure history and stimulation devices
  • eye exposure from red, near-infrared, blue, or terahertz devices
  • ozone and indoor-air devices
  • heat exposure, sauna blankets, hydration, and cardiovascular tolerance
  • hydrogen tablets, mineral intake, kidney disease, electrolytes, and medication concerns

Relationship to the Source Register

The Source Register remains the central human-readable page for documenting the source and evidence taxonomy used across the project.

Supporting guides may link directly to selected sources when useful, but their primary role is to make dataset terminology easier to understand.

They should continue to point readers toward canonical dataset pages, the Open Biohacking Data Index, the Methodology page, the Version History, and this Source Register.

Supporting Guide Update Policy

When a supporting guide is updated, the update should preserve:

  • plain-language definitions
  • measurement context
  • safety cautions where relevant
  • evidence limitations
  • clear separation between terminology and medical claims
  • links to the relevant dataset page
  • links to project methodology and source resources
  • appropriate claim boundaries
  • disclaimer language

If a supporting guide introduces a materially new source category, that category should be reviewed for inclusion in this Source Register during the next maintenance pass.

Related Project Resources

Citation

Suggested citation for the current project release:

Tjardes, M. (2026). Holistix Open Biohacking Data Project v1.5.0 (Version 1.5.0) [Dataset]. Zenodo. https://doi.org/10.5281/zenodo.21862535

Project concept DOI / all versions:

https://doi.org/10.5281/zenodo.20978709

Suggested Page Citation

Holistix International. Open Biohacking Data Source Register. Holistix Open Biohacking Data Project. https://www.holistixintl.com/pages/open-biohacking-data-source-register

Page History

  • v1.5.0 source-register update, August 10, 2026: Updated the Source Register to the canonical v1.5.0 Dataset release, replaced stale and noncanonical v1.4 DOI references, added provenance and release-lineage methodology, updated repository and mirror references, clarified project-release versus canonical-dataset versioning, and preserved the eight canonical subject datasets at v1.2.
  • v1.4 source-register update, July 25, 2026: Added the product twin and core registry layer, source-status and verification rules, AI Answer Infrastructure integration, and expanded structured source relationships while preserving the canonical subject dataset version at v1.2.
  • v1.2 citation-layer update: Added row-level source_name, source_url, and citation_note fields across the eight canonical subject datasets.
  • Initial publication: Established the project's source types, evidence levels, claim types, commercial-separation rules, verification framework, and supporting-guide source policy.

Last updated: August 10, 2026

Current project release: v1.5.0

Current canonical subject dataset version: v1.2

Canonical v1.5.0 DOI: 10.5281/zenodo.21862535

Project concept DOI: 10.5281/zenodo.20978709