Device Architecture Taxonomy (TREF-0004)

Defines how this archive classifies thermal extraction devices so that hundreds of device pages describe the same engineering reality with the same words. The model is the governing standard for devices/TED-* records; device pages are expected to map their specification tables and tags onto the axes below.

Design rule: orthogonal axes, not one “type” field

A device is not one exclusive type. Classification is expressed across five orthogonal axes, each with its own controlled vocabulary. A record may carry multiple values on an axis only where the hardware genuinely supports them (e.g., hybrid heating, dual power). No single frontmatter or prose field may substitute for the axes.

The machine-readable vocabulary lives in metadata/device-taxonomy.json and is enforced by scripts/audit_device_taxonomy.py. Migration guidance for existing records is in docs/device-taxonomy-migration.md.

1. Heating mechanism

How heat is transferred to the load. Distinct from heat generation (where the heat originates): a torch (heat-generation: direct flame) can deliver heat by convection (heating mechanism).

Rules:

• hybrid is a deliberate combination term — do not tag a device hybrid plus a single dominant mechanism unless the manufacturer states a ratio.
• Do not use conduction and convection together on the same record to mean “hybrid”; use the single hybrid value (contradiction rule TAX-01).
• radiant may co-occur with another mechanism where documented (Launch Box: conduction + infrared).

2. Heat-generation mechanism

Where the thermal energy originates — the heating element or energy conversion inside the device. This axis is frequently confused with heating mechanism; keep the two separate.

Rules:

• direct flame and indirect flame are mutually exclusive (contradiction rule TAX-02).
• induction (heat-generation) is distinct from induction heater (a power source, axis 5): the Switch² generates heat inductively inside the device; an induction heater is an external appliance that powers a flame-style device (DynaVap + Ispire Wand).

3. Delivery mode

How the user draws the aerosol from the device.

A single device may support several delivery modes (e.g., Cloud EVO: whip or water-tool). Record each supported mode explicitly.

4. Operating mode

The usage pattern the hardware is designed for.

Rules:

• manual thermal cycle is the operating-mode term for torch-driven devices; do not use “analog” as a synonym (analog describes the control interface, not the operating mode).
• A device can support multiple operating modes (Solo III: Session + On-Demand). manual thermal cycle normally excludes session unless the manufacturer documents a session-style usage (contradiction rule TAX-03).

5. Power

The energy input that drives the device.

Rules:

• torch and induction heater may both apply to the same device (DynaVap supports both) — record both.
• battery and mains are mutually exclusive as primary power for a single unit unless the manufacturer documents dual power or pass-through operation (contradiction rule TAX-04).

Ball-vape component modeling

Ball vapes are modular. A retailer bundle is not a device model. Before creating a devices/TED-* entity for a ball-vape SKU, assign its component role:

Rules:

• A bundle is not an entity. A retailer bundle that repackages an existing head+coil+PID+bowl is a SKU of the existing model, not a new devices/TED-* record (rule TAX-05). Reference the bundle only as a source note on the model’s page.

• Heads, coils, PIDs, bowls, and stands are components, not standalone devices. Create a TED-* entity for a component only when it is a substantive, separately-purchasable platform (e.g., the ZenLeaf Nova is a system/station; the B1 is a heater head). Otherwise record the component in the parent system/head’s specification table.

• When a head entity exists, its spec table names the coil/PID/bowl it mates with (e.g., “20 mm enail coil + external PID controller (CH or Auber)”) rather than implying they are part of the head.

• A page for a head must say “heater head” explicitly in its family/summary so it is not mistaken for a complete system.

• A marketing name does not promote a component to a model (rule TAX-06). Manufacturers rename and relaunch parts. If a SKU is currently sold as a component of a modeled head or system, it does not get its own devices/TED-* record — even if it once carried its own product name, its own page, and its own price. Record it as a spec-table row on the records that use it, and narrate the former name as a lineage stage on the manufacturer or family-lineage page.

  The discriminator is what the listing sold, not what it was called: a listing offering the parts needed to complete a working head (for example a diffuser plus a top or nut) is an assembly and may earn a record; a listing offering only an insert that drops into a head the buyer already owns is a component. Apply the test to the listing as it stood, then check whether the part still ships inside a current product.

  Worked example: Cannabis Hardware part 3408 was sold as the “Screen Baller”, a named generation in the manufacturer’s own lineage blog. Its listing contained only the diffuser and a screen — no top — and the same part ships today inside the B1 and B2 heads as the “22mm Standard Diffuser”. It is a component. Part 3405, the “Baller Head Assembly”, sold top-with-dish variants on the same listing and is discontinued; it is a heater head and holds a record.

Family lineage — the worked example

The component model above is abstract by design; it has to classify a torch-heated pan and a mains-powered base station with the same five axes. Cannabis Hardware Family Lineage (TGDE-0006) is the reference application of it: a single manufacturer’s FlowerPot, ZenLeaf, and Airstream catalog mapped end to end, with every modeled record assigned a component role and every deliberately unmodeled SKU recorded as a component or a bundle rather than silently omitted.

Consult it when a new record raises one of the recurring questions this standard answers in the abstract:

• Whether a SKU is a model, a component, or a bundle — the guide shows the call already made, with the manufacturer evidence behind it.
• How a head relates to the station that heats it, and how both relate to the coil, PID, and bowl named in their specification tables.
• How a generational chain is expressed — supersedes between records, with approximate or unpublished dates labelled rather than invented.

A family index of this shape is the expected companion to any manufacturer whose catalog grows past a handful of interdependent records. The lineage guide is the pattern to copy.

Reusable terminology

Device pages must use the following terms consistently:

Relation conventions

Boris relations on device pages follow the established kinds (relates_to, supersedes, depends_on, implements):

• Device → manufacturer: relates_to=manufacturers/TMFR-XXXX.
• Successor models: supersedes=devices/TED-XXXX (newer → older).
• Family/sibling links: relates_to=devices/TED-XXXX.
• Component relationships (head ↔ system/station) are expressed with relates_to plus explicit terminology in the spec table; do not invent relation kinds.

Validation

scripts/audit_device_taxonomy.py enforces the vocabulary and the contradiction rules TAX-01…TAX-05 against content/devices/*.md. See metadata/device-taxonomy.json for the machine-readable rule set and docs/device-taxonomy-migration.md for the state of existing pages.

TAX-06 is a review rule, not a machine check. Deciding whether a SKU is currently sold as a component of another product requires reading the manufacturer’s listing, so no audit can enforce it. It is applied when a record is created or revised, and any record it excludes is written into the family-lineage page’s “deliberately not modeled” table so the decision is auditable by a reader rather than by a script.

The record-completeness floor

A standard most records do not implement is not a standard. Before 2026-08-08 this document described five axes while no record in the corpus carried a tag on all five — heat generation was absent from 44 of 45 records and power from 43. The gap was invisible because nothing measured it.

scripts/audit_record_completeness.py now measures it, and bin/validate_graph.sh enforces it on every build:

The severity split is deliberate. REC-01 to REC-03 are objective and mechanically decidable, so they block a build. REC-04 to REC-06 depend on how much a manufacturer chose to publish, so they inform without failing a record that is honestly thin.

Two consequences worth stating plainly. An absent part number is recorded, not omitted — “Not published by the manufacturer” satisfies REC-02, because the reader learns the identifier does not exist instead of wondering whether the archive forgot. And a record may not rest on the internal research corpus alone: dossier provenance is a pointer to where research happened, never a citation a reader can follow.

Related pages

• Physical Property Data Standards (TREF-0001)
• Evidence Labels and Claim Grammar (TREF-0003)
• Cannabis Hardware Family Lineage (TGDE-0006) — reference application of this standard
• Devices catalog