Skip to content

Domain, Metro & Competency Entities

Chazona Baum edited this page Jun 24, 2026 · 1 revision

Relevant source files

Lodestar uses three primary reference entities to provide structure to unstructured Job Description (JD) data: Domains, Metros, and Competencies. These entities function as controlled vocabularies that allow the system to map free-text strings (from LLM extraction or scraping) into stable, user-defined categories for filtering and scoring.

Data Flow: Natural Language to Code Entities

The following diagram illustrates how raw text from a Job Description is resolved into structured Rust entities through normalization and alias matching.

Text Resolution Pipeline

flowchart LR
    subgraph subGraph2 ["Code Entity Space"]
        D["MetroIndex::resolve()"]
        E["CompetencyIndex::matches()"]
        F["Domain::parse_domain()"]
        G["metros/new-york-city.md"]
        H["competencies/react.md"]
        I["domains/financial-services.md"]
    end
    subgraph subGraph1 ["Normalization (note::slugify)"]
        A1["'nyc'"]
        B1["'react-js'"]
        C1["'fintech'"]
    end
    subgraph subGraph0 ["Natural Language Space"]
        A["'NYC' (Location String)"]
        B["'React.js' (Skill String)"]
        C["'Fintech' (Domain String)"]
    end
    A --> A1
    A1 --> D
    B --> B1
    B1 --> E
    C --> C1
    C1 --> F
    D --> G
    E --> H
    F --> I
Loading

Sources: src-tauri/src/metro.rs#73-97src-tauri/src/competency.rs#55-59src-tauri/src/domain.rs#26-35


Domain Entity

Domains represent industry or functional categories (e.g., "Financial Services", "Healthcare"). They are stored in the vault under the domains/ directory src-tauri/src/domain.rs#39

Data Model & Screening

Each domain can be tagged with a screening status, which propagates to any company associated with that domain src-tauri/src/domain.rs#15

Field Type Description
slug String Unique identifier derived from filename src-tauri/src/domain.rs#11
name String Display name; defaults to slug if not in frontmatter src-tauri/src/domain.rs#31
aliases Vec<String> Alternative names for matching (e.g., "Fintech" for "Financial Services") src-tauri/src/domain.rs#13
screening Option<String> Can be "dealbreaker" or "caution"src-tauri/src/domain.rs#14-15

Implementation Details

  • Parsing: The parse_domain function extracts YAML frontmatter using split_frontmattersrc-tauri/src/domain.rs#26-35
  • Screening Map: The screening_map function builds a HashMap<String, String> (slug -> status) used during company loading to flag undesirable industries src-tauri/src/domain.rs#66-76
  • Frontend: The DomainPicker.svelte component provides a searchable Combobox for assigning domains to companies, rendering them as removable chips src/lib/DomainPicker.svelte#26-38

Sources: src-tauri/src/domain.rs#9-35src/lib/domain.ts#3-8src/lib/DomainPicker.svelte#1-38


Metro Entity

Metros represent geographic regions. The system uses a specialized MetroIndex to resolve ambiguous location strings (like "Norfolk, VA") into a single canonical metro slug src-tauri/src/metro.rs#1-2

Metro Resolution Logic

The MetroIndex::resolve function implements a multi-step candidate search:

  1. Candidate Generation: Splits the input string by commas and treats both the whole string and parts as candidates src-tauri/src/metro.rs#74-76
  2. Normalization: Every candidate is passed through note::slugifysrc-tauri/src/metro.rs#80
  3. Ambiguity Handling: If a slugified key (like richmond) maps to multiple metros, it is skipped unless a more specific candidate resolves the conflict src-tauri/src/metro.rs#84-89
  4. Single Hit Rule: Returns a slug only if exactly one distinct metro is identified src-tauri/src/metro.rs#92-96

Metro Index Structure

classDiagram
    class Metro {
        +String slug
        +String name
        +String country
        +Vec<String> aliases
    }
    class MetroIndex {
        -HashMapUnsupported markdown: del> keys
        +build(metros: &[Metro]) : MetroIndex
        +resolve(location: &str) : Option<String>
    }
    MetroIndex -- Metro
Loading

Sources: src-tauri/src/metro.rs#10-15src-tauri/src/metro.rs#41-43src-tauri/src/metro.rs#73-97


Competency Entity

Competencies define the skills and technologies the user tracks (e.g., "Ruby on Rails"). They are stored in competencies/*.mdsrc-tauri/src/competency.rs#34-35

Competency Matching

Unlike Metros, which resolve to a single canonical slug, the CompetencyIndex is primarily used to validate if a skill mentioned in a JD exists in the user's "known" universe src-tauri/src/competency.rs#1-2

Example Resolution

Input Term Normalized Key Match Target Result
"a11y" a11y aliases: ["a11y"] true
"Ruby on Rails" ruby-on-rails name: "Ruby on Rails" true
"WCAG" wcag aliases: ["WCAG"] true

Sources: src-tauri/src/competency.rs#10-14src-tauri/src/competency.rs#37-39src-tauri/src/competency.rs#55-59


Persistence & Loading

All three entities follow the Lodestar "Note" pattern:

  1. Storage: Markdown files in specific vault subdirectories (/domains, /metros, /competencies) src-tauri/src/domain.rs#39src-tauri/src/metro.rs#37src-tauri/src/competency.rs#34
  2. Loading: Rust functions list_domains, list_metros, and list_competencies use note::read_notes_in to bulk-parse files into structs src-tauri/src/domain.rs#57-61src-tauri/src/metro.rs#36-38src-tauri/src/competency.rs#33-35
  3. Tauri Commands: Domains are exposed to the frontend via the list_domains command for use in UI pickers src-tauri/src/domain.rs#56-61

Sources: src-tauri/src/domain.rs#38-54src-tauri/src/metro.rs#25-34src-tauri/src/competency.rs#23-31

Clone this wiki locally