Pipeline run
c123e6af-1ee0-46fc-ac24-3514f0fbd8fb
Client output enrichment
v2 Skill cluster · Nature of work · AI index · Tech stack maturity · Evidence · KRA description
role baseline loaded
sources · ai_index: jd · nature_of_work: no_kras · tech_stack_maturity: jd
Nature of work
no kras
Vague JD — no KRAs present to derive a specific nature of work.
Tech stack maturity
Mainstream Modern
AI index (0 = no AI use, 5 = totally AI-dependent · v2.1)
0.00 / 5
· Title match
· Has AI skill
· AI skill (primary)
· AI skill (secondary)
· On AI team
· Builds AI products
vocab breakdown (legacy)
Assistants (×1):
—
Frameworks (×2):
—
Models / concepts (×3):
—
Evidence — skills matched in JD (0)
Skill cluster (0 dimension groups, role-scoped)
Status:
completed
Created: 2026-05-08T07:57:28.055709Z
Updated: 2026-05-08T07:59:26.572629Z
API 3 duration: 703 ms
Flow
Current 3-step pipeline
1 POST /skills/extract-from-jd
2 POST /skills/extract-details
3 POST /skills/final-role-output
Role
Chosen role & resolution
DevOps Engineer
slug: devops-engineer · id: 1 · source: db
DevOps Engineer is the dominant role across observability, configuration management, IaC, containerization, cloud operations, and CI/CD dimensions.
0
New skills
0
Skill↔dim saved
0
Role↔dim saved
48
Skipped
Job description
Job Description – DevOps Engineer Job Title: DevOps Engineer Experience: 3–6 Years Location: Hyderabad / Remote / Hybrid About the Role We are looking for a skilled DevOps Engineer to build, automate, and maintain scalable infrastructure and deployment pipelines. The ideal candidate should have strong experience in CI/CD, cloud platforms, containerization, and monitoring systems to support high-availability applications. Key Responsibilities Design and maintain CI/CD pipelines for automated build, test, and deployment processes Manage cloud infrastructure across AWS, Azure, or GCP environments Deploy and maintain containerized applications using Docker and Kubernetes Automate infrastructure provisioning using Infrastructure as Code tools Monitor system performance, uptime, and reliability using observability tools Collaborate with development and QA teams to improve deployment efficiency Implement security best practices and access control mechanisms Troubleshoot production issues and optimize system performance Maintain backup, disaster recovery, and scaling strategies Support release management and environment configuration activities Required Skills Strong experience with Linux system administration Hands-on experience with Docker and Kubernetes Experience with CI/CD tools like Jenkins, GitHub Actions, or GitLab CI Knowledge of cloud platforms such as AWS, Azure, or GCP Experience with Terraform, Ansible, or CloudFormation Understanding of networking, DNS, load balancing, and security concepts Familiarity with monitoring tools like Prometheus, Grafana, ELK, or Datadog Scripting knowledge in Bash, Python, or Shell scripting Preferred Qualifications Bachelor’s degree in Computer Science, IT, or related field Experience working in microservices-based architectures Knowledge of container orchestration and scaling strategies Cloud or Kubernetes certifications are a plus Nice to Have Exposure to SRE practices and incident management Experience with Kafka, Redis, or message queue systems Knowledge of security scanning and DevSecOps practices Benefits Flexible working hours Health and wellness benefits Learning and certification support Internet/work-from-home allowance Paid time off and holidays Collaborative engineering culture
history_view bundle (older API). Showing raw API payloads below.
All API 3 persistence rows
Same grid as the skill-extractor “Persistence items” table: one row per (skill × dimension) work item.
| Skill | Tag | Dimension | Skill↔dim | Role↔dim | Outcome | Notes |
|---|---|---|---|---|---|---|
| Disaster Recovery | in_db |
Backup and Disaster Recovery
backup-and-disaster-recovery
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Redis | in_db |
NoSQL and Cache Stores
nosql-and-cache-stores
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Datadog | in_db |
Observability and Alerting
observability-and-alerting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Load Balancing | in_db |
Scaling and Resilience Engineering
scaling-and-resilience-engineering
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Bash | in_db |
Build and Execution Tooling
build-and-execution-tooling
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Ansible | in_db |
Configuration Management
configuration-management
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Ansible | in_db |
Network Automation and Scripting
network-automation-and-scripting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Kubernetes | in_db |
Orchestration Platforms
orchestration-platforms
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| shell scripting | in_db |
Programming for Data Automation
programming-for-data-automation
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Microservices | in_db |
Service Architecture and Integration
service-architecture-and-integration
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Terraform | in_db |
Infrastructure Provisioning Templates
infrastructure-provisioning-templates
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Terraform | in_db |
Infrastructure as Code
infrastructure-as-code
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Terraform | in_db |
Infrastructure as Code and Declarative Provisioning
infrastructure-as-code-and-declarative-provisioning
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| CloudFormation | in_db |
Infrastructure as Code
infrastructure-as-code
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Jenkins | in_db |
Continuous Integration Test Integration
continuous-integration-test-integration
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| GitLab CI | in_db |
Continuous Integration Test Integration
continuous-integration-test-integration
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Analytical Programming Languages
analytical-programming-languages
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Automation Scripting and CLI
automation-scripting-and-cli
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Network Automation and Scripting
network-automation-and-scripting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Programming Languages for AI Workflows
programming-languages-for-ai-workflows
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Programming Languages for Backend Systems
programming-languages-for-backend-systems
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Programming Languages for Data Work
programming-languages-for-data-work
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Programming Languages for ML Systems
programming-languages-for-ml-systems
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Programming Languages for Test Automation
programming-languages-for-test-automation
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Python | in_db |
Security Automation and Scripting
security-automation-and-scripting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Grafana | in_db |
Observability and Alerting
observability-and-alerting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Grafana | in_db |
Observability and Diagnostics
observability-and-diagnostics
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Docker | in_db |
Containerization and Image Delivery
containerization-and-image-delivery
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Docker | in_db |
Model Serving Deployment and Runtime Packaging
model-serving-deployment-and-runtime-packaging
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Prometheus | in_db |
Observability and Alerting
observability-and-alerting
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Prometheus | in_db |
Observability and Diagnostics
observability-and-diagnostics
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Azure | in_db |
Cloud Platform Operations
cloud-platform-operations
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| GitHub Actions | in_db |
Continuous Integration Test Integration
continuous-integration-test-integration
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| Kafka | in_db |
Messaging and Event Streaming
messaging-and-event-streaming
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| AWS | in_db |
Cloud Platform Operations
cloud-platform-operations
|
— | — | — | TODO: REMOVE AFTER TESTING — api3_writes_enabled=False (writes disabled) |
| CI | new |
Continuous Integration
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| CI | new |
Build and Test Automation
d_init_02
|
— | — | — | skill_not_in_db_v3_proposed |
| Code | new |
General Programming Code
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| ELK | new |
Log Aggregation and Search
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Exposure | new |
Exposure Management
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Infrastructure | new |
Infrastructure Engineering
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Knowledge | new |
Domain Knowledge
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Linux | new |
Linux System Administration
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Monitor | new |
Operational Monitoring
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| SRE | new |
Site Reliability Engineering
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Scripting | new |
General Automation Scripting
d_init_02
|
— | — | — | skill_not_in_db_v3_proposed |
| Understanding | new |
Technical Understanding and Comprehension
d_init_01
|
— | — | — | skill_not_in_db_v3_proposed |
| Understanding | new |
Requirements Comprehension
d_init_02
|
— | — | — | skill_not_in_db_v3_proposed |
Library artifacts (this run)
| Kind | Detail | DB id |
|---|---|---|
| canonical_skill_proposed | CI | type=Methodology subtype=continuous_integration nature=METHODOLOGY lifespan=EVERGREEN | |
| canonical_skill_proposed | Cloud | type=Domain subtype=cloud_computing nature=CONCEPT lifespan=EVERGREEN | |
| canonical_skill_proposed | Code | type=Language subtype=programming_language nature=LANGUAGE lifespan=EVERGREEN | |
| canonical_skill_proposed | ELK | type=Tool subtype=log_analysis_stack nature=TOOL lifespan=EVERGREEN | |
| canonical_skill_proposed | Exposure | type=Concept subtype=risk_exposure nature=CONCEPT lifespan=EVERGREEN | |
| canonical_skill_proposed | Infrastructure | type=Domain subtype=infrastructure nature=CONCEPT lifespan=EVERGREEN | |
| canonical_skill_proposed | Knowledge | type=Concept subtype=general_knowledge nature=CONCEPT lifespan=EVERGREEN | |
| canonical_skill_proposed | Linux | type=Concept subtype=operating_system nature=CONCEPT lifespan=EVERGREEN | |
| canonical_skill_proposed | Monitor | type=Tool subtype=monitoring_tool nature=TOOL lifespan=EVERGREEN | |
| canonical_skill_proposed | QA | type=SoftSkill subtype=quality_assurance nature=PRACTICE lifespan=EVERGREEN | |
| canonical_skill_proposed | SRE | type=Methodology subtype=site_reliability_engineering nature=METHODOLOGY lifespan=EVERGREEN | |
| canonical_skill_proposed | Scripting | type=Language subtype=scripting_language nature=LANGUAGE lifespan=EVERGREEN | |
| canonical_skill_proposed | Understanding | type=Concept subtype=comprehension nature=CONCEPT lifespan=EVERGREEN | |
| dimension_proposed | Continuous Integration | |
| dimension_skill_link_proposed | CI ↔ Continuous Integration | |
| dimension_proposed | Build and Test Automation | |
| dimension_skill_link_proposed | CI ↔ Build and Test Automation | |
| dimension_proposed | General Programming Code | |
| dimension_skill_link_proposed | Code ↔ General Programming Code | |
| dimension_proposed | Log Aggregation and Search | |
| dimension_skill_link_proposed | ELK ↔ Log Aggregation and Search | |
| dimension_proposed | Exposure Management | |
| dimension_skill_link_proposed | Exposure ↔ Exposure Management | |
| dimension_proposed | Infrastructure Engineering | |
| dimension_skill_link_proposed | Infrastructure ↔ Infrastructure Engineering | |
| dimension_proposed | Domain Knowledge | |
| dimension_skill_link_proposed | Knowledge ↔ Domain Knowledge | |
| dimension_proposed | Linux System Administration | |
| dimension_skill_link_proposed | Linux ↔ Linux System Administration | |
| dimension_proposed | Operational Monitoring | |
| dimension_skill_link_proposed | Monitor ↔ Operational Monitoring | |
| dimension_proposed | Site Reliability Engineering | |
| dimension_skill_link_proposed | SRE ↔ Site Reliability Engineering | |
| dimension_proposed | General Automation Scripting | |
| dimension_skill_link_proposed | Scripting ↔ General Automation Scripting | |
| dimension_proposed | Technical Understanding and Comprehension | |
| dimension_skill_link_proposed | Understanding ↔ Technical Understanding and Comprehension | |
| dimension_proposed | Requirements Comprehension | |
| dimension_skill_link_proposed | Understanding ↔ Requirements Comprehension |
API 1 — extract-from-jd click to toggle
{
"filtered_unknown_words": [
"3\u20136",
"Actions",
"Automate",
"Bachelor",
"Benefits",
"CD",
"CI",
"Cloud",
"Code",
"Computer",
"Description",
"Design",
"ELK",
"Engineer",
"Experience",
"Exposure",
"Familiarity",
"Hands",
"Health",
"Hybrid",
"Hyderabad",
"Infrastructure",
"Internet",
"Job",
"Key",
"Knowledge",
"Learning",
"Linux",
"Location",
"Monitor",
"Preferred",
"QA",
"Qualifications",
"Remote",
"Required",
"Responsibilities",
"Role",
"SRE",
"Science",
"Scripting",
"Skills",
"Support",
"Title",
"Understanding",
"Years",
"access",
"administration",
"allowance",
"applications",
"architectures",
"availability",
"balancing",
"benefits",
"build",
"candidate",
"certification",
"certifications",
"cloud",
"concepts",
"configuration",
"container",
"control",
"culture",
"degree",
"deployment",
"development",
"disaster",
"efficiency",
"engineering",
"environment",
"environments",
"experience",
"field",
"holidays",
"home",
"hours",
"incident",
"infrastructure",
"issues",
"knowledge",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"scripting",
"security",
"strategies",
"support",
"system",
"systems",
"teams",
"test",
"time",
"tools",
"wellness",
"work"
],
"final_non_skills": [
"3\u20136",
"Actions",
"Automate",
"Bachelor",
"Benefits",
"CD",
"Computer",
"Description",
"Design",
"Engineer",
"Experience",
"Familiarity",
"Hands",
"Health",
"Hybrid",
"Hyderabad",
"Internet",
"Job",
"Key",
"Learning",
"Location",
"Preferred",
"Qualifications",
"Remote",
"Required",
"Responsibilities",
"Role",
"Science",
"Skills",
"Support",
"Title",
"Years",
"allowance",
"availability",
"candidate",
"certification",
"certifications",
"concepts",
"culture",
"degree",
"field",
"holidays",
"home",
"hours",
"teams",
"time",
"wellness",
"work"
],
"final_skills": [
"Disaster Recovery",
"Redis",
"Datadog",
"Load Balancing",
"Bash",
"Ansible",
"Kubernetes",
"shell scripting",
"Microservices",
"Terraform",
"CloudFormation",
"Jenkins",
"GitLab CI",
"Python",
"Grafana",
"Docker",
"Prometheus",
"Azure",
"GitHub Actions",
"Kafka",
"AWS",
"CI",
"Cloud",
"Code",
"ELK",
"Exposure",
"Infrastructure",
"Knowledge",
"Linux",
"Monitor",
"QA",
"SRE",
"Scripting",
"Understanding",
"access",
"administration",
"applications",
"architectures",
"balancing",
"build",
"configuration",
"container",
"control",
"deployment",
"development",
"disaster",
"efficiency",
"environment",
"environments",
"incident",
"issues",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"security",
"strategies",
"system",
"systems",
"test",
"tools"
],
"initial_skills": [
"Disaster Recovery",
"Redis",
"Datadog",
"Load Balancing",
"Bash",
"Ansible",
"Kubernetes",
"shell scripting",
"Microservices",
"Terraform",
"CloudFormation",
"Jenkins",
"GitLab CI",
"Python",
"Grafana",
"Docker",
"Prometheus",
"Azure",
"GitHub Actions",
"Kafka",
"AWS"
],
"jd_role_hint": {
"display_name": "DevOps Engineer",
"rationale": "The excerpt centers on building and maintaining scalable infrastructure, CI/CD pipelines, cloud platforms, containerization, and monitoring.",
"role_archetype": "Infrastructure and deployment-focused engineer responsible for automation, CI/CD, cloud operations, and reliability.",
"slug": "devops-engineer"
},
"llm_non_skills": [
"3\u20136",
"Actions",
"Automate",
"Bachelor",
"Benefits",
"CD",
"Computer",
"Description",
"Design",
"Engineer",
"Experience",
"Familiarity",
"Hands",
"Health",
"Hybrid",
"Hyderabad",
"Internet",
"Job",
"Key",
"Learning",
"Location",
"Preferred",
"Qualifications",
"Remote",
"Required",
"Responsibilities",
"Role",
"Science",
"Skills",
"Support",
"Title",
"Years",
"allowance",
"availability",
"candidate",
"certification",
"certifications",
"concepts",
"culture",
"degree",
"field",
"holidays",
"home",
"hours",
"teams",
"time",
"wellness",
"work"
],
"llm_skills": [
"CI",
"Cloud",
"Code",
"ELK",
"Exposure",
"Infrastructure",
"Knowledge",
"Linux",
"Monitor",
"QA",
"SRE",
"Scripting",
"Understanding",
"access",
"administration",
"applications",
"architectures",
"balancing",
"build",
"cloud",
"configuration",
"container",
"control",
"deployment",
"development",
"disaster",
"efficiency",
"environment",
"environments",
"incident",
"infrastructure",
"issues",
"knowledge",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"scripting",
"security",
"strategies",
"system",
"systems",
"test",
"tools"
],
"run_id": null,
"unknown_words": [
"3\u20136",
"Actions",
"Automate",
"Bachelor",
"Benefits",
"CD",
"CI",
"Cloud",
"Code",
"Computer",
"Description",
"Design",
"ELK",
"Engineer",
"Experience",
"Exposure",
"Familiarity",
"Hands",
"Health",
"Hybrid",
"Hyderabad",
"Infrastructure",
"Internet",
"Job",
"Key",
"Knowledge",
"Learning",
"Linux",
"Location",
"Monitor",
"Preferred",
"QA",
"Qualifications",
"Remote",
"Required",
"Responsibilities",
"Role",
"SRE",
"Science",
"Scripting",
"Skills",
"Support",
"Title",
"Understanding",
"Years",
"access",
"administration",
"allowance",
"applications",
"architectures",
"availability",
"balancing",
"benefits",
"build",
"candidate",
"certification",
"certifications",
"cloud",
"concepts",
"configuration",
"container",
"control",
"culture",
"degree",
"deployment",
"development",
"disaster",
"efficiency",
"engineering",
"environment",
"environments",
"experience",
"field",
"holidays",
"home",
"hours",
"incident",
"infrastructure",
"issues",
"knowledge",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"scripting",
"security",
"strategies",
"support",
"system",
"systems",
"teams",
"test",
"time",
"tools",
"wellness",
"work"
]
}
API 2 — extract-details
{
"alias_matches": [],
"candidate_roles": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
},
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
},
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
},
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
},
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
},
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
},
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
},
{
"display_name": "Data Analyst",
"id": 20,
"rationale": null,
"role_archetype": null,
"slug": "data-analyst",
"source": "db"
},
{
"display_name": "AI Engineer",
"id": 12,
"rationale": null,
"role_archetype": null,
"slug": "ai-engineer",
"source": "db"
},
{
"display_name": "Data Engineer",
"id": 6,
"rationale": null,
"role_archetype": null,
"slug": "data-engineer",
"source": "db"
},
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
},
{
"display_name": "Cybersecurity Engineer",
"id": 9,
"rationale": null,
"role_archetype": null,
"slug": "cybersecurity-engineer",
"source": "db"
},
{
"display_name": "MLOps Engineer",
"id": 5,
"rationale": null,
"role_archetype": null,
"slug": "mlops-engineer",
"source": "db"
}
],
"chosen_role": {
"display_name": "DevOps Engineer",
"id": 1,
"rationale": "DevOps Engineer is the dominant role across observability, configuration management, IaC, containerization, cloud operations, and CI/CD dimensions.",
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Backup and Disaster Recovery",
"id": 51,
"rationale": "Plans and operates backup, restore, and disaster recovery capabilities for Azure environments. This is a distinct cluster because recovery objectives and restore mechanics are specialized operational skills.",
"slug": "backup-and-disaster-recovery",
"source": "db"
},
"input_skill": "Disaster Recovery",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "NoSQL and Cache Stores",
"id": 145,
"rationale": "Non-relational databases and in-memory stores used for low-latency access, flexible schemas, and specialized persistence patterns. This cluster is coherent because backend services often combine these stores with relational systems.",
"slug": "nosql-and-cache-stores",
"source": "db"
},
"input_skill": "Redis",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Datadog",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Scaling and Resilience Engineering",
"id": 45,
"rationale": "Implements Azure-side patterns that improve availability, capacity, and fault tolerance. This is a coherent cluster because the role must keep environments ready for production load and failure scenarios.",
"slug": "scaling-and-resilience-engineering",
"source": "db"
},
"input_skill": "Load Balancing",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Build and Execution Tooling",
"id": 206,
"rationale": "Command-line and build tools used to run, package, and integrate automated tests into developer workflows. This cluster is coherent because automation testers often need to wire tests into local and shared execution paths.",
"slug": "build-and-execution-tooling",
"source": "db"
},
"input_skill": "Bash",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Configuration Management",
"id": 23,
"rationale": "Manages environment-specific settings, secrets wiring, and standardized runtime configuration across services. It is distinct from infrastructure provisioning because it focuses on how software is parameterized at deploy time.",
"slug": "configuration-management",
"source": "db"
},
"input_skill": "Ansible",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"input_skill": "Ansible",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Orchestration Platforms",
"id": 25,
"rationale": "Operates the platforms that schedule and run containerized workloads and related deployment primitives. This is separate from image delivery because it concerns runtime placement and service rollout behavior.",
"slug": "orchestration-platforms",
"source": "db"
},
"input_skill": "Kubernetes",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
},
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming for Data Automation",
"id": 93,
"rationale": "Lightweight scripting used to automate repetitive analysis tasks, data preparation, and report generation. This is a useful split because data scientists often need practical automation without owning full pipelines.",
"slug": "programming-for-data-automation",
"source": "db"
},
"input_skill": "shell scripting",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Service Architecture and Integration",
"id": 148,
"rationale": "Patterns for structuring backend systems as services and coordinating calls across internal and external dependencies. This includes how services are decomposed, connected, and evolved safely.",
"slug": "service-architecture-and-integration",
"source": "db"
},
"input_skill": "Microservices",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure Provisioning Templates",
"id": 291,
"rationale": "Declarative templates and modules used to create repeatable cloud resources and environments. This cluster covers the infrastructure definitions the role applies, reviews, and updates to keep environments consistent.",
"slug": "infrastructure-provisioning-templates",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code and Declarative Provisioning",
"id": 36,
"rationale": "Defines cloud and platform infrastructure declaratively through versioned code so environments are repeatable, reviewable, and automatable. This includes authoring and maintaining IaC templates/modules, managing parameters and state, and using plan/apply workflows to provision and update resources across Azure and other cloud platforms.",
"slug": "infrastructure-as-code-and-declarative-provisioning",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"input_skill": "CloudFormation",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "Jenkins",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "GitLab CI",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Analytical Programming Languages",
"id": 82,
"rationale": "Languages used to clean, transform, analyze, and prototype models in notebooks and scripts. This is the core coding surface for expressing statistical logic and data manipulation in a reproducible way.",
"slug": "analytical-programming-languages",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Analyst",
"id": 20,
"rationale": null,
"role_archetype": null,
"slug": "data-analyst",
"source": "db"
},
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Automation Scripting and CLI",
"id": 48,
"rationale": "Uses scripts and command-line tooling to execute repeatable Azure operations and reduce manual work. This is a practical cluster because the role frequently automates provisioning, checks, and remediation tasks.",
"slug": "automation-scripting-and-cli",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
},
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for AI Workflows",
"id": 261,
"rationale": "Languages used to implement AI feature logic, orchestration, and response handling inside product code. This is the core coding surface for turning prompts and model calls into reliable application behavior.",
"slug": "programming-languages-for-ai-workflows",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "AI Engineer",
"id": 12,
"rationale": null,
"role_archetype": null,
"slug": "ai-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Backend Systems",
"id": 140,
"rationale": "Languages used to implement server-side business logic, request handlers, workers, and service integrations. This is the core coding surface for backend feature delivery and maintenance.",
"slug": "programming-languages-for-backend-systems",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Data Work",
"id": 67,
"rationale": "Languages used to implement data pipelines, transformations, and operational utilities. This is the code layer for expressing extraction, parsing, validation, and orchestration logic in data engineering workflows.",
"slug": "programming-languages-for-data-work",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Engineer",
"id": 6,
"rationale": null,
"role_archetype": null,
"slug": "data-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for ML Systems",
"id": 113,
"rationale": "Languages used to implement model integration code, inference services, and feature-processing logic. This is the core coding surface for turning trained models into product-facing software components.",
"slug": "programming-languages-for-ml-systems",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Test Automation",
"id": 193,
"rationale": "Languages used to implement automated checks, helper utilities, and test harness code. This is the core coding surface for turning test ideas into maintainable automation.",
"slug": "programming-languages-for-test-automation",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Security Automation and Scripting",
"id": 258,
"rationale": "Automating repeatable security checks, enrichment, and remediation workflows. This cluster is coherent because the role often needs lightweight automation to scale analysis and response.",
"slug": "security-automation-and-scripting",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cybersecurity Engineer",
"id": 9,
"rationale": null,
"role_archetype": null,
"slug": "cybersecurity-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Grafana",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"input_skill": "Grafana",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Containerization and Image Delivery",
"id": 24,
"rationale": "Builds, packages, and ships application and support workloads as container images. This cluster covers the artifact format and the mechanics of producing deployable images.",
"slug": "containerization-and-image-delivery",
"source": "db"
},
"input_skill": "Docker",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Model Serving Deployment and Runtime Packaging",
"id": 52,
"rationale": "Operational deployment of trained models into online, batch, or streaming serving environments, including packaging models and model servers into containers or managed inference runtimes, coordinating rollout, and handing off to inference systems. Covers serving frameworks and platforms such as TensorFlow Serving, TorchServe, Triton Inference Server, BentoML, KServe, and Seldon Core, plus container/runtime concerns like Docker images, GPU-enabled containers, base image selection, container entrypoints, runtime dependencies, and image scanning for model services.",
"slug": "model-serving-deployment-and-runtime-packaging",
"source": "db"
},
"input_skill": "Docker",
"llm_role": null,
"roles_from_db": [
{
"display_name": "MLOps Engineer",
"id": 5,
"rationale": null,
"role_archetype": null,
"slug": "mlops-engineer",
"source": "db"
},
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Prometheus",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"input_skill": "Prometheus",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"input_skill": "Azure",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "GitHub Actions",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Messaging and Event Streaming",
"id": 146,
"rationale": "Asynchronous communication patterns and systems for decoupled service interaction and background processing. This is a coherent backend cluster because many server-side workflows depend on queues, topics, and event streams.",
"slug": "messaging-and-event-streaming",
"source": "db"
},
"input_skill": "Kafka",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"input_skill": "AWS",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Continuous Integration",
"id": null,
"rationale": "Practices and tooling for automatically building, testing, and validating code changes on every commit or pull request. CI belongs here because it is the core automation layer that keeps changes integrated and feedback fast in DevOps workflows.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "CI",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Build and Test Automation",
"id": null,
"rationale": "Automation that compiles code and runs verification steps as part of a repeatable delivery pipeline. This fits CI when the emphasis is on the automated build-and-test mechanics rather than broader release management.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "CI",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "General Programming Code",
"id": null,
"rationale": "Writing executable code in a general-purpose programming language to implement logic, transformations, and control flow. The target skill belongs here because it is the broad act of coding when no narrower language- or framework-specific dimension is intended.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Code",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Log Aggregation and Search",
"id": null,
"rationale": "Covers centralized collection, indexing, search, and analysis of logs for troubleshooting and operational visibility. ELK belongs here because it is commonly used as the stack for ingesting, storing, querying, and visualizing machine logs.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "ELK",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Exposure Management",
"id": null,
"rationale": "Covers controlling how systems, services, and endpoints are exposed to networks, users, and external traffic. This skill fits here when it refers to limiting or shaping what is reachable from outside the host or cluster.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Exposure",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Infrastructure Engineering",
"id": null,
"rationale": "Covers the design, provisioning, and operation of compute, network, storage, and platform foundations that applications run on. This is the best fit for the broad skill \"Infrastructure\" in a DevOps context because it refers to the underlying environment rather than a single specialized subdomain.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Infrastructure",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Domain Knowledge",
"id": null,
"rationale": "General understanding of the business, product, or technical domain that informs decisions and communication. This skill belongs here when it refers to knowing the relevant subject matter rather than a specific tool, process, or implementation technique.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Knowledge",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Linux System Administration",
"id": null,
"rationale": "Operating and troubleshooting Linux hosts used for servers, build agents, and cloud workloads. This skill belongs here because Linux is the core OS layer for managing users, processes, filesystems, services, and command-line operations.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Linux",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Operational Monitoring",
"id": null,
"rationale": "Monitoring covers checking system, service, and infrastructure health through metrics, logs, alerts, and status signals. The skill fits here because it involves continuously watching for abnormal conditions and confirming systems are behaving as expected.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Monitor",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Site Reliability Engineering",
"id": null,
"rationale": "Practices for operating production systems with high availability, observability, and safe change management. This is the broader home for SRE as a discipline, covering reliability engineering beyond a single incident.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "SRE",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "General Automation Scripting",
"id": null,
"rationale": "Writing scripts to automate repetitive operational tasks, glue systems together, and reduce manual toil. This fits Scripting when the work is cross-cutting automation rather than a domain-specific implementation area.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "Scripting",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Technical Understanding and Comprehension",
"id": null,
"rationale": "Ability to understand technical concepts, system behavior, and operational context well enough to make correct decisions. This skill is broad and foundational, so it does not map cleanly to a narrower catalog dimension.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Understanding",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Requirements Comprehension",
"id": null,
"rationale": "Understanding what a system, process, or change is supposed to do from requirements, acceptance criteria, and stakeholder descriptions. This fits when the skill is about interpreting expected behavior rather than implementing or testing it.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "Understanding",
"llm_role": null,
"roles_from_db": []
}
],
"input_final_skills": [
"Disaster Recovery",
"Redis",
"Datadog",
"Load Balancing",
"Bash",
"Ansible",
"Kubernetes",
"shell scripting",
"Microservices",
"Terraform",
"CloudFormation",
"Jenkins",
"GitLab CI",
"Python",
"Grafana",
"Docker",
"Prometheus",
"Azure",
"GitHub Actions",
"Kafka",
"AWS",
"CI",
"Cloud",
"Code",
"ELK",
"Exposure",
"Infrastructure",
"Knowledge",
"Linux",
"Monitor",
"QA",
"SRE",
"Scripting",
"Understanding",
"access",
"administration",
"applications",
"architectures",
"balancing",
"build",
"configuration",
"container",
"control",
"deployment",
"development",
"disaster",
"efficiency",
"environment",
"environments",
"incident",
"issues",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"security",
"strategies",
"system",
"systems",
"test",
"tools"
],
"input_llm_skills": [
"CI",
"Cloud",
"Code",
"ELK",
"Exposure",
"Infrastructure",
"Knowledge",
"Linux",
"Monitor",
"QA",
"SRE",
"Scripting",
"Understanding",
"access",
"administration",
"applications",
"architectures",
"balancing",
"build",
"configuration",
"container",
"control",
"deployment",
"development",
"disaster",
"efficiency",
"environment",
"environments",
"incident",
"issues",
"load",
"management",
"mechanisms",
"message",
"monitoring",
"networking",
"observability",
"orchestration",
"performance",
"pipelines",
"platforms",
"practices",
"processes",
"production",
"provisioning",
"queue",
"recovery",
"release",
"scaling",
"scanning",
"security",
"strategies",
"system",
"systems",
"test",
"tools"
],
"new_aliases_persisted": 0,
"run_id": "c123e6af-1ee0-46fc-ac24-3514f0fbd8fb",
"skills_detail": [
{
"aliases_in_db": [
{
"alias_text": "Disaster Recovery",
"alias_type": "CANONICAL",
"id": 479,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 16,
"display_name": "Disaster Recovery",
"id": 278,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "CONCEPT",
"slug": "disaster-recovery",
"sub_category_id": 212,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Backup and Disaster Recovery",
"id": 51,
"rationale": "Plans and operates backup, restore, and disaster recovery capabilities for Azure environments. This is a distinct cluster because recovery objectives and restore mechanics are specialized operational skills.",
"slug": "backup-and-disaster-recovery",
"source": "db"
},
"input_skill": "Disaster Recovery",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
}
],
"input_skill": "Disaster Recovery",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Redis",
"alias_type": "CANONICAL",
"id": 1278,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 12,
"display_name": "Redis",
"id": 846,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "redis",
"sub_category_id": 701,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "NoSQL and Cache Stores",
"id": 145,
"rationale": "Non-relational databases and in-memory stores used for low-latency access, flexible schemas, and specialized persistence patterns. This cluster is coherent because backend services often combine these stores with relational systems.",
"slug": "nosql-and-cache-stores",
"source": "db"
},
"input_skill": "Redis",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
}
],
"input_skill": "Redis",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Datadog",
"alias_type": "CANONICAL",
"id": 356,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 13,
"display_name": "Datadog",
"id": 171,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PLATFORM",
"slug": "datadog",
"sub_category_id": 162,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Datadog",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
}
],
"input_skill": "Datadog",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Load Balancing",
"alias_type": "CANONICAL",
"id": 476,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 2,
"display_name": "Load Balancing",
"id": 275,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "CONCEPT",
"slug": "load-balancing",
"sub_category_id": 211,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Scaling and Resilience Engineering",
"id": 45,
"rationale": "Implements Azure-side patterns that improve availability, capacity, and fault tolerance. This is a coherent cluster because the role must keep environments ready for production load and failure scenarios.",
"slug": "scaling-and-resilience-engineering",
"source": "db"
},
"input_skill": "Load Balancing",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
}
],
"input_skill": "Load Balancing",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Shell Scripts",
"alias_type": "CANONICAL",
"id": 1788,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Bash",
"alias_type": "VERSION",
"id": 1793,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Bourne shell",
"alias_type": "VERSION",
"id": 1798,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "POSIX shell",
"alias_type": "VERSION",
"id": 1797,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "bash",
"alias_type": "VERSION",
"id": 1794,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "csh",
"alias_type": "VERSION",
"id": 1790,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "ksh",
"alias_type": "VERSION",
"id": 1791,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "sh",
"alias_type": "VERSION",
"id": 1789,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "shell",
"alias_type": "VERSION",
"id": 1796,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "tcsh",
"alias_type": "VERSION",
"id": 1795,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "zsh",
"alias_type": "VERSION",
"id": 1792,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 5,
"display_name": "Shell Scripts",
"id": 1248,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "LANGUAGE",
"slug": "shell-scripts",
"sub_category_id": 145,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Build and Execution Tooling",
"id": 206,
"rationale": "Command-line and build tools used to run, package, and integrate automated tests into developer workflows. This cluster is coherent because automation testers often need to wire tests into local and shared execution paths.",
"slug": "build-and-execution-tooling",
"source": "db"
},
"input_skill": "Bash",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
}
],
"input_skill": "Bash",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Ansible",
"alias_type": "CANONICAL",
"id": 293,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "Ansible",
"id": 147,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "ansible",
"sub_category_id": 1471,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Configuration Management",
"id": 23,
"rationale": "Manages environment-specific settings, secrets wiring, and standardized runtime configuration across services. It is distinct from infrastructure provisioning because it focuses on how software is parameterized at deploy time.",
"slug": "configuration-management",
"source": "db"
},
"input_skill": "Ansible",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"input_skill": "Ansible",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
]
}
],
"input_skill": "Ansible",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Kubernetes",
"alias_type": "CANONICAL",
"id": 304,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.0",
"alias_type": "VERSION",
"id": 307,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.0+",
"alias_type": "VERSION",
"id": 2366,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.1",
"alias_type": "VERSION",
"id": 308,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.10",
"alias_type": "VERSION",
"id": 318,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.11",
"alias_type": "VERSION",
"id": 319,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.12",
"alias_type": "VERSION",
"id": 320,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.13",
"alias_type": "VERSION",
"id": 321,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.14",
"alias_type": "VERSION",
"id": 322,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.15",
"alias_type": "VERSION",
"id": 323,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.16",
"alias_type": "VERSION",
"id": 324,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.17",
"alias_type": "VERSION",
"id": 325,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.18",
"alias_type": "VERSION",
"id": 326,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.19",
"alias_type": "VERSION",
"id": 327,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.2",
"alias_type": "VERSION",
"id": 309,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.20",
"alias_type": "VERSION",
"id": 328,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.21",
"alias_type": "VERSION",
"id": 329,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.22",
"alias_type": "VERSION",
"id": 330,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.23",
"alias_type": "VERSION",
"id": 331,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.24",
"alias_type": "VERSION",
"id": 332,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.25",
"alias_type": "VERSION",
"id": 333,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.26",
"alias_type": "VERSION",
"id": 334,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.27",
"alias_type": "VERSION",
"id": 335,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.28",
"alias_type": "VERSION",
"id": 336,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.29",
"alias_type": "VERSION",
"id": 337,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.3",
"alias_type": "VERSION",
"id": 310,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.30",
"alias_type": "VERSION",
"id": 338,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.4",
"alias_type": "VERSION",
"id": 311,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.5",
"alias_type": "VERSION",
"id": 312,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.6",
"alias_type": "VERSION",
"id": 313,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.7",
"alias_type": "VERSION",
"id": 314,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.8",
"alias_type": "VERSION",
"id": 315,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.9",
"alias_type": "VERSION",
"id": 316,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes 1.x",
"alias_type": "VERSION",
"id": 317,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kubernetes v1",
"alias_type": "VERSION",
"id": 306,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "k8s",
"alias_type": "VERSION",
"id": 305,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 13,
"display_name": "Kubernetes",
"id": 158,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PLATFORM",
"slug": "kubernetes",
"sub_category_id": 1524,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Orchestration Platforms",
"id": 25,
"rationale": "Operates the platforms that schedule and run containerized workloads and related deployment primitives. This is separate from image delivery because it concerns runtime placement and service rollout behavior.",
"slug": "orchestration-platforms",
"source": "db"
},
"input_skill": "Kubernetes",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
},
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
}
],
"input_skill": "Kubernetes",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "shell scripting",
"alias_type": "CANONICAL",
"id": 847,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 5,
"display_name": "shell scripting",
"id": 549,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "LANGUAGE",
"slug": "shell-scripting",
"sub_category_id": 145,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming for Data Automation",
"id": 93,
"rationale": "Lightweight scripting used to automate repetitive analysis tasks, data preparation, and report generation. This is a useful split because data scientists often need practical automation without owning full pipelines.",
"slug": "programming-for-data-automation",
"source": "db"
},
"input_skill": "shell scripting",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
]
}
],
"input_skill": "shell scripting",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Microservices",
"alias_type": "CANONICAL",
"id": 1307,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 1,
"display_name": "Microservices",
"id": 864,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PATTERN",
"slug": "microservices",
"sub_category_id": 663,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Service Architecture and Integration",
"id": 148,
"rationale": "Patterns for structuring backend systems as services and coordinating calls across internal and external dependencies. This includes how services are decomposed, connected, and evolved safely.",
"slug": "service-architecture-and-integration",
"source": "db"
},
"input_skill": "Microservices",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
}
],
"input_skill": "Microservices",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Terraform",
"alias_type": "CANONICAL",
"id": 290,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "Terraform",
"id": 144,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "terraform",
"sub_category_id": 171,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure Provisioning Templates",
"id": 291,
"rationale": "Declarative templates and modules used to create repeatable cloud resources and environments. This cluster covers the infrastructure definitions the role applies, reviews, and updates to keep environments consistent.",
"slug": "infrastructure-provisioning-templates",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code and Declarative Provisioning",
"id": 36,
"rationale": "Defines cloud and platform infrastructure declaratively through versioned code so environments are repeatable, reviewable, and automatable. This includes authoring and maintaining IaC templates/modules, managing parameters and state, and using plan/apply workflows to provision and update resources across Azure and other cloud platforms.",
"slug": "infrastructure-as-code-and-declarative-provisioning",
"source": "db"
},
"input_skill": "Terraform",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
]
}
],
"input_skill": "Terraform",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "CloudFormation",
"alias_type": "CANONICAL",
"id": 291,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "CloudFormation",
"id": 145,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "cloudformation",
"sub_category_id": 171,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"input_skill": "CloudFormation",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
}
],
"input_skill": "CloudFormation",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Jenkins",
"alias_type": "CANONICAL",
"id": 1799,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "Jenkins",
"id": 1249,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "jenkins",
"sub_category_id": 166,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "Jenkins",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
}
],
"input_skill": "Jenkins",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "GitLab CI",
"alias_type": "CANONICAL",
"id": 1801,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 14,
"display_name": "GitLab CI",
"id": 1251,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "CLOUD_SERVICE",
"slug": "gitlab-ci",
"sub_category_id": 1019,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "GitLab CI",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
}
],
"input_skill": "GitLab CI",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Python",
"alias_type": "CANONICAL",
"id": 608,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 2",
"alias_type": "VERSION",
"id": 611,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 2.x",
"alias_type": "VERSION",
"id": 613,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 3",
"alias_type": "VERSION",
"id": 612,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 3.10",
"alias_type": "VERSION",
"id": 2330,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 3.11",
"alias_type": "VERSION",
"id": 2331,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 3.12",
"alias_type": "VERSION",
"id": 2332,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Python 3.x",
"alias_type": "VERSION",
"id": 614,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "py2",
"alias_type": "VERSION",
"id": 609,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "py3",
"alias_type": "VERSION",
"id": 610,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 2",
"alias_type": "VERSION",
"id": 2152,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 2.x",
"alias_type": "VERSION",
"id": 2154,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 3",
"alias_type": "VERSION",
"id": 990,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 3.10",
"alias_type": "VERSION",
"id": 992,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 3.11",
"alias_type": "VERSION",
"id": 993,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 3.12",
"alias_type": "VERSION",
"id": 994,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python 3.x",
"alias_type": "VERSION",
"id": 991,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python2",
"alias_type": "VERSION",
"id": 2150,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "python3",
"alias_type": "VERSION",
"id": 989,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 5,
"display_name": "Python",
"id": 393,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "LANGUAGE",
"slug": "python",
"sub_category_id": 54,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Analytical Programming Languages",
"id": 82,
"rationale": "Languages used to clean, transform, analyze, and prototype models in notebooks and scripts. This is the core coding surface for expressing statistical logic and data manipulation in a reproducible way.",
"slug": "analytical-programming-languages",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Analyst",
"id": 20,
"rationale": null,
"role_archetype": null,
"slug": "data-analyst",
"source": "db"
},
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Automation Scripting and CLI",
"id": 48,
"rationale": "Uses scripts and command-line tooling to execute repeatable Azure operations and reduce manual work. This is a practical cluster because the role frequently automates provisioning, checks, and remediation tasks.",
"slug": "automation-scripting-and-cli",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
},
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for AI Workflows",
"id": 261,
"rationale": "Languages used to implement AI feature logic, orchestration, and response handling inside product code. This is the core coding surface for turning prompts and model calls into reliable application behavior.",
"slug": "programming-languages-for-ai-workflows",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "AI Engineer",
"id": 12,
"rationale": null,
"role_archetype": null,
"slug": "ai-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Backend Systems",
"id": 140,
"rationale": "Languages used to implement server-side business logic, request handlers, workers, and service integrations. This is the core coding surface for backend feature delivery and maintenance.",
"slug": "programming-languages-for-backend-systems",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Data Work",
"id": 67,
"rationale": "Languages used to implement data pipelines, transformations, and operational utilities. This is the code layer for expressing extraction, parsing, validation, and orchestration logic in data engineering workflows.",
"slug": "programming-languages-for-data-work",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Data Engineer",
"id": 6,
"rationale": null,
"role_archetype": null,
"slug": "data-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for ML Systems",
"id": 113,
"rationale": "Languages used to implement model integration code, inference services, and feature-processing logic. This is the core coding surface for turning trained models into product-facing software components.",
"slug": "programming-languages-for-ml-systems",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Test Automation",
"id": 193,
"rationale": "Languages used to implement automated checks, helper utilities, and test harness code. This is the core coding surface for turning test ideas into maintainable automation.",
"slug": "programming-languages-for-test-automation",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Security Automation and Scripting",
"id": 258,
"rationale": "Automating repeatable security checks, enrichment, and remediation workflows. This cluster is coherent because the role often needs lightweight automation to scale analysis and response.",
"slug": "security-automation-and-scripting",
"source": "db"
},
"input_skill": "Python",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Cybersecurity Engineer",
"id": 9,
"rationale": null,
"role_archetype": null,
"slug": "cybersecurity-engineer",
"source": "db"
}
]
}
],
"input_skill": "Python",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Grafana",
"alias_type": "CANONICAL",
"id": 354,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "Grafana",
"id": 169,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "grafana",
"sub_category_id": 331,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Grafana",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"input_skill": "Grafana",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
}
],
"input_skill": "Grafana",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Docker",
"alias_type": "CANONICAL",
"id": 299,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 11,
"display_name": "Docker",
"id": 153,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "docker",
"sub_category_id": 170,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Containerization and Image Delivery",
"id": 24,
"rationale": "Builds, packages, and ships application and support workloads as container images. This cluster covers the artifact format and the mechanics of producing deployable images.",
"slug": "containerization-and-image-delivery",
"source": "db"
},
"input_skill": "Docker",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Model Serving Deployment and Runtime Packaging",
"id": 52,
"rationale": "Operational deployment of trained models into online, batch, or streaming serving environments, including packaging models and model servers into containers or managed inference runtimes, coordinating rollout, and handing off to inference systems. Covers serving frameworks and platforms such as TensorFlow Serving, TorchServe, Triton Inference Server, BentoML, KServe, and Seldon Core, plus container/runtime concerns like Docker images, GPU-enabled containers, base image selection, container entrypoints, runtime dependencies, and image scanning for model services.",
"slug": "model-serving-deployment-and-runtime-packaging",
"source": "db"
},
"input_skill": "Docker",
"llm_role": null,
"roles_from_db": [
{
"display_name": "MLOps Engineer",
"id": 5,
"rationale": null,
"role_archetype": null,
"slug": "mlops-engineer",
"source": "db"
},
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
]
}
],
"input_skill": "Docker",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Prometheus",
"alias_type": "CANONICAL",
"id": 353,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 13,
"display_name": "Prometheus",
"id": 168,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PLATFORM",
"slug": "prometheus",
"sub_category_id": 729,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"input_skill": "Prometheus",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
},
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"input_skill": "Prometheus",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
}
],
"input_skill": "Prometheus",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Azure",
"alias_type": "CANONICAL",
"id": 349,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 13,
"display_name": "Azure",
"id": 164,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PLATFORM",
"slug": "azure",
"sub_category_id": 161,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"input_skill": "Azure",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
}
],
"input_skill": "Azure",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "GitHub Actions",
"alias_type": "CANONICAL",
"id": 1800,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 14,
"display_name": "GitHub Actions",
"id": 1250,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "CLOUD_SERVICE",
"slug": "github-actions",
"sub_category_id": 1019,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"input_skill": "GitHub Actions",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
]
}
],
"input_skill": "GitHub Actions",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "Apache Kafka",
"alias_type": "VERSION",
"id": 1295,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka",
"alias_type": "VERSION",
"id": 1284,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3",
"alias_type": "VERSION",
"id": 1286,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.0",
"alias_type": "VERSION",
"id": 1287,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.1",
"alias_type": "VERSION",
"id": 1288,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.2",
"alias_type": "VERSION",
"id": 1289,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.3",
"alias_type": "VERSION",
"id": 1290,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.4",
"alias_type": "VERSION",
"id": 1291,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.5",
"alias_type": "VERSION",
"id": 1292,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.6",
"alias_type": "VERSION",
"id": 1293,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
},
{
"alias_text": "Kafka 3.x",
"alias_type": "VERSION",
"id": 1294,
"is_primary": false,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 12,
"display_name": "Kafka",
"id": 852,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "TOOL",
"slug": "kafka",
"sub_category_id": 700,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Messaging and Event Streaming",
"id": 146,
"rationale": "Asynchronous communication patterns and systems for decoupled service interaction and background processing. This is a coherent backend cluster because many server-side workflows depend on queues, topics, and event streams.",
"slug": "messaging-and-event-streaming",
"source": "db"
},
"input_skill": "Kafka",
"llm_role": null,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
]
}
],
"input_skill": "Kafka",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [
{
"alias_text": "AWS",
"alias_type": "CANONICAL",
"id": 348,
"is_primary": true,
"match_strategy": "CASE_INSENSITIVE"
}
],
"canonical": {
"category_id": 13,
"display_name": "AWS",
"id": 163,
"is_also_category": false,
"is_extractable": true,
"skill_nature": "PLATFORM",
"slug": "aws",
"sub_category_id": 161,
"typical_lifespan": "EVERGREEN",
"volatility": "STABLE"
},
"dimensions": [
{
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"input_skill": "AWS",
"llm_role": null,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
]
}
],
"input_skill": "AWS",
"matched_via": "alias",
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "db",
"was_in_llm_skills": false
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Continuous Integration",
"id": null,
"rationale": "Practices and tooling for automatically building, testing, and validating code changes on every commit or pull request. CI belongs here because it is the core automation layer that keeps changes integrated and feedback fast in DevOps workflows.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "CI",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Build and Test Automation",
"id": null,
"rationale": "Automation that compiles code and runs verification steps as part of a repeatable delivery pipeline. This fits CI when the emphasis is on the automated build-and-test mechanics rather than broader release management.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "CI",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "CI",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Methodology",
"skill_nature": "METHODOLOGY",
"sub_category": "continuous_integration",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"continuous_delivery",
"continuous_deployment"
],
"reasoning": "\"CI\" is a common abbreviation for continuous integration, but in JDs it can be conflated with nearby DevOps terms like continuous delivery or continuous deployment, especially when shorthand is used loosely."
},
"context_keywords": {
"context_keywords": [
"Jenkins",
"GitHub Actions",
"GitLab CI",
"CircleCI",
"Travis CI",
"build pipeline",
"automated testing",
"unit tests",
"integration tests",
"pipeline as code",
"YAML",
"artifact",
"merge request",
"pull request",
"build status"
]
},
"maturity": {
"confidence": 0.95,
"maturity": "well_known",
"reasoning": "Continuous Integration is a standard requirement in many software JDs and is built into major platforms like GitHub Actions, GitLab CI, and Jenkins, indicating broad hiring-market adoption."
},
"skill_id": "ci",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Practices and tooling for automatically building, testing, and validating code changes on every commit or pull request. CI belongs here because it is the core automation layer that keeps changes integrated and feedback fast in DevOps workflows.",
"exemplar_skills": [
"CI",
"continuous integration",
"build pipelines",
"pull request checks",
"automated build validation",
"pipeline status checks"
],
"in_scope": "CI, continuous integration, build triggers, pull request checks, automated builds, unit test execution, integration test execution, linting, static analysis, pipeline status checks",
"name": "Continuous Integration",
"out_of_scope": "Continuous delivery and deployment orchestration, release approval workflows, infrastructure provisioning, test framework implementation, incident response and remediation",
"overlap_flags": [
{
"reason": "CI pipelines often need upkeep and refactoring, but that dimension focuses on maintaining automation quality rather than the integration practice itself.",
"with_dim_id": "automation-maintenance-and-refactoring",
"with_dim_name": null,
"with_role": null
},
{
"reason": "CI commonly runs frontend tests, but that dimension owns the test design and quality techniques rather than the pipeline orchestration.",
"with_dim_id": "frontend-testing-and-quality",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
},
{
"description": "Automation that compiles code and runs verification steps as part of a repeatable delivery pipeline. This fits CI when the emphasis is on the automated build-and-test mechanics rather than broader release management.",
"exemplar_skills": [
"CI",
"automated builds",
"pipeline validation",
"artifact generation",
"static analysis in CI",
"pre-merge checks"
],
"in_scope": "CI, automated builds, test automation in pipelines, linting, static analysis, artifact generation, build verification, smoke tests, pre-merge validation",
"name": "Build and Test Automation",
"out_of_scope": "Release packaging and signing, deployment orchestration, environment provisioning, manual QA acceptance testing, production incident handling",
"overlap_flags": [
{
"reason": "Build configuration and release owns packaging/signing/release preparation, while this dimension focuses on the automated verification loop.",
"with_dim_id": "build-configuration-and-release",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Acceptance validation checks business requirements, whereas CI validates code health and integration correctness.",
"with_dim_id": "requirements-and-acceptance-validation",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_02"
}
],
"merge_log": [],
"placed": {
"name": "CI",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 2 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [
"d_init_02"
],
"skill_id": "ci"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"junit",
"confidence-intervals",
"confidence-thresholds",
"http"
],
"requires": [],
"skill_id": "ci",
"suppress_on_match": []
},
"skill_id": "ci",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.92,
"name": "CI",
"reasoning": "CI is fundamentally a way of working for integrating changes frequently and validating them continuously, so by the Concept vs Methodology rule it is a Methodology rather than a tool or platform.",
"skill_id": "ci",
"subtype": "continuous_integration",
"type": "Methodology"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "Cloud",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Domain",
"skill_nature": "CONCEPT",
"sub_category": "cloud_computing",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"cloud_computing"
],
"reasoning": "\"Cloud\" is a broad shorthand that in JDs can mean cloud computing, but also cloud storage, cloud services, or even non-technical cloud contexts. It could be confused with the more specific cloud_computing skill."
},
"context_keywords": {
"context_keywords": [
"AWS",
"Azure",
"Google Cloud",
"GCP",
"IaaS",
"PaaS",
"SaaS",
"Kubernetes",
"Docker",
"serverless",
"Terraform",
"cloud migration",
"multi-cloud",
"hybrid cloud",
"load balancer"
]
},
"maturity": {
"confidence": 0.98,
"maturity": "well_known",
"reasoning": "Cloud computing is a hiring-pipeline staple: AWS, Azure, and GCP appear in a large share of modern infrastructure JDs, and major vendors continue expanding cloud services rather than sunsetting them."
},
"skill_id": "cloud",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [],
"merge_log": [
{
"into": "d_merge_01",
"into_name": "Cloud Platform Fundamentals and Service Selection",
"merged_from": [
"d_init_01",
"cloud-platform-service-selection"
],
"reasoning": "Both dims describe the same broad cloud-platform cluster. Dim A covers core cloud concepts and managed services (Cloud, AWS/Azure/GCP, managed compute/storage/databases, serverless, autoscaling, load balancing). Dim B narrows to selecting managed cloud services and primitives based on workload tradeoffs, which is already implied by A\u2019s \u201cprovider capabilities\u201d and \u201cmanaged services\u201d scope. The exemplar skills overlap on serverless and managed cloud services, so this is one conceptual skill area."
}
],
"placed": {
"name": "Cloud",
"placement_confidence": 0.0,
"primary_dimension": "d_init_00",
"reasoning": "Stub placement: no locked_dimensions after Stage 2/3; downstream containment and enrichment use placeholders only.",
"secondary_dimensions": [],
"skill_id": "cloud"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"cloud-run",
"cloud-reference-architecture",
"azure-backup",
"aws-s3",
"aws-cloudformation",
"azure-monitor",
"kubernetes",
"ec2",
"aws-organizations",
"aws-direct-connect",
"aws-vpc",
"google-cloud-iam",
"azure-virtual-machines",
"aws-migration-hub",
"json",
"livedata",
"http",
"aws-iam",
"azure-expressroute",
"protobuf"
],
"requires": [],
"skill_id": "cloud",
"suppress_on_match": []
},
"skill_id": "cloud",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.93,
"name": "Cloud",
"reasoning": "Cloud is best treated as a Domain because it names a broad vertical/body of knowledge about cloud computing rather than a specific platform, service, tool, or architecture.",
"skill_id": "cloud",
"subtype": "cloud_computing",
"type": "Domain"
},
"warnings": [
"placement_stub_no_locked_dimensions"
]
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "General Programming Code",
"id": null,
"rationale": "Writing executable code in a general-purpose programming language to implement logic, transformations, and control flow. The target skill belongs here because it is the broad act of coding when no narrower language- or framework-specific dimension is intended.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Code",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Code",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Language",
"skill_nature": "LANGUAGE",
"sub_category": "programming_language",
"typical_lifespan": "EVERGREEN",
"version_strategy": "SEPARATE_ENTITY",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"code_review",
"source_code"
],
"reasoning": "\"Code\" is highly overloaded in JDs and can mean source code or code review rather than the programming language; a reasonable extractor could confuse it with these catalog skills."
},
"context_keywords": {
"context_keywords": [
"syntax",
"compiler",
"interpreter",
"debugging",
"unit tests",
"version control",
"Git",
"IDE",
"refactoring",
"code review",
"build scripts",
"CI/CD",
"linting",
"static analysis"
]
},
"maturity": {
"confidence": 0.97,
"maturity": "well_known",
"reasoning": "General-purpose coding is a hiring-pipeline staple across nearly all software JDs; it underpins mainstream languages and platforms rather than a niche or sunset tool."
},
"skill_id": "code",
"vendor_license": {
"confidence": 0.98,
"license": "other_open",
"vendor": "Guido van Rossum",
"year_introduced": 1991
},
"versioning": {
"current_version": "3",
"version_aliases": {
"Python 2": "2",
"Python 2.x": "2",
"Python 3": "3",
"Python 3.10": "3.10",
"Python 3.11": "3.11",
"Python 3.12": "3.12",
"Python 3.x": "3",
"py2": "2",
"py3": "3"
},
"versioned": true
}
},
"locked_dimensions": [
{
"description": "Writing executable code in a general-purpose programming language to implement logic, transformations, and control flow. The target skill belongs here because it is the broad act of coding when no narrower language- or framework-specific dimension is intended.",
"exemplar_skills": [
"Code",
"Programming",
"Scripting",
"Writing functions",
"Implementing business logic",
"Refactoring code"
],
"in_scope": "Code, writing functions and classes, control flow, data structures, basic algorithms, scripting, refactoring, syntax, debugging simple code issues",
"name": "General Programming Code",
"out_of_scope": "test automation code, infrastructure-as-code, database queries, UI markup and styling, security automation scripts",
"overlap_flags": [
{
"reason": "Backend implementation is a common context for code, but that dimension is narrower and owns server-side language usage.",
"with_dim_id": "programming-languages-for-backend-systems",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Automated test code is still code, but that dimension specifically covers coding for test harnesses and checks.",
"with_dim_id": "programming-languages-for-test-automation",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Code",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "code"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"java",
"javascript",
"typescript",
"python",
"kotlin",
"bash",
"c"
],
"requires": [],
"skill_id": "code",
"suppress_on_match": []
},
"skill_id": "code",
"split_log": [],
"typed": {
"alternatives_considered": [
"Concept: ruled out \u2014 although \"code\" can mean the general notion of source code, the input is most naturally a language label.",
"Tool: ruled out \u2014 it is not software you operate as a user."
],
"confidence": 0.88,
"name": "Code",
"reasoning": "Code is best treated as a programming language in the closed typology because it refers to the language used to write software rather than a tool or framework.",
"skill_id": "code",
"subtype": "programming_language",
"type": "Language"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Log Aggregation and Search",
"id": null,
"rationale": "Covers centralized collection, indexing, search, and analysis of logs for troubleshooting and operational visibility. ELK belongs here because it is commonly used as the stack for ingesting, storing, querying, and visualizing machine logs.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "ELK",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "ELK",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Tool",
"skill_nature": "TOOL",
"sub_category": "log_analysis_stack",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"elastic_stack",
"elk_stack"
],
"reasoning": "ELK is a common shorthand for the Elastic Stack, but in JDs it can also be read as the elk animal or other ELK-branded tools. A reasonable extractor could confuse the stack name with related catalog entries."
},
"context_keywords": {
"context_keywords": [
"Elasticsearch",
"Logstash",
"Kibana",
"Beats",
"Filebeat",
"Metricbeat",
"Apm Server",
"Lucene",
"index patterns",
"dashboards",
"ingest pipelines",
"Groovy",
"JSON logs",
"log aggregation",
"SIEM"
]
},
"maturity": {
"confidence": 0.93,
"maturity": "well_known",
"reasoning": "ELK (Elasticsearch, Logstash, Kibana) appears frequently in DevOps/SRE job descriptions and is a standard observability stack across many enterprises, with strong vendor and community adoption."
},
"skill_id": "elk",
"vendor_license": {
"confidence": 0.9,
"license": "apache_2",
"vendor": "Elastic",
"year_introduced": 2010
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Covers centralized collection, indexing, search, and analysis of logs for troubleshooting and operational visibility. ELK belongs here because it is commonly used as the stack for ingesting, storing, querying, and visualizing machine logs.",
"exemplar_skills": [
"ELK",
"Elasticsearch",
"Logstash",
"Kibana",
"centralized logging",
"log analytics",
"log search"
],
"in_scope": "ELK, Elasticsearch log indexing, Logstash ingestion pipelines, Kibana log search, centralized application logs, structured logging, log retention, log querying, log dashboards",
"name": "Log Aggregation and Search",
"out_of_scope": "Metrics-only monitoring such as Prometheus/Grafana, distributed tracing platforms, SIEM-specific security analytics, application performance tuning unrelated to log search",
"overlap_flags": [
{
"reason": "Log search and dashboards often support outage triage and remediation workflows.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Kibana dashboards can overlap with general operational reporting and visualization.",
"with_dim_id": "reporting-and-dashboard-configuration",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "ELK",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "elk"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"dashboards",
"json"
],
"requires": [],
"skill_id": "elk",
"suppress_on_match": []
},
"skill_id": "elk",
"split_log": [],
"typed": {
"alternatives_considered": [
"Platform: ruled out \u2014 ELK is usually software you run yourself, not a hosted multi-tenant environment with managed APIs.",
"Framework: ruled out \u2014 it is not primarily a codebase you build applications inside.",
"Datastore: ruled out \u2014 only Elasticsearch is a datastore component, while ELK as a whole is a stack/tooling suite."
],
"confidence": 0.78,
"name": "ELK",
"reasoning": "By the Tool vs Framework rule, ELK is typically a self-hosted software stack (Elasticsearch, Logstash, Kibana) that users operate rather than a hosted multi-tenant platform or a code framework.",
"skill_id": "elk",
"subtype": "log_analysis_stack",
"type": "Tool"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Exposure Management",
"id": null,
"rationale": "Covers controlling how systems, services, and endpoints are exposed to networks, users, and external traffic. This skill fits here when it refers to limiting or shaping what is reachable from outside the host or cluster.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Exposure",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Exposure",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Concept",
"skill_nature": "CONCEPT",
"sub_category": "risk_exposure",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"risk_exposure"
],
"reasoning": "\u201cExposure\u201d is a generic term in JDs and could refer to risk exposure, which is a distinct catalog skill. A mention like \u201cexposure management\u201d or \u201cexposure analysis\u201d may be misread as this concept."
},
"context_keywords": {
"context_keywords": [
"counterparty risk",
"market risk",
"credit risk",
"VaR",
"stress testing",
"scenario analysis",
"hedging",
"derivatives",
"notional",
"duration",
"sensitivity analysis",
"portfolio exposure",
"limit monitoring",
"risk limits",
"concentration risk"
]
},
"maturity": {
"confidence": 0.84,
"maturity": "niche",
"reasoning": "Job postings rarely list \"exposure\" as a standalone skill; it appears mainly in risk, insurance, and finance roles, while broader market demand is for specific frameworks like VaR or credit risk models."
},
"skill_id": "exposure",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Covers controlling how systems, services, and endpoints are exposed to networks, users, and external traffic. This skill fits here when it refers to limiting or shaping what is reachable from outside the host or cluster.",
"exemplar_skills": [
"Exposure",
"service exposure",
"port exposure",
"endpoint exposure",
"ingress exposure",
"public exposure"
],
"in_scope": "Exposure, public exposure, service exposure, port exposure, endpoint exposure, ingress exposure, load balancer exposure, firewall exposure, Kubernetes service exposure, network surface reduction",
"name": "Exposure Management",
"out_of_scope": "Secrets storage and rotation, certificate lifecycle, user authentication, authorization policy, incident response, application logging, data quality checks",
"overlap_flags": [
{
"reason": "Exposure settings often interact with perimeter controls such as firewalls and security appliances.",
"with_dim_id": "network-security-appliances",
"with_dim_name": null,
"with_role": null
},
{
"reason": "If exposure refers to storage reachability, it may overlap with storage connectivity and access paths.",
"with_dim_id": "storage-networking-and-connectivity",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Exposure",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "exposure"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"risk-based-testing",
"threat-modeling",
"sampling-bias",
"confidence-thresholds"
],
"requires": [],
"skill_id": "exposure",
"suppress_on_match": []
},
"skill_id": "exposure",
"split_log": [],
"typed": {
"alternatives_considered": [
"Domain: ruled out \u2014 it is not a full vertical/problem-space body of knowledge.",
"Methodology: ruled out \u2014 it describes a state or principle, not a way of working."
],
"confidence": 0.78,
"name": "Exposure",
"reasoning": "Exposure is best treated as a Concept because it is a named knowledge unit about the degree of potential loss or vulnerability, not a tool, format, or working process.",
"skill_id": "exposure",
"subtype": "risk_exposure",
"type": "Concept"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Infrastructure Engineering",
"id": null,
"rationale": "Covers the design, provisioning, and operation of compute, network, storage, and platform foundations that applications run on. This is the best fit for the broad skill \"Infrastructure\" in a DevOps context because it refers to the underlying environment rather than a single specialized subdomain.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Infrastructure",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Infrastructure",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Domain",
"skill_nature": "CONCEPT",
"sub_category": "infrastructure",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": false,
"confused_with": [],
"reasoning": "\"Infrastructure\" is a broad domain term, but in JDs it usually denotes the general infrastructure area rather than a distinct catalog skill with a competing meaning."
},
"context_keywords": {
"context_keywords": [
"Terraform",
"Ansible",
"Kubernetes",
"Docker",
"AWS",
"Azure",
"GCP",
"CI/CD",
"IaC",
"Helm",
"Linux",
"networking",
"load balancer",
"subnets",
"VPC"
]
},
"maturity": {
"confidence": 0.96,
"maturity": "well_known",
"reasoning": "Infrastructure is a core hiring-pipeline domain across cloud/DevOps roles; JDs routinely list AWS/Azure/GCP, Kubernetes, Terraform, and CI/CD under infrastructure responsibilities."
},
"skill_id": "infrastructure",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Covers the design, provisioning, and operation of compute, network, storage, and platform foundations that applications run on. This is the best fit for the broad skill \"Infrastructure\" in a DevOps context because it refers to the underlying environment rather than a single specialized subdomain.",
"exemplar_skills": [
"Infrastructure",
"Infrastructure as Code",
"Server Provisioning",
"Environment Setup",
"Capacity Planning",
"Cloud Infrastructure",
"Platform Operations"
],
"in_scope": "Infrastructure, servers, virtual machines, bare metal, cloud resources, networking foundations, storage foundations, operating systems, environment setup, capacity planning, platform primitives, infrastructure lifecycle",
"name": "Infrastructure Engineering",
"out_of_scope": "application code, CI/CD pipeline design, database schema design, security policy tuning, incident triage procedures, data migration execution",
"overlap_flags": [
{
"reason": "Infrastructure work often includes choosing managed cloud services, but that dimension is specifically about selecting services rather than the broader infrastructure layer.",
"with_dim_id": "cloud-platform-service-selection",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Infrastructure includes storage and connectivity, but that catalog dimension is narrower and focused on storage reachability and performance.",
"with_dim_id": "storage-networking-and-connectivity",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Infrastructure operations can involve incident handling, but that dimension owns the outage response and remediation workflow.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Infrastructure",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "infrastructure"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"capacity-planning",
"thin-provisioning",
"terraform",
"capacity-forecasting",
"dependency-mapping",
"acls",
"expressroute",
"pulumi",
"endpoint-hardening",
"feature-flags"
],
"requires": [],
"skill_id": "infrastructure",
"suppress_on_match": []
},
"skill_id": "infrastructure",
"split_log": [],
"typed": {
"alternatives_considered": [
"Concept: ruled out \u2014 it is broader than a single named knowledge unit and usually refers to an area of practice.",
"Architecture: ruled out \u2014 it does not specify a particular system-shape pattern like microservices or hexagonal architecture."
],
"confidence": 0.88,
"name": "Infrastructure",
"reasoning": "Infrastructure is best treated as a Domain because it names a broad technical problem-space/body of knowledge rather than a specific system shape, tool, or methodology.",
"skill_id": "infrastructure",
"subtype": "infrastructure",
"type": "Domain"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Domain Knowledge",
"id": null,
"rationale": "General understanding of the business, product, or technical domain that informs decisions and communication. This skill belongs here when it refers to knowing the relevant subject matter rather than a specific tool, process, or implementation technique.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Knowledge",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Knowledge",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Concept",
"skill_nature": "CONCEPT",
"sub_category": "general_knowledge",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"knowledge_management",
"knowledge_graph",
"knowledge_base"
],
"reasoning": "\"Knowledge\" is a very broad concept and in JDs could refer to knowledge management, knowledge graphs, or a knowledge base rather than the generic concept."
},
"context_keywords": {
"context_keywords": [
"domain expertise",
"subject matter expert",
"SME",
"institutional knowledge",
"knowledge base",
"knowledge management",
"knowledge transfer",
"knowledge sharing",
"lessons learned",
"best practices",
"documentation",
"runbooks",
"wikis",
"taxonomy",
"ontologies"
]
},
"maturity": {
"confidence": 0.92,
"maturity": "niche",
"reasoning": "\u201cKnowledge\u201d is a generic concept, not a specific engineering skill; it rarely appears as a standalone requirement in job descriptions compared with concrete tools or languages."
},
"skill_id": "knowledge",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "General understanding of the business, product, or technical domain that informs decisions and communication. This skill belongs here when it refers to knowing the relevant subject matter rather than a specific tool, process, or implementation technique.",
"exemplar_skills": [
"Knowledge",
"Domain knowledge",
"Subject matter expertise",
"Business context awareness",
"Operational understanding"
],
"in_scope": "Knowledge, domain knowledge, subject matter understanding, business context, product context, operational context, terminology, workflows, constraints, dependencies",
"name": "Domain Knowledge",
"out_of_scope": "Programming languages, cloud services, testing tools, security controls, database administration, which belong to more specific technical dimensions",
"overlap_flags": [
{
"reason": "Domain understanding often overlaps with service design decisions, but this dimension is about the architecture patterns themselves.",
"with_dim_id": "service-architecture-and-integration",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Platform familiarity can be part of domain knowledge, but service selection is a distinct architectural skill.",
"with_dim_id": "cloud-platform-service-selection",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Knowledge",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "knowledge"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [],
"requires": [],
"skill_id": "knowledge",
"suppress_on_match": []
},
"skill_id": "knowledge",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.97,
"name": "Knowledge",
"reasoning": "This is a named knowledge unit rather than a way of working or a system shape, so by the Concept vs Methodology and Architecture vs Concept rules it fits Concept.",
"skill_id": "knowledge",
"subtype": "general_knowledge",
"type": "Concept"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Linux System Administration",
"id": null,
"rationale": "Operating and troubleshooting Linux hosts used for servers, build agents, and cloud workloads. This skill belongs here because Linux is the core OS layer for managing users, processes, filesystems, services, and command-line operations.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Linux",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Linux",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Concept",
"skill_nature": "CONCEPT",
"sub_category": "operating_system",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": false,
"confused_with": [],
"reasoning": "Linux is a well-known operating system name and is typically unambiguous in job descriptions; it is unlikely to be confused with a different catalog skill."
},
"context_keywords": {
"context_keywords": [
"shell",
"bash",
"systemd",
"cron",
"iptables",
"SELinux",
"SSH",
"grep",
"awk",
"sed",
"package manager",
"kernel",
"filesystem",
"permissions",
"init"
]
},
"maturity": {
"confidence": 0.98,
"maturity": "well_known",
"reasoning": "Linux appears in a large share of DevOps, backend, cloud, and SRE job descriptions and is the default OS for most servers and containers; major vendors like AWS, GCP, and Azure all center Linux-based workloads."
},
"skill_id": "linux",
"vendor_license": {
"confidence": 0.98,
"license": "gpl_v2",
"vendor": "Linux Foundation",
"year_introduced": 1991
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Operating and troubleshooting Linux hosts used for servers, build agents, and cloud workloads. This skill belongs here because Linux is the core OS layer for managing users, processes, filesystems, services, and command-line operations.",
"exemplar_skills": [
"Linux",
"Linux administration",
"systemd",
"bash",
"SSH",
"filesystem management",
"process management",
"package management"
],
"in_scope": "Linux, shell usage, systemd service management, package management, users and groups, permissions and sudo, filesystems and mounts, process inspection, log inspection, cron jobs, networking basics on Linux, SSH access, kernel and OS tuning",
"name": "Linux System Administration",
"out_of_scope": "Container orchestration and Kubernetes workloads, cloud provider resource provisioning, database administration, application-level debugging, network appliance configuration, identity provider setup",
"overlap_flags": [
{
"reason": "Linux administration often supports outage triage, but this dimension is about the host OS itself rather than incident handling workflows.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Linux shell automation can overlap with security scripting, but that dimension centers on automating security tasks rather than general OS operations.",
"with_dim_id": "security-automation-and-scripting",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Linux",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "linux"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"bash",
"powershell",
"kubernetes",
"ansible"
],
"requires": [],
"skill_id": "linux",
"suppress_on_match": []
},
"skill_id": "linux",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.91,
"name": "Linux",
"reasoning": "Linux is fundamentally an operating system/kernel knowledge unit rather than a hosted environment or user-operated software, so it fits the Concept category best under the closed typology.",
"skill_id": "linux",
"subtype": "operating_system",
"type": "Concept"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Operational Monitoring",
"id": null,
"rationale": "Monitoring covers checking system, service, and infrastructure health through metrics, logs, alerts, and status signals. The skill fits here because it involves continuously watching for abnormal conditions and confirming systems are behaving as expected.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Monitor",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Monitor",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Tool",
"skill_nature": "TOOL",
"sub_category": "monitoring_tool",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"monitoring"
],
"reasoning": "\"Monitor\" is a generic term and can be read as the broader monitoring skill/tool category rather than this specific tool name, so a JD extractor could confuse it with the catalog\u0027s monitoring skill."
},
"context_keywords": {
"context_keywords": [
"Prometheus",
"Grafana",
"alerting",
"dashboards",
"metrics",
"logs",
"traces",
"observability",
"SLI",
"SLO",
"APM",
"Nagios",
"Datadog",
"New Relic",
"health checks"
]
},
"maturity": {
"confidence": 0.86,
"maturity": "niche",
"reasoning": "\u201cMonitor\u201d is a generic monitoring tool label, not a standard market keyword; JDs usually specify Datadog, Prometheus, Grafana, or CloudWatch instead, indicating low standalone hiring demand."
},
"skill_id": "monitor",
"vendor_license": {
"confidence": 0.12,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Monitoring covers checking system, service, and infrastructure health through metrics, logs, alerts, and status signals. The skill fits here because it involves continuously watching for abnormal conditions and confirming systems are behaving as expected.",
"exemplar_skills": [
"Monitor",
"set up alerts",
"review system health",
"track service uptime",
"watch logs and metrics"
],
"in_scope": "Monitor, alerting, health checks, metric review, log review, uptime checks, threshold-based detection, service status tracking",
"name": "Operational Monitoring",
"out_of_scope": "incident triage and remediation, dashboard/report creation, capacity planning, security event investigation, which belong to other operational dimensions",
"overlap_flags": [
{
"reason": "Monitoring often feeds incident response, but this dimension is about detection and observation rather than mitigation and recovery.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Dashboards can present monitoring data, but that dimension focuses on configuring reports and views rather than ongoing operational watch.",
"with_dim_id": "reporting-and-dashboard-configuration",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "Monitor",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "monitor"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"azure-monitor",
"dashboards",
"health-checks",
"notifications",
"replication-lag-monitoring",
"runbooks"
],
"requires": [],
"skill_id": "monitor",
"suppress_on_match": []
},
"skill_id": "monitor",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.88,
"name": "Monitor",
"reasoning": "Monitor is software you operate to observe systems, so by the Tool vs Framework rule it is a Tool rather than a framework or platform.",
"skill_id": "monitor",
"subtype": "monitoring_tool",
"type": "Tool"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "QA",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "SoftSkill",
"skill_nature": "PRACTICE",
"sub_category": "quality_assurance",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"quality_assurance"
],
"reasoning": "\"QA\" is a common abbreviation for quality assurance, but in JDs it can also mean quality analyst or QA testing roles; a catalog extractor could confuse this soft-skill label with the broader quality_assurance skill."
},
"context_keywords": {
"context_keywords": [
"test cases",
"test plans",
"regression testing",
"UAT",
"defect tracking",
"bug triage",
"test automation",
"Selenium",
"JIRA",
"manual testing",
"acceptance criteria",
"test scripts",
"smoke testing",
"traceability matrix",
"quality gates"
]
},
"maturity": {
"confidence": 0.95,
"maturity": "well_known",
"reasoning": "QA appears in a large share of software job descriptions and is a standard hiring-pipeline requirement across manual and automation roles, with broad tooling ecosystems and no sunset signal."
},
"skill_id": "qa",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [],
"merge_log": [
{
"into": "d_merge_01",
"into_name": "Requirements and Acceptance Validation",
"merged_from": [
"d_init_01",
"requirements-and-acceptance-validation"
],
"reasoning": "Dim A and Dim B describe the same cluster: validating implemented behavior against requirements, user stories, and acceptance criteria. A explicitly includes QA, manual testing, regression testing, defect verification, and sign-off testing; B says the same thing in slightly shorter form and notes manual testing starts by checking whether the product does what it should. No distinct skill boundary appears."
}
],
"placed": {
"name": "QA",
"placement_confidence": 0.0,
"primary_dimension": "d_init_00",
"reasoning": "Stub placement: no locked_dimensions after Stage 2/3; downstream containment and enrichment use placeholders only.",
"secondary_dimensions": [],
"skill_id": "qa"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"acceptance-criteria-checks",
"acceptance-criteria-validation",
"test-case-authoring",
"defect-retest",
"risk-based-testing",
"cross-browser-testing",
"session-based-testing",
"charter-based-testing"
],
"requires": [],
"skill_id": "qa",
"suppress_on_match": []
},
"skill_id": "qa",
"split_log": [],
"typed": {
"alternatives_considered": [
"Methodology: ruled out \u2014 QA is broader than a specific process like TDD or Scrum and is commonly used as a practice area rather than a named workflow.",
"Concept: ruled out \u2014 it is not primarily a single knowledge unit or principle, but an operational discipline."
],
"confidence": 0.78,
"name": "QA",
"reasoning": "QA is best treated as a quality-assurance practice area rather than a software artifact, and by the Concept vs Methodology rule it fits a way of working focused on verifying quality.",
"skill_id": "qa",
"subtype": "quality_assurance",
"type": "SoftSkill"
},
"warnings": [
"placement_stub_no_locked_dimensions"
]
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Site Reliability Engineering",
"id": null,
"rationale": "Practices for operating production systems with high availability, observability, and safe change management. This is the broader home for SRE as a discipline, covering reliability engineering beyond a single incident.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "SRE",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "SRE",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Methodology",
"skill_nature": "METHODOLOGY",
"sub_category": "site_reliability_engineering",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": false,
"confused_with": [],
"reasoning": "SRE is a well-known acronym for Site Reliability Engineering in JDs and is usually unambiguous in context; it is not commonly mistaken for another catalog skill."
},
"context_keywords": {
"context_keywords": [
"SLI",
"SLO",
"SLA",
"error budget",
"incident response",
"postmortem",
"on-call",
"blameless postmortem",
"observability",
"monitoring",
"alerting",
"capacity planning",
"service reliability",
"availability",
"latency",
"distributed systems"
]
},
"maturity": {
"confidence": 0.93,
"maturity": "well_known",
"reasoning": "SRE is broadly listed in DevOps/platform engineering job descriptions and has strong vendor support from Google, AWS, and Datadog; it\u2019s a standard hiring-pipeline skill rather than a niche practice."
},
"skill_id": "sre",
"vendor_license": {
"confidence": 0.98,
"license": null,
"vendor": "Google",
"year_introduced": 2003
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Practices for operating production systems with high availability, observability, and safe change management. This is the broader home for SRE as a discipline, covering reliability engineering beyond a single incident.",
"exemplar_skills": [
"SRE",
"service level objectives",
"error budgets",
"observability",
"monitoring",
"alerting",
"capacity planning",
"toil reduction"
],
"in_scope": "SRE, service level objectives, error budgets, observability, monitoring, alerting, capacity planning, toil reduction, resilience engineering, operational readiness, change management",
"name": "Site Reliability Engineering",
"out_of_scope": "one-off incident handling, application feature implementation, security policy administration, database access control, which are owned by more specific engineering or operations dimensions",
"overlap_flags": [
{
"reason": "SRE includes incident response, but that catalog dimension is the more specific home for outage triage and remediation.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Both cover reliability practices; this broader SRE dimension can overlap with service-specific reliability work.",
"with_dim_id": "model-service-reliability",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
}
],
"merge_log": [],
"placed": {
"name": "SRE",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "sre"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"eks",
"aks",
"gke",
"grpc",
"saml",
"hsm",
"ssids",
"r",
"defect-retest",
"expressroute",
"risk-based-testing",
"retention-metric"
],
"requires": [
"recovery-procedures",
"reconciliation",
"right-sizing",
"shutdown-sequencing",
"retention-policies",
"secret-rotation",
"rbac",
"cspm"
],
"skill_id": "sre",
"suppress_on_match": []
},
"skill_id": "sre",
"split_log": [],
"typed": {
"alternatives_considered": [
"Concept: ruled out \u2014 SRE is not just a knowledge unit; it describes an operational practice and operating model."
],
"confidence": 0.93,
"name": "SRE",
"reasoning": "SRE is fundamentally a way of working for operating and improving reliable systems, so by the Concept vs Methodology rule it fits Methodology rather than a tool or architecture.",
"skill_id": "sre",
"subtype": "site_reliability_engineering",
"type": "Methodology"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "General Automation Scripting",
"id": null,
"rationale": "Writing scripts to automate repetitive operational tasks, glue systems together, and reduce manual toil. This fits Scripting when the work is cross-cutting automation rather than a domain-specific implementation area.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "Scripting",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Scripting",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Language",
"skill_nature": "LANGUAGE",
"sub_category": "scripting_language",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"shell_scripting",
"python",
"javascript"
],
"reasoning": "\u201cScripting\u201d is a broad, generic term in JDs and can refer to specific scripting languages or shell scripting. A reasonable extractor could map it to Python, JavaScript, or shell_scripting depending on context."
},
"context_keywords": {
"context_keywords": [
"Bash",
"Shell",
"PowerShell",
"Perl",
"Ruby",
"Python",
"awk",
"sed",
"cron",
"CLI",
"automation",
"batch processing",
"Unix",
"Linux",
"Jenkins"
]
},
"maturity": {
"confidence": 0.93,
"maturity": "well_known",
"reasoning": "Scripting languages are a hiring-pipeline staple: job postings commonly ask for Python, Bash, or PowerShell scripting across DevOps, data, and automation roles, indicating broad market demand."
},
"skill_id": "scripting",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Writing scripts to automate repetitive operational tasks, glue systems together, and reduce manual toil. This fits Scripting when the work is cross-cutting automation rather than a domain-specific implementation area.",
"exemplar_skills": [
"Scripting",
"Bash scripting",
"Python scripting",
"PowerShell scripting",
"Shell scripting",
"Task automation",
"Command-line automation"
],
"in_scope": "Scripting, Bash, Python automation, PowerShell, shell scripts, cron jobs, command-line utilities, file manipulation, API glue code, task automation",
"name": "General Automation Scripting",
"out_of_scope": "Full application development, test framework authoring, security-specific remediation, database-only administration scripts, these are owned by more specialized dimensions",
"overlap_flags": [
{
"reason": "Many scripting tasks use backend languages, but this dimension emphasizes small operational scripts rather than service code.",
"with_dim_id": "programming-languages-for-backend-systems",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Long-lived automation may require maintenance, but that dimension focuses on keeping existing automation stable rather than creating scripts.",
"with_dim_id": "automation-maintenance-and-refactoring",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_02"
}
],
"merge_log": [
{
"into": "d_merge_01",
"into_name": "Security Automation Scripting and Workflow Automation",
"merged_from": [
"d_init_01",
"security-automation-and-scripting"
],
"reasoning": "Dim A and Dim B describe the same conceptual cluster: lightweight scripting used to operationalize security work. Both descriptions center on automating repeatable security checks, enrichment, and remediation workflows, and Dim A\u2019s exemplars (Python scripting, Bash scripting, PowerShell scripting, log enrichment scripts, alert triage automation) are exactly the kinds of skills implied by Dim B\u2019s broader description. The only substantive difference is that Dim A adds explicit scope boundaries (e.g., excluding general backend development, data engineering, infra provisioning) and concrete examples, while Dim B is a shorter version of the same idea. Because the underlying skill cluster is identical and not a broader/narrower split, the right reconciliation is to merge them."
}
],
"placed": {
"name": "Scripting",
"placement_confidence": 0.92,
"primary_dimension": "d_init_02",
"reasoning": "Deterministic JD placement: locked_dimensions has 1 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [],
"skill_id": "scripting"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"bash-scripting",
"powershell",
"python-scripting",
"typescript",
"bash",
"javascript",
"python",
"java",
"json",
"c"
],
"requires": [],
"skill_id": "scripting",
"suppress_on_match": []
},
"skill_id": "scripting",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.88,
"name": "Scripting",
"reasoning": "Scripting is fundamentally a programming language category rather than a tool or framework, since it refers to writing executable code in a language used to automate tasks.",
"skill_id": "scripting",
"subtype": "scripting_language",
"type": "Language"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [
{
"dimension": {
"difficulty_hint": null,
"display_name": "Technical Understanding and Comprehension",
"id": null,
"rationale": "Ability to understand technical concepts, system behavior, and operational context well enough to make correct decisions. This skill is broad and foundational, so it does not map cleanly to a narrower catalog dimension.",
"slug": "d_init_01",
"source": "llm"
},
"input_skill": "Understanding",
"llm_role": null,
"roles_from_db": []
},
{
"dimension": {
"difficulty_hint": null,
"display_name": "Requirements Comprehension",
"id": null,
"rationale": "Understanding what a system, process, or change is supposed to do from requirements, acceptance criteria, and stakeholder descriptions. This fits when the skill is about interpreting expected behavior rather than implementing or testing it.",
"slug": "d_init_02",
"source": "llm"
},
"input_skill": "Understanding",
"llm_role": null,
"roles_from_db": []
}
],
"input_skill": "Understanding",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": {
"derived": {
"category": "Concept",
"skill_nature": "CONCEPT",
"sub_category": "comprehension",
"typical_lifespan": "EVERGREEN",
"version_strategy": "NOT_APPLICABLE",
"volatility": "STABLE"
},
"enrichment": {
"ambiguity": {
"ambiguity_flag": true,
"confused_with": [
"understanding_customer_needs",
"understanding_business_requirements"
],
"reasoning": "\"Understanding\" is too generic for JDs and could easily be parsed as a soft skill or as part of phrases like understanding customer needs or business requirements, which are distinct catalog skills."
},
"context_keywords": {
"context_keywords": [
"requirements analysis",
"stakeholder needs",
"problem framing",
"root cause analysis",
"domain knowledge",
"specification",
"interpretation",
"critical thinking",
"requirements gathering",
"gap analysis",
"user stories",
"acceptance criteria",
"business context",
"system behavior",
"edge cases"
]
},
"maturity": {
"confidence": 0.93,
"maturity": "well_known",
"reasoning": "Core comprehension is a universal hiring requirement across JDs and interview loops; it appears implicitly in nearly every role rather than as a niche tool skill."
},
"skill_id": "understanding",
"vendor_license": {
"confidence": 0.99,
"license": null,
"vendor": null,
"year_introduced": null
},
"versioning": {
"current_version": null,
"version_aliases": {},
"versioned": false
}
},
"locked_dimensions": [
{
"description": "Ability to understand technical concepts, system behavior, and operational context well enough to make correct decisions. This skill is broad and foundational, so it does not map cleanly to a narrower catalog dimension.",
"exemplar_skills": [
"Understanding",
"Reading technical documentation",
"Interpreting system diagrams",
"Grasping operational workflows",
"Understanding failure modes"
],
"in_scope": "Understanding, comprehension of technical documentation, reading system diagrams, grasping architecture and workflows, interpreting logs and metrics, understanding runbooks and SOPs, understanding dependencies and failure modes",
"name": "Technical Understanding and Comprehension",
"out_of_scope": "Hands-on incident triage and mitigation, which belongs to incident-response-and-remediation; security design review, which belongs to security-architecture-review; coding or scripting implementation, which belongs to programming-languages-for-backend-systems or security-automation-and-scripting",
"overlap_flags": [
{
"reason": "Understanding is often used during incident work, but that dimension owns the active response and remediation behaviors.",
"with_dim_id": "incident-response-and-remediation",
"with_dim_name": null,
"with_role": null
},
{
"reason": "Understanding security implications can support review work, but the review and threat-analysis activity belongs there.",
"with_dim_id": "security-architecture-review",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_01"
},
{
"description": "Understanding what a system, process, or change is supposed to do from requirements, acceptance criteria, and stakeholder descriptions. This fits when the skill is about interpreting expected behavior rather than implementing or testing it.",
"exemplar_skills": [
"Understanding",
"Requirements comprehension",
"Acceptance criteria interpretation",
"User story analysis",
"Specification reading"
],
"in_scope": "Understanding requirements, acceptance criteria, user stories, functional expectations, scope boundaries, reading specifications, clarifying ambiguities, understanding desired outcomes",
"name": "Requirements Comprehension",
"out_of_scope": "Executing validation or test cases, which belongs to requirements-and-acceptance-validation; building the solution, which belongs to implementation-oriented programming dimensions; operational troubleshooting, which belongs to incident-response-and-remediation",
"overlap_flags": [
{
"reason": "Understanding requirements is closely related, but that dimension owns the act of checking implemented behavior against them.",
"with_dim_id": "requirements-and-acceptance-validation",
"with_dim_name": null,
"with_role": null
}
],
"tentative_id": "d_init_02"
}
],
"merge_log": [],
"placed": {
"name": "Understanding",
"placement_confidence": 0.92,
"primary_dimension": "d_init_01",
"reasoning": "Deterministic JD placement: locked_dimensions has 2 dimension(s) from skill-driven dimension generation after reconciliation; primary_dimension is the first locked dim.",
"secondary_dimensions": [
"d_init_02"
],
"skill_id": "understanding"
},
"relationships": {
"child_skills": [],
"parent_skills": [],
"related_to": [
"error-analysis",
"threat-modeling",
"acceptance-criteria-validation",
"acceptance-criteria-checks",
"dependency-mapping",
"clean-architecture",
"reconciliation"
],
"requires": [],
"skill_id": "understanding",
"suppress_on_match": []
},
"skill_id": "understanding",
"split_log": [],
"typed": {
"alternatives_considered": [],
"confidence": 0.97,
"name": "Understanding",
"reasoning": "Understanding is a named knowledge unit about grasping information, so by the Concept vs Methodology rule it is a Concept rather than a way of working.",
"skill_id": "understanding",
"subtype": "comprehension",
"type": "Concept"
},
"warnings": []
},
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "access",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "administration",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "applications",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "architectures",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "balancing",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "build",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "configuration",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "container",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "control",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "deployment",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "development",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "disaster",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "efficiency",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "environment",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "environments",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "incident",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "issues",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "load",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "management",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "mechanisms",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "message",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "monitoring",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "networking",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "observability",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "orchestration",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "performance",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "pipelines",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "platforms",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "practices",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "processes",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "production",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "provisioning",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "queue",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "recovery",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "release",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "scaling",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "scanning",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "security",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "strategies",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "system",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "systems",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "test",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
},
{
"aliases_in_db": [],
"canonical": null,
"dimensions": [],
"input_skill": "tools",
"matched_via": null,
"new_alias_persisted": false,
"new_alias_text": null,
"new_skill_meta": null,
"source_tag": "llm",
"was_in_llm_skills": true
}
],
"unmatched_skills": [
"CI",
"Cloud",
"Code",
"ELK",
"Exposure",
"Infrastructure",
"Knowledge",
"Linux",
"Monitor",
"QA",
"SRE",
"Scripting",
"Understanding"
]
}
API 3 — final-role-output
{
"chosen_role": {
"display_name": "DevOps Engineer",
"id": 1,
"rationale": "DevOps Engineer is the dominant role across observability, configuration management, IaC, containerization, cloud operations, and CI/CD dimensions.",
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
},
"final_input_skills": [
{
"skill": "Disaster Recovery",
"tag": "in_db"
},
{
"skill": "Redis",
"tag": "in_db"
},
{
"skill": "Datadog",
"tag": "in_db"
},
{
"skill": "Load Balancing",
"tag": "in_db"
},
{
"skill": "Bash",
"tag": "in_db"
},
{
"skill": "Ansible",
"tag": "in_db"
},
{
"skill": "Kubernetes",
"tag": "in_db"
},
{
"skill": "shell scripting",
"tag": "in_db"
},
{
"skill": "Microservices",
"tag": "in_db"
},
{
"skill": "Terraform",
"tag": "in_db"
},
{
"skill": "CloudFormation",
"tag": "in_db"
},
{
"skill": "Jenkins",
"tag": "in_db"
},
{
"skill": "GitLab CI",
"tag": "in_db"
},
{
"skill": "Python",
"tag": "in_db"
},
{
"skill": "Grafana",
"tag": "in_db"
},
{
"skill": "Docker",
"tag": "in_db"
},
{
"skill": "Prometheus",
"tag": "in_db"
},
{
"skill": "Azure",
"tag": "in_db"
},
{
"skill": "GitHub Actions",
"tag": "in_db"
},
{
"skill": "Kafka",
"tag": "in_db"
},
{
"skill": "AWS",
"tag": "in_db"
},
{
"skill": "CI",
"tag": "new"
},
{
"skill": "Cloud",
"tag": "new"
},
{
"skill": "Code",
"tag": "new"
},
{
"skill": "ELK",
"tag": "new"
},
{
"skill": "Exposure",
"tag": "new"
},
{
"skill": "Infrastructure",
"tag": "new"
},
{
"skill": "Knowledge",
"tag": "new"
},
{
"skill": "Linux",
"tag": "new"
},
{
"skill": "Monitor",
"tag": "new"
},
{
"skill": "QA",
"tag": "new"
},
{
"skill": "SRE",
"tag": "new"
},
{
"skill": "Scripting",
"tag": "new"
},
{
"skill": "Understanding",
"tag": "new"
},
{
"skill": "access",
"tag": "new"
},
{
"skill": "administration",
"tag": "new"
},
{
"skill": "applications",
"tag": "new"
},
{
"skill": "architectures",
"tag": "new"
},
{
"skill": "balancing",
"tag": "new"
},
{
"skill": "build",
"tag": "new"
},
{
"skill": "configuration",
"tag": "new"
},
{
"skill": "container",
"tag": "new"
},
{
"skill": "control",
"tag": "new"
},
{
"skill": "deployment",
"tag": "new"
},
{
"skill": "development",
"tag": "new"
},
{
"skill": "disaster",
"tag": "new"
},
{
"skill": "efficiency",
"tag": "new"
},
{
"skill": "environment",
"tag": "new"
},
{
"skill": "environments",
"tag": "new"
},
{
"skill": "incident",
"tag": "new"
},
{
"skill": "issues",
"tag": "new"
},
{
"skill": "load",
"tag": "new"
},
{
"skill": "management",
"tag": "new"
},
{
"skill": "mechanisms",
"tag": "new"
},
{
"skill": "message",
"tag": "new"
},
{
"skill": "monitoring",
"tag": "new"
},
{
"skill": "networking",
"tag": "new"
},
{
"skill": "observability",
"tag": "new"
},
{
"skill": "orchestration",
"tag": "new"
},
{
"skill": "performance",
"tag": "new"
},
{
"skill": "pipelines",
"tag": "new"
},
{
"skill": "platforms",
"tag": "new"
},
{
"skill": "practices",
"tag": "new"
},
{
"skill": "processes",
"tag": "new"
},
{
"skill": "production",
"tag": "new"
},
{
"skill": "provisioning",
"tag": "new"
},
{
"skill": "queue",
"tag": "new"
},
{
"skill": "recovery",
"tag": "new"
},
{
"skill": "release",
"tag": "new"
},
{
"skill": "scaling",
"tag": "new"
},
{
"skill": "scanning",
"tag": "new"
},
{
"skill": "security",
"tag": "new"
},
{
"skill": "strategies",
"tag": "new"
},
{
"skill": "system",
"tag": "new"
},
{
"skill": "systems",
"tag": "new"
},
{
"skill": "test",
"tag": "new"
},
{
"skill": "tools",
"tag": "new"
}
],
"persistence": {
"items": [
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Backup and Disaster Recovery",
"id": 51,
"rationale": "Plans and operates backup, restore, and disaster recovery capabilities for Azure environments. This is a distinct cluster because recovery objectives and restore mechanics are specialized operational skills.",
"slug": "backup-and-disaster-recovery",
"source": "db"
},
"dimension_id": 51,
"input_skill": "Disaster Recovery",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 278,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "NoSQL and Cache Stores",
"id": 145,
"rationale": "Non-relational databases and in-memory stores used for low-latency access, flexible schemas, and specialized persistence patterns. This cluster is coherent because backend services often combine these stores with relational systems.",
"slug": "nosql-and-cache-stores",
"source": "db"
},
"dimension_id": 145,
"input_skill": "Redis",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 846,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"dimension_id": 27,
"input_skill": "Datadog",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 171,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Scaling and Resilience Engineering",
"id": 45,
"rationale": "Implements Azure-side patterns that improve availability, capacity, and fault tolerance. This is a coherent cluster because the role must keep environments ready for production load and failure scenarios.",
"slug": "scaling-and-resilience-engineering",
"source": "db"
},
"dimension_id": 45,
"input_skill": "Load Balancing",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 275,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Build and Execution Tooling",
"id": 206,
"rationale": "Command-line and build tools used to run, package, and integrate automated tests into developer workflows. This cluster is coherent because automation testers often need to wire tests into local and shared execution paths.",
"slug": "build-and-execution-tooling",
"source": "db"
},
"dimension_id": 206,
"input_skill": "Bash",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 1248,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Configuration Management",
"id": 23,
"rationale": "Manages environment-specific settings, secrets wiring, and standardized runtime configuration across services. It is distinct from infrastructure provisioning because it focuses on how software is parameterized at deploy time.",
"slug": "configuration-management",
"source": "db"
},
"dimension_id": 23,
"input_skill": "Ansible",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 147,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"dimension_id": 285,
"input_skill": "Ansible",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 147,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Orchestration Platforms",
"id": 25,
"rationale": "Operates the platforms that schedule and run containerized workloads and related deployment primitives. This is separate from image delivery because it concerns runtime placement and service rollout behavior.",
"slug": "orchestration-platforms",
"source": "db"
},
"dimension_id": 25,
"input_skill": "Kubernetes",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
},
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 158,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming for Data Automation",
"id": 93,
"rationale": "Lightweight scripting used to automate repetitive analysis tasks, data preparation, and report generation. This is a useful split because data scientists often need practical automation without owning full pipelines.",
"slug": "programming-for-data-automation",
"source": "db"
},
"dimension_id": 93,
"input_skill": "shell scripting",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 549,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Service Architecture and Integration",
"id": 148,
"rationale": "Patterns for structuring backend systems as services and coordinating calls across internal and external dependencies. This includes how services are decomposed, connected, and evolved safely.",
"slug": "service-architecture-and-integration",
"source": "db"
},
"dimension_id": 148,
"input_skill": "Microservices",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 864,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure Provisioning Templates",
"id": 291,
"rationale": "Declarative templates and modules used to create repeatable cloud resources and environments. This cluster covers the infrastructure definitions the role applies, reviews, and updates to keep environments consistent.",
"slug": "infrastructure-provisioning-templates",
"source": "db"
},
"dimension_id": 291,
"input_skill": "Terraform",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 144,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"dimension_id": 22,
"input_skill": "Terraform",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 144,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code and Declarative Provisioning",
"id": 36,
"rationale": "Defines cloud and platform infrastructure declaratively through versioned code so environments are repeatable, reviewable, and automatable. This includes authoring and maintaining IaC templates/modules, managing parameters and state, and using plan/apply workflows to provision and update resources across Azure and other cloud platforms.",
"slug": "infrastructure-as-code-and-declarative-provisioning",
"source": "db"
},
"dimension_id": 36,
"input_skill": "Terraform",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 144,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Infrastructure as Code",
"id": 22,
"rationale": "Defines infrastructure and platform resources through versioned code so environments are repeatable and reviewable. This is a coherent cluster because it underpins environment consistency and change control.",
"slug": "infrastructure-as-code",
"source": "db"
},
"dimension_id": 22,
"input_skill": "CloudFormation",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 145,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"dimension_id": 207,
"input_skill": "Jenkins",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 1249,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"dimension_id": 207,
"input_skill": "GitLab CI",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 1251,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Analytical Programming Languages",
"id": 82,
"rationale": "Languages used to clean, transform, analyze, and prototype models in notebooks and scripts. This is the core coding surface for expressing statistical logic and data manipulation in a reproducible way.",
"slug": "analytical-programming-languages",
"source": "db"
},
"dimension_id": 82,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Data Analyst",
"id": 20,
"rationale": null,
"role_archetype": null,
"slug": "data-analyst",
"source": "db"
},
{
"display_name": "Data Scientist",
"id": 7,
"rationale": null,
"role_archetype": null,
"slug": "data-scientist",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Automation Scripting and CLI",
"id": 48,
"rationale": "Uses scripts and command-line tooling to execute repeatable Azure operations and reduce manual work. This is a practical cluster because the role frequently automates provisioning, checks, and remediation tasks.",
"slug": "automation-scripting-and-cli",
"source": "db"
},
"dimension_id": 48,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Azure Cloud Engineer",
"id": 4,
"rationale": null,
"role_archetype": null,
"slug": "azure-cloud-engineer",
"source": "db"
},
{
"display_name": "Cloud Engineer",
"id": 18,
"rationale": null,
"role_archetype": null,
"slug": "cloud-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Network Automation and Scripting",
"id": 285,
"rationale": "Covers scripts and automation used to configure, validate, and audit network devices and services. This cluster is coherent because repeatable network operations increasingly depend on programmatic changes and checks.",
"slug": "network-automation-and-scripting",
"source": "db"
},
"dimension_id": 285,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Network Engineer",
"id": 21,
"rationale": null,
"role_archetype": null,
"slug": "network-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for AI Workflows",
"id": 261,
"rationale": "Languages used to implement AI feature logic, orchestration, and response handling inside product code. This is the core coding surface for turning prompts and model calls into reliable application behavior.",
"slug": "programming-languages-for-ai-workflows",
"source": "db"
},
"dimension_id": 261,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "AI Engineer",
"id": 12,
"rationale": null,
"role_archetype": null,
"slug": "ai-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Backend Systems",
"id": 140,
"rationale": "Languages used to implement server-side business logic, request handlers, workers, and service integrations. This is the core coding surface for backend feature delivery and maintenance.",
"slug": "programming-languages-for-backend-systems",
"source": "db"
},
"dimension_id": 140,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Data Work",
"id": 67,
"rationale": "Languages used to implement data pipelines, transformations, and operational utilities. This is the code layer for expressing extraction, parsing, validation, and orchestration logic in data engineering workflows.",
"slug": "programming-languages-for-data-work",
"source": "db"
},
"dimension_id": 67,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Data Engineer",
"id": 6,
"rationale": null,
"role_archetype": null,
"slug": "data-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for ML Systems",
"id": 113,
"rationale": "Languages used to implement model integration code, inference services, and feature-processing logic. This is the core coding surface for turning trained models into product-facing software components.",
"slug": "programming-languages-for-ml-systems",
"source": "db"
},
"dimension_id": 113,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Programming Languages for Test Automation",
"id": 193,
"rationale": "Languages used to implement automated checks, helper utilities, and test harness code. This is the core coding surface for turning test ideas into maintainable automation.",
"slug": "programming-languages-for-test-automation",
"source": "db"
},
"dimension_id": 193,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Security Automation and Scripting",
"id": 258,
"rationale": "Automating repeatable security checks, enrichment, and remediation workflows. This cluster is coherent because the role often needs lightweight automation to scale analysis and response.",
"slug": "security-automation-and-scripting",
"source": "db"
},
"dimension_id": 258,
"input_skill": "Python",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Cybersecurity Engineer",
"id": 9,
"rationale": null,
"role_archetype": null,
"slug": "cybersecurity-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 393,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"dimension_id": 27,
"input_skill": "Grafana",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 169,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"dimension_id": 151,
"input_skill": "Grafana",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 169,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Containerization and Image Delivery",
"id": 24,
"rationale": "Builds, packages, and ships application and support workloads as container images. This cluster covers the artifact format and the mechanics of producing deployable images.",
"slug": "containerization-and-image-delivery",
"source": "db"
},
"dimension_id": 24,
"input_skill": "Docker",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 153,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Model Serving Deployment and Runtime Packaging",
"id": 52,
"rationale": "Operational deployment of trained models into online, batch, or streaming serving environments, including packaging models and model servers into containers or managed inference runtimes, coordinating rollout, and handing off to inference systems. Covers serving frameworks and platforms such as TensorFlow Serving, TorchServe, Triton Inference Server, BentoML, KServe, and Seldon Core, plus container/runtime concerns like Docker images, GPU-enabled containers, base image selection, container entrypoints, runtime dependencies, and image scanning for model services.",
"slug": "model-serving-deployment-and-runtime-packaging",
"source": "db"
},
"dimension_id": 52,
"input_skill": "Docker",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "MLOps Engineer",
"id": 5,
"rationale": null,
"role_archetype": null,
"slug": "mlops-engineer",
"source": "db"
},
{
"display_name": "Machine Learning Engineer",
"id": 10,
"rationale": null,
"role_archetype": null,
"slug": "machine-learning-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 153,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Alerting",
"id": 27,
"rationale": "Builds feedback loops for system health through metrics, logs, traces, dashboards, and alerts. This cluster is coherent because it turns runtime behavior into actionable operational signals.",
"slug": "observability-and-alerting",
"source": "db"
},
"dimension_id": 27,
"input_skill": "Prometheus",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 168,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Observability and Diagnostics",
"id": 151,
"rationale": "Logging, metrics, tracing, dashboards, and debugging practices used to understand backend behavior in production. This cluster is coherent because backend engineers must detect failures, performance issues, and unexpected behavior.",
"slug": "observability-and-diagnostics",
"source": "db"
},
"dimension_id": 151,
"input_skill": "Prometheus",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 168,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"dimension_id": 26,
"input_skill": "Azure",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 164,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Continuous Integration Test Integration",
"id": 207,
"rationale": "Integrating automated checks into shared build and merge workflows so results are repeatable and visible. This cluster is coherent because automation testers commonly configure test execution triggers, artifacts, and reporting hooks.",
"slug": "continuous-integration-test-integration",
"source": "db"
},
"dimension_id": 207,
"input_skill": "GitHub Actions",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Automation Tester",
"id": 16,
"rationale": null,
"role_archetype": null,
"slug": "automation-tester",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 1250,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Messaging and Event Streaming",
"id": 146,
"rationale": "Asynchronous communication patterns and systems for decoupled service interaction and background processing. This is a coherent backend cluster because many server-side workflows depend on queues, topics, and event streams.",
"slug": "messaging-and-event-streaming",
"source": "db"
},
"dimension_id": 146,
"input_skill": "Kafka",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "Backend Engineer",
"id": 14,
"rationale": null,
"role_archetype": null,
"slug": "backend-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 852,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": "well_known",
"display_name": "Cloud Platform Operations",
"id": 26,
"rationale": "Uses cloud provider services to support delivery and runtime environments. The focus is on consumer-level operation of cloud services rather than deep cloud architecture ownership.",
"slug": "cloud-platform-operations",
"source": "db"
},
"dimension_id": 26,
"input_skill": "AWS",
"llm_role": null,
"matched_chosen_role": true,
"role_dimension_saved": false,
"roles_from_db": [
{
"display_name": "DevOps Engineer",
"id": 1,
"rationale": null,
"role_archetype": "A DevOps Engineer enables reliable, repeatable delivery of software by designing and operating the processes that connect development and production. They focus on improving deployment flow, operational stability, and collaboration between teams through automation, standardization, and monitoring of delivery and runtime practices.",
"slug": "devops-engineer",
"source": "db"
}
],
"skill_dimension_saved": false,
"skill_id": 163,
"skill_tag": "in_db",
"skipped_reason": "TODO: REMOVE AFTER TESTING \u2014 api3_writes_enabled=False (writes disabled)"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Continuous Integration",
"id": null,
"rationale": "Practices and tooling for automatically building, testing, and validating code changes on every commit or pull request. CI belongs here because it is the core automation layer that keeps changes integrated and feedback fast in DevOps workflows.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "CI",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Build and Test Automation",
"id": null,
"rationale": "Automation that compiles code and runs verification steps as part of a repeatable delivery pipeline. This fits CI when the emphasis is on the automated build-and-test mechanics rather than broader release management.",
"slug": "d_init_02",
"source": "llm"
},
"dimension_id": null,
"input_skill": "CI",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "General Programming Code",
"id": null,
"rationale": "Writing executable code in a general-purpose programming language to implement logic, transformations, and control flow. The target skill belongs here because it is the broad act of coding when no narrower language- or framework-specific dimension is intended.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Code",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Log Aggregation and Search",
"id": null,
"rationale": "Covers centralized collection, indexing, search, and analysis of logs for troubleshooting and operational visibility. ELK belongs here because it is commonly used as the stack for ingesting, storing, querying, and visualizing machine logs.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "ELK",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Exposure Management",
"id": null,
"rationale": "Covers controlling how systems, services, and endpoints are exposed to networks, users, and external traffic. This skill fits here when it refers to limiting or shaping what is reachable from outside the host or cluster.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Exposure",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Infrastructure Engineering",
"id": null,
"rationale": "Covers the design, provisioning, and operation of compute, network, storage, and platform foundations that applications run on. This is the best fit for the broad skill \"Infrastructure\" in a DevOps context because it refers to the underlying environment rather than a single specialized subdomain.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Infrastructure",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Domain Knowledge",
"id": null,
"rationale": "General understanding of the business, product, or technical domain that informs decisions and communication. This skill belongs here when it refers to knowing the relevant subject matter rather than a specific tool, process, or implementation technique.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Knowledge",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Linux System Administration",
"id": null,
"rationale": "Operating and troubleshooting Linux hosts used for servers, build agents, and cloud workloads. This skill belongs here because Linux is the core OS layer for managing users, processes, filesystems, services, and command-line operations.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Linux",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Operational Monitoring",
"id": null,
"rationale": "Monitoring covers checking system, service, and infrastructure health through metrics, logs, alerts, and status signals. The skill fits here because it involves continuously watching for abnormal conditions and confirming systems are behaving as expected.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Monitor",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Site Reliability Engineering",
"id": null,
"rationale": "Practices for operating production systems with high availability, observability, and safe change management. This is the broader home for SRE as a discipline, covering reliability engineering beyond a single incident.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "SRE",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "General Automation Scripting",
"id": null,
"rationale": "Writing scripts to automate repetitive operational tasks, glue systems together, and reduce manual toil. This fits Scripting when the work is cross-cutting automation rather than a domain-specific implementation area.",
"slug": "d_init_02",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Scripting",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Technical Understanding and Comprehension",
"id": null,
"rationale": "Ability to understand technical concepts, system behavior, and operational context well enough to make correct decisions. This skill is broad and foundational, so it does not map cleanly to a narrower catalog dimension.",
"slug": "d_init_01",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Understanding",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
},
{
"chosen_role_id": 1,
"dimension": {
"difficulty_hint": null,
"display_name": "Requirements Comprehension",
"id": null,
"rationale": "Understanding what a system, process, or change is supposed to do from requirements, acceptance criteria, and stakeholder descriptions. This fits when the skill is about interpreting expected behavior rather than implementing or testing it.",
"slug": "d_init_02",
"source": "llm"
},
"dimension_id": null,
"input_skill": "Understanding",
"llm_role": null,
"matched_chosen_role": false,
"role_dimension_saved": false,
"roles_from_db": [],
"skill_dimension_saved": false,
"skill_id": null,
"skill_tag": "new",
"skipped_reason": "skill_not_in_db_v3_proposed"
}
],
"new_skills_created": 0,
"role_dimension_saved": 0,
"skill_dimension_saved": 0,
"skipped": 48
},
"planner_output": null,
"run_id": "c123e6af-1ee0-46fc-ac24-3514f0fbd8fb"
}
LLM Calls
Every model call made for this run, in pipeline order. Click a card to see the model's response.
Loading…