Building a Deterministic JD Analyser: Grounded in the GFE Sk### 6.6 Technical Challenges Solved

Challenge	Solution
SSR hydration errors	Client-side only form rendering
Multipart file parsing	Busboy library for Node.js
Email notification failures	Properly awaited async fetch calls
Level name confusion	Direct mapping from spec JSON files
Keyword coverage	Expanded keywords from task descriptions
Frontend-backend mismatch	Field name alignment + new UI components
Empty UI fields	Proper null checking and fallback values
Cross-domain keyword pollution	Refined keywords to be domain-specific
Wrong domain tasks surfacing	Title-based detection + domain-sorted results

Authors: GrowthFlow Engineering Team
Version: 2.2.0-domain-sort
Last Updated: January 2025
Status: Production

Executive Summary

This whitepaper documents the development journey of the GFE JD Analyser—a deterministic tool that analyses job descriptions and maps them to the GFE Skill System's 174 tasks across Marketing, Sales, and Finance domains.

What began as an LLM-powered experiment evolved into a principled, rule-based system grounded in real task specifications. This document covers:

The Problem: Traditional JD analysis tools either rely on expensive LLMs or use arbitrary "skill" inventories
The Insight: The GFE Skill System already defines 174 concrete tasks—we should match against those, not invent skills
The Architecture: A serverless Netlify function using pattern matching against actual task specifications
The Taxonomy: Complete explanation of the GFE Skill System's structure (Levels, Tasks, Processes, KPIs, ValuationOps)
Domain Sorting: Intelligent detection and prioritization so marketing JDs surface marketing tasks first (v2.2.0)

Part 1: The Problem Space

1.1 Traditional JD Analysis Approaches

Most job description analysis tools fall into two categories:

LLM-Dependent Approaches

Send JD text to GPT/Claude/Gemini and ask it to "extract skills"
Results are non-deterministic and vary between calls
Expensive at scale (API costs compound)
Skills invented on-the-fly with no standardized taxonomy

Keyword-Matching Approaches

Match against arbitrary lists like "Excel", "Communication", "Leadership"
No hierarchy or leveling
No connection to business outcomes
Misses context ("Excel" for a finance role ≠ "Excel" for an admin role)

1.2 The Key Insight

The GFE Skill System already solves this problem. It defines 174 concrete tasks with:

Clear domain assignments (Marketing, Sales, Finance)
Level designations (L0-L4) indicating seniority
KPI linkages connecting tasks to measurable outcomes
Process mappings showing how tasks fit into business workflows

Why invent skills when we have tasks?

A "skill" is abstract and subjective. A task is concrete and verifiable:

Approach	Example	Problem
Invented Skill	"Data Analysis"	What level? What domain? How measured?
GFE Task	`F-012: Prepare Variance Reports` (L1, Finance)	Clear level, domain, linked to KPI-FIN-VAR-01

Part 2: The GFE Skill System Deep Dive

2.1 The Five Levels

The GFE Skill System defines five levels, each with clear progression expectations:

Level	Name	Focus	Time Horizon
L0	Apprentice	Execute defined tasks, build fundamentals	Daily tasks
L1	Practitioner	Own processes, contribute to improvements	Weekly cycles
L2	Architect	Design systems, optimize performance	Monthly/Quarterly
L3	Strategist	Drive cross-functional initiatives	Annual planning
L4	Partner	Shape organizational direction	Multi-year vision

2.2 The LEO Framework

Each level has expectations across three dimensions (Learning, Earning, Org-Building):

┌─────────────────────────────────────────────────────────────┐
│                    LEO Framework                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Learning (25%)     │   Earning (60%)    │  Org-Building   │
│   ─────────────────  │   ──────────────   │  (15%)          │
│   • Self-study       │   • Task delivery  │  • Mentoring    │
│   • Certifications   │   • KPI impact     │  • Process docs │
│   • Peer learning    │   • Revenue contrib│  • Team growth  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Each domain (Marketing, Sales, Finance) has specific LEO expectations per level.

2.3 The 174 Tasks

Tasks are the atomic units of the GFE Skill System. Here's the distribution:

Domain	Task Count	ID Prefix	Example
Marketing	67 tasks	M-###	M-001: Clean Contact Lists
Sales	69 tasks	S-###	S-001: Qualify Inbound Leads
Finance	38 tasks	F-###	F-001: Process Invoices

Each task specification includes:

json

{
  "id": "S-015",
  "title": "Negotiate Contract Terms",
  "domain": "sales",
  "level": 2,
  "description": "Lead contract negotiations with prospects...",
  "kpi_links": ["KPI-REV-WIN-01", "KPI-REV-DEAL-01"],
  "owner": "Account Executive",
  "process_id": "PROC-REV-DEAL-CLOSING-01"
}

2.4 The 44 Processes

Tasks group into processes—business workflows with primary KPIs:

Process ID	Process Name	Primary KPI
PROC-REV-DEMAND-GEN-01	Demand Generation Pipeline	KPI-MKT-MQL-01
PROC-REV-DEAL-CLOSING-01	Pipeline Management	KPI-REV-WIN-01
PROC-FIN-REPORTING-01	Financial Reporting	KPI-FIN-REPORT-01
PROC-REV-CUSTOMER-SUCCESS-01	Customer Success Programs	KPI-REV-NRR-01

2.5 ValuationOps Layers

The ultimate purpose: every task connects to company valuation through six layers:

┌────────────────────────────────────────────────────────────────┐
│                   ValuationOps Layers                          │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│   Layer 1: Revenue        → Top-line growth (ARR, MRR)         │
│   Layer 2: EBITDA         → Operational profitability          │
│   Layer 3: Cash           → Working capital, collections       │
│   Layer 4: FCF            → Free cash flow generation          │
│   Layer 5: Story          → Market narrative, positioning      │
│   Layer 6: Valuation      → Multiple expansion, exit value     │
│                                                                │
│   Tasks → Processes → KPIs → ValuationOps Layers               │
│                                                                │
└────────────────────────────────────────────────────────────────┘

Part 3: Technical Architecture

3.1 System Overview

┌─────────────────────────────────────────────────────────────────┐
│                    JD Analyser Architecture                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   ┌──────────┐     ┌────────────────┐     ┌────────────────┐    │
│   │  User    │────▶│  VitePress     │────▶│  Netlify       │    │
│   │  Browser │     │  Landing Page  │     │  Function      │    │
│   └──────────┘     └────────────────┘     └────────────────┘    │
│                                                 │                │
│                                                 ▼                │
│                                    ┌────────────────────────┐   │
│                                    │  Embedded Task         │   │
│                                    │  Taxonomy (174 tasks)  │   │
│                                    └────────────────────────┘   │
│                                                 │                │
│                                                 ▼                │
│                                    ┌────────────────────────┐   │
│                                    │  Pattern Matching      │   │
│                                    │  Engine                │   │
│                                    └────────────────────────┘   │
│                                                 │                │
│                                                 ▼                │
│                                    ┌────────────────────────┐   │
│                                    │  Structured Analysis   │   │
│                                    │  Report                │   │
│                                    └────────────────────────┘   │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

3.2 The Pattern Matching Engine

Instead of LLM inference, we use deterministic keyword pattern matching:

javascript

const TASK_TAXONOMY = {
  "S-001": {
    title: "Qualify Inbound Leads",
    domain: "sales",
    level: 1,
    description: "Review and qualify incoming leads...",
    keywords: ["qualify", "inbound", "lead", "qualification", "mql", "bant"],
    kpi_links: ["KPI-REV-MQL-01"],
    process_id: "PROC-REV-DEMAND-GEN-01"
  },
  // ... 173 more tasks
};

function matchTasksToJD(jdText) {
  const normalizedJD = jdText.toLowerCase();
  const matches = [];
  
  for (const [taskId, task] of Object.entries(TASK_TAXONOMY)) {
    let score = 0;
    let matchedKeywords = [];
    
    for (const keyword of task.keywords) {
      if (normalizedJD.includes(keyword.toLowerCase())) {
        score++;
        matchedKeywords.push(keyword);
      }
    }
    
    if (score > 0) {
      matches.push({
        taskId,
        ...task,
        score,
        matchedKeywords
      });
    }
  }
  
  return matches.sort((a, b) => b.score - a.score);
}

3.3 Domain Detection & Sorting

The system uses a two-tier approach to determine the primary domain:

Tier 1: Title-Based Detection (Explicit Signals)

javascript

function detectDomainFromTitle(text) {
  const firstLines = text.split('\n').slice(0, 5).join(' ').toLowerCase();
  
  const titlePatterns = {
    marketing: /\b(marketing manager|head of marketing|cmo|demand gen|brand)\b/i,
    sales: /\b(sales manager|head of sales|cro|account executive|ae)\b/i,
    finance: /\b(finance manager|cfo|controller|fp&a|financial analyst)\b/i
  };
  
  for (const [domain, pattern] of Object.entries(titlePatterns)) {
    if (pattern.test(firstLines)) return domain;
  }
  return null;
}

Tier 2: Keyword Volume Scoring (Implicit Signals)

javascript

function determineDomain(matchedTasks, text) {
  const titleSignal = detectDomainFromTitle(text);
  
  const scores = { marketing: 0, sales: 0, finance: 0 };
  matchedTasks.forEach(task => {
    scores[task.domain] += task.matched_keywords.length;
  });
  
  // Title signal adds significant weight
  if (titleSignal) scores[titleSignal] += 3;
  
  return {
    primary: Object.entries(scores).sort((a, b) => b[1] - a[1])[0][0],
    title_signal: titleSignal,
    confidence: scores
  };
}

Tier 3: Domain-Prioritized Sorting

Results are sorted to show primary domain tasks first:

javascript

function sortTasksByDomainRelevance(matchedTasks, primaryDomain) {
  return matchedTasks.sort((a, b) => {
    const aIsPrimary = a.domain === primaryDomain ? 1 : 0;
    const bIsPrimary = b.domain === primaryDomain ? 1 : 0;
    
    if (aIsPrimary !== bIsPrimary) return bIsPrimary - aIsPrimary;
    return b.matched_keywords.length - a.matched_keywords.length;
  });
}

3.4 Why Deterministic > LLM for This Use Case

Aspect	LLM Approach	Deterministic Approach
Cost	$0.01-0.10 per call	$0.00 per call
Consistency	Varies between calls	Same input → same output
Explainability	"The model thinks..."	"Matched keywords: X, Y, Z"
Grounding	Invents skills	Maps to real GFE tasks
Latency	1-5 seconds	<100ms
Offline capable	No	Yes

3.5 Serverless Function Implementation

The Netlify function handles multipart form data (supporting file uploads and text):

javascript

// Key components:
// 1. Busboy for multipart parsing (file + form fields)
// 2. Embedded TASK_TAXONOMY with all 174 tasks
// 3. Pattern matching engine
// 4. Email notification for lead capture (MailerSend)
// 5. Structured JSON response

exports.handler = async (event) => {
  // Parse form data
  const { jdText, company, email, name } = await parseFormData(event);
  
  // Match against taxonomy
  const matchedTasks = matchTasksToJD(jdText);
  
  // Build analysis
  const analysis = buildAnalysis(matchedTasks);
  
  // Send lead notification (non-blocking)
  sendLeadNotification({ company, email, name, matchedTasks });
  
  return {
    statusCode: 200,
    body: JSON.stringify(analysis)
  };
};

Part 4: UI/UX Evolution & Screenshots

4.1 Initial Production Issue

When we first deployed the task-grounded version, we encountered a critical UI problem: the frontend expected different field names than the backend was returning.

The Problem:

Frontend expected: s.skill, s.why, i.name, i.instructions, i.evaluation
Backend returned: s.task, s.match_confidence, i.stage, i.focus, i.what_good_looks_like

This is a common integration issue when backend and frontend evolve separately.

4.2 The V2 Scorecard Design

We redesigned the scorecard to surface the GFE Skill System structure explicitly:

New Information Hierarchy:

┌─────────────────────────────────────────────────────────────────┐
│  📋 Your Hiring Scorecard                                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Role Summary                                                 │
│     └─ "Marketing Role: L3 (Strategist). Key tasks:..."         │
│                                                                  │
│  2. Domain Detection (NEW in v2.2.0)                             │
│     ├─ Primary: marketing                                        │
│     ├─ Title Signal: "Head of Marketing" detected                │
│     └─ Confidence: marketing 10.1, sales 3.4, finance 2.4        │
│                                                                  │
│  3. Detected Level                                               │
│     ├─ Level Badge: L3 – Strategist                              │
│     ├─ Summary: "Owns outcomes across channels..."               │
│     └─ AI Fluency: "Designs AI supported operating models..."    │
│                                                                  │
│  4. Matched Tasks (Domain-Sorted)                                │
│     ├─ Task ID: M-050, M-100, M-103...                          │
│     ├─ Task Name: "Landing Page Optimization"                    │
│     ├─ Domain: marketing (shown first when primary)              │
│     ├─ Level: L2 (Architect)                                     │
│     ├─ Match Confidence: 67%                                     │
│     └─ Matched Keywords: [landing page, conversion, a/b test]    │
│                                                                  │
│  5. Processes Involved                                           │
│     └─ PROC-REV-DEMAND-GEN-01 – Demand Generation                │
│                                                                  │
│  6. ValuationOps Alignment                                       │
│     ├─ Layer: Revenue (High)                                     │
│     ├─ KPIs: ARR/MRR, Pipeline, Win Rate, Bookings              │
│     └─ Why: "marketing roles drive pipeline generation"          │
│                                                                  │
│  7. Weighted Scorecard                                           │
│     └─ Interview scoring criteria with evidence expectations     │
│                                                                  │
│  8. Interview Plan                                               │
│     ├─ Stage: Technical Deep-Dive                                │
│     ├─ Focus: Marketing competency                               │
│     ├─ Format: Case presentation + Q&A                           │
│     └─ What good looks like: "Strategic thinking..."             │
│                                                                  │
│  9. Risk Flags                                                   │
│     └─ Warnings about JD gaps or unrealistic expectations        │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

4.3 Key UI Improvements

Element	Before	After
Skill Column	Empty (wrong field name)	Task ID + Task Name
Why Column	Empty	Match Confidence %
Level Display	None	Full level badge with AI fluency
Domain Detection	None	Title signal + confidence scores
Task Sorting	By match count only	Primary domain first, then by match
Matched Keywords	Not shown	Tags showing which keywords matched
Processes	Not shown	PROC-REV-* codes with names
ValuationOps	Not shown	Layer + KPIs + business impact
Interview Plan	"(Eval: )" empty	Stage/Focus/Format/What-Good-Looks-Like

4.4 Domain-Specific Styling

We added visual cues to help users quickly identify task domains:

css

/* Domain color coding */
.domain-tag.domain-sales { background: #dbeafe; color: #1d4ed8; }
.domain-tag.domain-marketing { background: #fce7f3; color: #be185d; }
.domain-tag.domain-finance { background: #dcfce7; color: #166534; }

/* Level badges */
.level-badge.level-0 { background: #e0f2fe; } /* Apprentice - Light blue */
.level-badge.level-1 { background: #dcfce7; } /* Practitioner - Light green */
.level-badge.level-2 { background: #fef9c3; } /* Architect - Light yellow */
.level-badge.level-3 { background: #fce7f3; } /* Strategist - Light pink */
.level-badge.level-4 { background: #f3e8ff; } /* Partner - Light purple */

Part 5: Analysis Output Structure

5.1 Response Format

The analyser returns a structured response with domain detection:

json

{
  "success": true,
  "version": "2.2.0-domain-sort",
  "domain_detected": {
    "primary": "marketing",
    "title_signal": "marketing",
    "confidence": {
      "marketing": 10.13,
      "sales": 3.43,
      "finance": 2.4
    }
  },
  "scorecard": {
    "role_summary": "Sales Role: L3 (Strategist) in sales. Key tasks: Qualification via DM, Opportunity Scoring...",
    "detected_level": {
      "level": 3,
      "name": "Strategist",
      "summary": "Owns outcomes across channels or stages. Sets direction, prioritises bets...",
      "ai_fluency": "Designs AI supported operating models for the team..."
    },
    "skill_requirements": [
      {
        "task_id": "M-050",
        "task": "Landing Page Optimization",
        "domain": "marketing",
        "level": "L2 (Architect)",
        "match_confidence": "67%",
        "matched_keywords": ["landing page", "conversion", "optimization", "a/b test"]
      }
    ],
    "processes_involved": [
      {
        "id": "PROC-REV-DEAL-CLOSING-01",
        "name": "Pipeline Management",
        "domain": "sales"
      }
    ],
    "valuation_ops_alignment": [
      {
        "layer": "Revenue",
        "relevance": "High",
        "kpis": ["ARR/MRR", "Pipeline", "Win Rate", "Bookings"],
        "why": "sales roles directly impact top-line growth"
      }
    ],
    "scorecard": [
      {
        "item": "Qualification via DM",
        "task_id": "S-103",
        "weight": 16,
        "expected_level": "L3 (Strategist)",
        "evidence": "Qualification via DM portfolio, past results documentation"
      }
    ],
    "interview_plan": [
      {
        "stage": "Technical Deep-Dive",
        "focus": "Sales competency",
        "format": "Case presentation + Q&A",
        "tasks_to_probe": ["S-103", "S-111"],
        "what_good_looks_like": "Strategic thinking, trade-off reasoning, outcome ownership"
      }
    ],
    "risk_flags": [
      "Senior role but no budget/P&L authority mentioned",
      "Management implied but team size not specified"
    ]
  }
}

4.2 Level Inference Logic

The system infers seniority based on matched task levels:

javascript

function inferSeniority(matchedTasks) {
  const levelCounts = { 0: 0, 1: 0, 2: 0, 3: 0, 4: 0 };
  
  matchedTasks.forEach(task => {
    levelCounts[task.level]++;
  });
  
  // Weight higher-level tasks more heavily
  const weightedScore = 
    levelCounts[0] * 1 +
    levelCounts[1] * 2 +
    levelCounts[2] * 4 +
    levelCounts[3] * 8 +
    levelCounts[4] * 16;
  
  const avgLevel = weightedScore / matchedTasks.length;
  
  // Map to level range
  if (avgLevel < 1.5) return "L0-L1 (Apprentice to Practitioner)";
  if (avgLevel < 3) return "L1-L2 (Practitioner to Architect)";
  if (avgLevel < 6) return "L2-L3 (Architect to Strategist)";
  return "L3-L4 (Strategist to Partner)";
}

Part 6: Development Journey

6.1 Phase 1: LLM-Based Approach (Failed)

Initial Implementation:

Used Gemini API to analyze JDs
Prompt engineering to extract "skills"
Hit rate limits immediately (429 errors)
Free tier quota exhausted in testing

Lesson Learned: LLMs are expensive for high-volume, deterministic tasks.

6.2 Phase 2: Deterministic with Invented Skills (Wrong)

Second Attempt:

Created pattern matching with arbitrary skill clusters
Used generic level names (Observer, Executor, Expert)
No connection to actual GFE specifications

Lesson Learned: We were reinventing what already existed.

6.3 Phase 3: Grounded in GFE Specs (Correct)

Third Implementation:

Studied actual GFE Skill System specs
Extracted all 174 tasks with metadata
Embedded complete taxonomy in function
Used real level names (Apprentice → Partner)
Connected tasks to processes, KPIs, ValuationOps

Key Insight: Don't abstract—ground in reality.

6.4 Phase 4: Frontend-Backend Alignment (Current)

Production Issue Discovered: When deployed, the scorecard showed empty columns and broken interview plans (see Figure 1 above).

Root Cause:

Backend field names changed but frontend wasn't updated
Classic "contract drift" between API and UI

Fix Applied:

Updated frontend to expect new field structure
Added new UI sections: Detected Level, Processes, ValuationOps
Added domain color coding and level badges
Improved interview plan display with "What Good Looks Like"

Lesson Learned: Always test the full integration path, not just the API response.

6.5 Phase 5: Domain-Sorted Results (Current)

Problem Discovered: After fixing the frontend display, a new issue emerged: cross-domain keyword pollution. When analyzing a "Head of Marketing" JD, sales tasks like "Advocate Nomination" and "Key Account VIP" were appearing at the top of results because they shared generic keywords with marketing.

Example of the Issue:

Marketing JD → Top Results:
1. Advocate Nomination (sales) - 71%   ❌ Wrong domain!
2. Key Account VIP (sales) - 57%       ❌ Wrong domain!
3. Board Reporting (finance) - 43%     ❌ Wrong domain!

Root Cause Analysis:

Task	Original Keywords	Problem
S-200: Advocate Nomination	`advocate, forecast, commit, pipeline`	"advocate" matches brand advocates
S-301: Lead Magnet Conversion	`landing page, conversion, a/b test`	Marketing uses these terms too
S-210: Key Account VIP	`key account, executive sponsor, qbr`	"QBR" generic in enterprises

Three-Part Solution:

1. Title-Based Domain Detection

javascript

function detectDomainFromTitle(text) {
  const firstLines = text.split('\n').slice(0, 5).join(' ').toLowerCase();
  
  // Explicit title signals
  if (/\b(marketing manager|head of marketing|cmo|marketing director|
        demand gen|brand manager|content lead)\b/i.test(firstLines)) {
    return 'marketing';
  }
  if (/\b(sales manager|head of sales|cro|sales director|
        account executive|ae manager|vp sales)\b/i.test(firstLines)) {
    return 'sales';
  }
  if (/\b(finance manager|cfo|controller|fp&a|financial analyst|
        head of finance)\b/i.test(firstLines)) {
    return 'finance';
  }
  return null;
}

2. Cross-Domain Keyword Refinement

Task	Before	After
S-200	`advocate, forecast, commit, pipeline`	`customer advocate, sales reference, deal support, champion`
S-301	`landing page, conversion, a/b test`	`sales landing page, sales conversion, demo request`
S-210	`key account, executive sponsor, qbr`	`named accounts, executive sponsor, qbr revenue, strategic account`
S-111	`email campaign, nurture, follow-up`	`sales email, outbound sequence, cold email, follow-up cadence`

3. Domain-Prioritized Sorting

javascript

function sortTasksByDomainRelevance(matchedTasks, primaryDomain) {
  return matchedTasks.sort((a, b) => {
    // Primary domain tasks first
    const aIsPrimary = a.domain === primaryDomain ? 1 : 0;
    const bIsPrimary = b.domain === primaryDomain ? 1 : 0;
    
    if (aIsPrimary !== bIsPrimary) {
      return bIsPrimary - aIsPrimary;
    }
    
    // Within same domain, sort by match count
    return b.matched_keywords.length - a.matched_keywords.length;
  });
}

Results After Fix:

Marketing JD → Top Results:
1. Landing Page Optimization (marketing) - 67%   ✅
2. Demand Generation Strategy (marketing) - 60%  ✅
3. MQL to SQL Conversion (marketing) - 43%       ✅
4. Marketing Automation (marketing) - 44%        ✅
5. Marketing Leadership (marketing) - 33%        ✅
6. Campaign Performance (marketing) - 38%        ✅

Key Insight: Domain sorting is as important as keyword matching. Users expect marketing roles to surface marketing tasks first.

6.6 Technical Challenges Solved

Challenge	Solution
SSR hydration errors	Client-side only form rendering
Multipart file parsing	Busboy library for Node.js
Email notification failures	Properly awaited async fetch calls
Level name confusion	Direct mapping from spec JSON files
Keyword coverage	Expanded keywords from task descriptions
Frontend-backend mismatch	Field name alignment + new UI components
Empty UI fields	Proper null checking and fallback values

Part 7: Business Value & Use Cases

7.1 Primary Use Cases

Hiring Managers: Analyze JDs to ensure role clarity and appropriate leveling
Recruiters: Map candidate experience to GFE task competencies
HR Teams: Standardize job architecture across the organization
Candidates: Understand role expectations in GFE taxonomy terms

7.2 Integration Points

The JD Analyser can integrate with:

ATS Systems: Auto-tag roles with GFE task IDs
Performance Management: Link role to expected KPI contributions
Learning Platforms: Generate training paths based on task gaps
Compensation Frameworks: Level-based pay bands

7.3 Lead Generation Value

Every analysis submission captures:

Company name
Contact email
Role type being analyzed
Matched task profile

This enables targeted outreach for GrowthFlow Engineering consulting services.

Part 8: Future Roadmap

8.1 Planned Enhancements

Feature	Status	Impact
PDF resume parsing	Planned	Match candidates to tasks
Batch JD analysis	Planned	Analyze entire job architecture
Gap analysis	Planned	Compare JD to ideal role profile
Process recommendations	In Progress	Suggest missing process coverage
Multilingual support	Planned	Support DE, FR, ES JDs

8.2 Integration Opportunities

GrowthQuiz: Connect to growth mindset assessment
Skill Builder: Generate training recommendations
Team Planner: Analyze team composition against task coverage

Appendix A: Complete Task Reference

Marketing Tasks (67 total)

ID	Title	Level
M-001	Clean Contact Lists	L0
M-002	Schedule Social Posts	L0
M-003	Monitor Campaign Metrics	L1
M-004	Create Landing Pages	L1
M-005	Design Email Templates	L1
...	...	...

Sales Tasks (69 total)

ID	Title	Level
S-001	Qualify Inbound Leads	L1
S-002	Conduct Discovery Calls	L1
S-003	Prepare Proposals	L1
S-015	Negotiate Contract Terms	L2
S-030	Manage Key Accounts	L2
...	...	...

Finance Tasks (38 total)

ID	Title	Level
F-001	Process Invoices	L0
F-002	Reconcile Accounts	L1
F-012	Prepare Variance Reports	L1
F-025	Build Financial Models	L2
F-035	Lead Budget Planning	L3
...	...	...

Full task specifications available in the GFE Skill System repository.

Appendix B: API Reference

Endpoint

POST https://growthflowengineering.xyz/.netlify/functions/jd-analyser

Request (multipart/form-data)

Field	Type	Required	Description
jdText	string	Yes	Job description text
company	string	Yes	Company name
email	string	Yes	Contact email
name	string	No	Contact name
jdFile	file	No	JD file (PDF/DOCX)

Response

json

{
  "success": true,
  "analysis": {
    "summary": { ... },
    "matchedTasks": [ ... ],
    "recommendations": { ... }
  }
}

Conclusion

The GFE JD Analyser demonstrates a fundamental principle: grounded systems beat generic AI.

By embedding the actual GFE Skill System taxonomy—174 tasks, 44 processes, 5 levels—we created a tool that:

Costs nothing to run (no LLM API calls)
Produces consistent results (deterministic matching)
Explains its reasoning (shows matched keywords)
Connects to business value (tasks → processes → KPIs → ValuationOps)
Respects context (domain-sorted results show marketing tasks for marketing roles)

The v2.2.0 domain-sorting update solved a critical UX problem: cross-domain keyword pollution. By combining title-based detection with domain-prioritized sorting, the system now surfaces the most relevant tasks first—even when generic keywords match across multiple domains.

This is the future of domain-specific AI: systems grounded in real taxonomies, not black-box models inventing skills on the fly.

Try the JD Analyser

Analyse Your Job Description →

Get instant insights into role requirements mapped to the GFE Skill System.

For questions or partnership inquiries, contact the GrowthFlow Engineering team.

EdTech Overview

Building a Deterministic JD Analyser: Grounded in the GFE Sk### 6.6 Technical Challenges Solved ​

Executive Summary ​

Part 1: The Problem Space ​

1.1 Traditional JD Analysis Approaches ​

1.2 The Key Insight ​

Part 2: The GFE Skill System Deep Dive ​

2.1 The Five Levels ​

2.2 The LEO Framework ​

2.3 The 174 Tasks ​

2.4 The 44 Processes ​

2.5 ValuationOps Layers ​

Part 3: Technical Architecture ​

3.1 System Overview ​

3.2 The Pattern Matching Engine ​

3.3 Domain Detection & Sorting ​

3.4 Why Deterministic > LLM for This Use Case ​

3.5 Serverless Function Implementation ​

Part 4: UI/UX Evolution & Screenshots ​

4.1 Initial Production Issue ​

4.2 The V2 Scorecard Design ​

4.3 Key UI Improvements ​

4.4 Domain-Specific Styling ​

Part 5: Analysis Output Structure ​

5.1 Response Format ​

4.2 Level Inference Logic ​

Part 6: Development Journey ​

6.1 Phase 1: LLM-Based Approach (Failed) ​

6.2 Phase 2: Deterministic with Invented Skills (Wrong) ​

6.3 Phase 3: Grounded in GFE Specs (Correct) ​

6.4 Phase 4: Frontend-Backend Alignment (Current) ​

6.5 Phase 5: Domain-Sorted Results (Current) ​

6.6 Technical Challenges Solved ​

Part 7: Business Value & Use Cases ​

7.1 Primary Use Cases ​

7.2 Integration Points ​

7.3 Lead Generation Value ​

Part 8: Future Roadmap ​

8.1 Planned Enhancements ​

8.2 Integration Opportunities ​

Appendix A: Complete Task Reference ​

Marketing Tasks (67 total) ​

Sales Tasks (69 total) ​

Finance Tasks (38 total) ​

Appendix B: API Reference ​

Endpoint ​

Request (multipart/form-data) ​

Response ​

Conclusion ​

Try the JD Analyser ​

Building a Deterministic JD Analyser: Grounded in the GFE Sk### 6.6 Technical Challenges Solved

Executive Summary

Part 1: The Problem Space

1.1 Traditional JD Analysis Approaches

1.2 The Key Insight

Part 2: The GFE Skill System Deep Dive

2.1 The Five Levels

2.2 The LEO Framework

2.3 The 174 Tasks

2.4 The 44 Processes

2.5 ValuationOps Layers

Part 3: Technical Architecture

3.1 System Overview

3.2 The Pattern Matching Engine

3.3 Domain Detection & Sorting

3.4 Why Deterministic > LLM for This Use Case

3.5 Serverless Function Implementation

Part 4: UI/UX Evolution & Screenshots

4.1 Initial Production Issue

4.2 The V2 Scorecard Design

4.3 Key UI Improvements

4.4 Domain-Specific Styling

Part 5: Analysis Output Structure

5.1 Response Format

4.2 Level Inference Logic

Part 6: Development Journey

6.1 Phase 1: LLM-Based Approach (Failed)

6.2 Phase 2: Deterministic with Invented Skills (Wrong)

6.3 Phase 3: Grounded in GFE Specs (Correct)

6.4 Phase 4: Frontend-Backend Alignment (Current)

6.5 Phase 5: Domain-Sorted Results (Current)

6.6 Technical Challenges Solved

Part 7: Business Value & Use Cases

7.1 Primary Use Cases

7.2 Integration Points

7.3 Lead Generation Value

Part 8: Future Roadmap

8.1 Planned Enhancements

8.2 Integration Opportunities

Appendix A: Complete Task Reference

Marketing Tasks (67 total)

Sales Tasks (69 total)

Finance Tasks (38 total)

Appendix B: API Reference

Endpoint

Request (multipart/form-data)

Response

Conclusion

Try the JD Analyser