Back to Review

Domain Classification Methodology

Purpose

The domain classification is designed to assign each profile to the most relevant technical or functional domain based on the person’s current or most recent professional activity.

This is an initial AI-supported classification and is used as a calibration layer. The goal of the current review is to validate whether the suggested domain assignments are directionally correct and where the taxonomy should be refined.

Data Used for Classification

For the domain assignment, the model only considered the following profile fields:

  • Current or most recent job title
  • Current or most recent job description
  • LinkedIn headline
  • Summary / bio

Other profile information was intentionally not used for the domain assignment in order to keep the classification focused on the person’s current professional context.

Older roles, education, courses, publications or general background information were not used unless they were clearly connected to the current or most recent role.

Core Classification Logic

The classification follows a two-step logic:

Step 1 — Specific Domain Assignment

The model first checks whether the profile can be clearly assigned to one of the specific domains. A specific domain is only assigned if there are clear indicators that the person is currently working in that area. Keywords alone are not sufficient if the role context does not support the assignment.

Step 2 — Broad Fallback Assignment

If no specific domain can be assigned with sufficient confidence, the profile is assigned to one of three broader technical buckets: Software, Hardware, or Physics / Research. These fallback categories are used to avoid forcing an overly specific classification where the available profile information is too generic or ambiguous.

Specific Domains

Cryo

Assigned when the current role clearly relates to cryogenic systems, low-temperature environments or cryogenic infrastructure.

Typical indicators:

cryogenicscryogeniccryostatdilution refrigeratordilution refrigerationmillikelvin / mKultra-low temperaturelow-temperature physicscryocoolerthermal anchoringcold stagevacuum cansuperconducting fridgecryogenic wiringcryogenic infrastructure

Microwave / RF

Assigned when the current role clearly relates to microwave engineering, RF systems, signal chains or qubit control / readout infrastructure.

Typical indicators:

microwave engineeringRF engineeringradio frequencymicrowave circuitsRF circuitsresonatorsuperconducting resonatorcavitywaveguidecoaxial linesimpedance matchingS-parametersVNA / vector network analyzerRF chainmicrowave controlqubit readoutqubit control pulsessignal integritylow-noise amplifier

Quantum Error Correction

Assigned only when there is an explicit reference to quantum error correction or closely related concepts.

Typical indicators:

quantum error correctionQECfault-tolerant quantum computingfault tolerancelogical qubitlogical error ratesurface codestabilizer codesyndrome extractionsyndrome decodingbosonic codethreshold theoremerror mitigationleakage reductionquantum decoding

Important rule: a generic "Quantum Engineer" or "Quantum Scientist" title is not enough for this category. QEC must be explicitly indicated.

Laser / Optics / Photonics

Assigned when the current role clearly relates to laser systems, optical setups, photonics or photon-based technologies.

Typical indicators:

laser systemslaser controlopticsoptical setupoptical alignmentphotonicsintegrated photonicsinterferometerinterferometrybeam shapingbeam steeringfiber opticsfree-space opticsoptical cavityelectro-opticsacousto-opticssingle-photonphoton sourcedetectorphotodetectorSPADSNSPDwavelength stabilization

Application and Use Case

Assigned when the current role focuses on applied quantum computing, industry applications, customer use cases or business value creation from quantum technologies.

Typical indicators:

quantum applicationsquantum use casesindustry applicationscustomer use casesquantum algorithms for optimizationportfolio optimizationroute optimizationschedulingmaterials simulationchemistry simulationdrug discoverymachine learning applicationsfinancial applicationsenterprise applicationsquantum solution architectapplied quantum computingbusiness value of quantum

Product Management

Assigned when the current role clearly relates to product ownership, product strategy or product lifecycle management.

Typical indicators:

product managerproduct managementtechnical product managergroup product managerprincipal product managerproduct ownerproduct strategyproduct roadmapcustomer requirementsmarket requirementsPRD / product requirements documentfeature prioritizationproduct lifecycleproduct launch

Project Management / PMO

Assigned when the current role clearly relates to project, program or delivery management.

Typical indicators:

project managerprogram managerPMOproject management officeproject planningdelivery managementresource planningtimeline managementmilestone trackingrisk managementdependency managementbudget trackingcross-functional coordinationworkstream leadimplementation managerproject execution

Broad Fallback Categories

Software

Used when the profile primarily points to software, IT, development, data, platforms or engineering work in a software context, but does not clearly match one of the specific domains.

Hardware

Used when the profile primarily points to hardware, electrical engineering, mechanical engineering, manufacturing, instrumentation or physical system components, but does not clearly match one of the specific domains.

Physics / Research

Used when the profile is clearly physics-oriented, research-oriented or quantum-science-oriented, but does not provide enough evidence for a more specific domain.

Special rule: if a profile only states a generic title such as "Quantum Engineer" without additional information that supports a more specific domain, it is assigned to Physics / Research by default.

Decision Rules

The classification uses the following principles:

  • Current or most recent role is weighted highest
  • Specific domains are checked before broad fallback categories
  • A specific domain requires clear evidence from the current role context
  • Keywords are treated as indicators, not automatic matches
  • If the profile is ambiguous, the model falls back to Software, Hardware or Physics / Research
  • Each profile receives exactly one suggested domain
  • The current review is intended to validate and refine these suggestions before scaling the model further

Review Objective

For this calibration set, the main review questions are:

  • Does the suggested domain make sense based on the current role?
  • Would you classify the profile differently?
  • Are any domains missing from the taxonomy?
  • Are the fallback categories Software, Hardware and Physics / Research useful for ambiguous profiles?
  • Are there recurring edge cases that should be handled differently in the next model iteration?