DEV Community: HR Pulsar

HRPulsar v1.15: Self-Hosted HR Management Goes Open Source (With Full Docker Support)

HR Pulsar — Mon, 27 Jul 2026 13:59:21 +0000

HRPulsar v1.15: Self-Hosted HR Management Now Fully Open

HRPulsar v1.15 is out, and for the first time, self-hosted deployment is a first-class citizen—not an afterthought bolted onto a SaaS product.

What's New in v1.15

White-Label Everything

LOGO_URL=https://...
INSTALL_NAME="Acme HR"
ACCENT_COLOR="#FF6B35"
FAVICON_URL=https://...

Configure logo, installation name, accent colors, and favicon via environment variables. Show up in your company's UI and in every outgoing email. Build HR ops that feel like your product, not something bolted on.

2. Docker That Actually Works

We fixed everything that usually breaks:
✅ Build contexts
✅ Celery command configurations
✅ Health checks
✅ Ready-made Caddyfile included
✅ MinIO auto-setup on first boot
Pull, docker-compose up, and go. No hunting through docs for missing configs.

3. Self-Serve Registration (No Email Required)

Self-hosted teams don't always have email infrastructure ready. v1.15 handles this:

Self-serve signup works standalone
Verification fallbacks when SMTP isn't configured
Your team gets in without waiting for IT

4. Complete Transparency

Full AGPLv3 license included
CONTRIBUTING.md for developers
SECURITY.md for peace of mind

No closed-source components or surprise licensing. You absolutly own what you run.

Why This Matters

The enterprise HR software market is consolidating around a few mega-platforms. Meanwhile, startups and mid-market companies:

Don't want vendor lock-in
Can't afford $500K+ annual contracts
Need to keep their people data actually private
Want to customize workflows without a 6-month implementation

HRPulsar solves this. It's infrastructure, not a service.

Who's This For?

Startups (0–250 people). If your team is growing fast, you probably don’t want a rigid HR stack that slows everything down. You need something you can shape around your process.
Teams with compliance needs. If you work in healthcare, finance, or any regulated industry, keeping sensitive data on your own infrastructure isn’t a nice-to-have — it’s the point.
Developers and CTOs. Deploy it like any other app. Monitor it. Modify it. Deploy again.
Anyone skeptical of SaaS. If you’re done with hidden limits, surprise bills, and vendors holding your data hostage, self-hosted starts to make a lot more sense.

Getting Started

Clone the repo: git clone https://github.com/hrpulsar/hrpulsar
Run with Docker: docker-compose up
Visit: http://localhost:3000
Deploy anywhere: Your server, your cloud, your on-prem infra
Full docs and contributing guidelines are in the repo.

Join Us
We're building this in public. Your feedback shapes the roadmap.

Try it free → https://github.com/hrpulsar/hrpulsar
Give it a star if you believe in open HR ops
Open an issue if something breaks or you have ideas
Contribute — we have a CONTRIBUTING.md ready for you

The future of HR software doesn't have to be rented from a mega-vendor. It can be built by and for the teams that use it.
Let's build it together.

Measuring AI Skills: What Actually Works

HR Pulsar — Mon, 13 Jul 2026 12:03:36 +0000

You deployed an AI agent last quarter. Your CTO swears it's saving time. Your finance team wants numbers. Your team says "it feels faster" but can't prove it. Meanwhile, you're getting hit with questions you can't answer:

— How do we know if this thing is actually working?
— Is 79% task completion rate good or bad?
— Why is our code review queue getting longer when we're shipping faster?

If you're nodding along, you're not alone. We found that 88% of tech leaders claim to measure AI impact, but when you dig deeper, only 39% actually have formal, automated processes to back it up. The rest are guessing—and worse, they're guessing with confidence.

After working with teams across HR and engineering automation for two years, we've learned that most AI measurement fails because people measure the wrong things. You end up with metrics that feel accurate but don't predict anything real, or you get drunk on one number (acceptance rate, task completion) and miss the actual problems happening downstream.

So we're sharing the framework we use internally. It's built on three dimensions that matter: output quality, speed, and autonomy. Nothing revolutionary, but the combination and how you measure them together is where things change.

Part 1: The Measurement Crisis Nobody Talks About

Your GitHub Copilot dashboard shows:

✓ 45% acceptance rate
✓ 2.4 hours saved per developer per week
✓ 1,200 code suggestions per engineer monthly

Your engineering team shipped 34% more pull requests YoY. Your CFO asks: "But did we ship better code? Faster cycles? Did anything break?". And it makes big question

This gap between activity and outcome is the real problem. Headlines promise "2x productivity improvements" and "30% of code written by AI," but these claims rarely match what organizations experience on the ground. Without robust measurement frameworks, you're left making critical investment decisions based on vendor marketing rather than data.

The mechanical issue: Developers use AI in fragmented ways—they might write code with GitHub Copilot in their IDE, brainstorm using ChatGPT, and use Claude for documentation, all within the same hour. DX's longitudinal analysis identified five structural reasons why AI productivity gains are lower than expected: Coding represents only ~14% of a developer's day, so accelerating it yields modest overall gains. AI speeds up code generation, but creates new bottlenecks in review and integration.

The honest truth? Developers report saving nearly 4 hours a week. But those savings aren't showing up proportionally in throughput. The gap between perceived productivity and measured output is itself a signal. It suggests developers are reinvesting AI-generated time into work that doesn't produce PRs: deeper thinking, better architecture, harder problems.

So your first mistake might be expecting AI to show up as a straight productivity multiplier. It doesn't work that way. Instead, what you get is a reorganization of where the work happens.

Part 2: The Three-Dimension Framework

We use three independent dimensions because they fail independently. If one fails, you catch it. If you only measure one or two, you ship broken code confidently.

1. Output Quality

This is the hardest to measure because quality is contextual. "This is good" is subjective until you define what good means for your specific system.

What to actually track:

Goal Completion Rate (GCR). Percentage of tasks the agent finished correctly on the first try. The most fundamental measure of agent effectiveness, GCR directly answers the question: "Does the agent accomplish what it was asked to do?" Unlike intermediate metrics such as token count or latency, GCR focuses on the final outcome.
Tool Selection Quality. Whether the agent picked the right tool for the right job, with the right parameters. Tool Selection Quality measures whether an agent selects correct tools with appropriate parameters. Poor tool selection cascades into downstream failures that broader operation metrics may not catch. This is crucial because in HR systems, a poorly selected data source leads to silent failures—the report runs, but the data is wrong.
Reasoning Quality. Can the agent explain why it made a decision? Better agents admit uncertainty. Reasoning quality includes knowing what the agent doesn't know. A well-designed agent admits uncertainty rather than fabricating answers. This is particularly challenging in the LLM where models are trained to produce answers no matter what.
Domain-Specific Correctness. In HR systems, this means: did the competency mapping work? Were the skill matches accurate? Did the salary band recommendation align with market data? You need 3-5 business experts to spot-check outputs, not an automated metric.

LLM benchmarks are standardized tests that assess LLM performance across various tasks. Typically, they check if the model can produce the correct known response to a given input. Common LLM benchmarks test models for skills like language understanding, question-answering, math problem-solving, and coding tasks. But the right benchmark for your system is usually custom. We built SkillsBench-like evaluations for competency models that none of the public benchmarks cover.

A real example:

We evaluated HR agents on 200 employee records with known skill classifications. The agent's GCR was 84%. But when we broke down by complexity tier: simple classifications (87%), complex cross-functional skill mapping (71%), ambiguous cases (64%). That breakdown matters more than the headline 84%.

2. Speed

This one seems obvious but people measure it wrong. Speed isn't latency. It's throughput under constraints.

What to actually track:

Latency Percentiles (p50, p95, p99): Not average. Percentiles. Performance metrics track how the system behaves moment by moment: Latency percentiles (p50, p95, p99), throughput, and error rates. If your p99 latency is 8 seconds, p50 is 200ms, and someone is making decisions based on average (500ms), you're lying to yourself. Your worst-case users are the ones who matter.
Token Efficiency: How many tokens did the agent burn to complete the task? Cost is throughput. If an agent saves 30 minutes but uses 50k tokens (≈ $0.50 per execution), and you run it 100 times a day, that's $50/day, $1,500/month. That's not free time, that's a cost you moved around. Measure it.
End-to-End Time to Resolution: How long from "agent receives task" to "human can act on result"? This includes review loops. If your agent generates a report in 2 seconds but it takes 15 minutes to review, the relevant metric is 15+ minutes, not 2 seconds.
Concurrency Limits: Can the agent handle 100 parallel requests or does it degrade at 10? Autonomy introduces variability that must be controlled through evaluation. Performance metrics alone do not ensure responsible behavior; evaluators must measure safety, guideline adherence and compliance with domain rules. Testing at scale is where systems break.

The J-curve Effect:

The J-curve effect describes an initial productivity decline followed by eventual improvement as teams adopt AI coding tools. When you first deploy an AI system, speed often drops because humans need time to learn it, set it up properly, and build confidence. The metrics tank for 3-6 weeks. If you bail out then, you never reach the upside.

3. Autonomy

Here's where most frameworks fall apart. Autonomy is usually framed as "yes/no"—the agent either makes decisions alone or it doesn't. That's wrong.

Autonomy is a spectrum, and different levels have different failure modes and costs.

What to actually track:

Autonomy Index (AIx): Proportion of task steps completed without human intervention. Autonomy Index is defined as the proportion of task steps completed without human intervention. True autonomy is a key promise of AI agents.
Escalation Rate: How often does the agent hit a situation it can't handle and needs to escalate to a human? This is your feedback loop. Escalation is not failure—unrecognized escalation is failure. An agent that silently fails is worse than one that asks for help.
Human Intervention Hours Saved: Executive metric: Human intervention hours saved. Not "tasks completed" but specifically hours that didn't require human review or rework.
Decision Confidence: Is the agent's confidence score correlated with actual correctness? If the agent says "I'm 95% confident" and is wrong 40% of the time, the confidence metric is useless. You need to track: given high-confidence outputs, what's the error rate? Given low-confidence outputs, what's the error rate? Are they different?
Handoff Quality: When the agent escalates, how much context does it provide? A good handoff means a human can pick it up in 30 seconds. A bad one takes 5 minutes to understand. Handoff quality is harder to measure than binary escalation rate, but it's more useful.

Case study from our work:
An HR agent we built for skills mapping could work autonomously on 68% of employee records (high AIx). But when it escalated, it provided zero context—just "couldn't classify." Humans spent 10 minutes per escalation digging through the record to understand why. We added structured escalation logging and that fell to 2 minutes. The AIx didn't change, but human time per request dropped 60%.

Part 3: How to Measure These Together

Here's the trap: optimize for one and you'll wreck the others.

Optimize for quality alone?
Your agent becomes risk-averse, escalates constantly, AIx drops to 20%. Technically high quality. Practically useless.

Optimize for speed alone?
You get fast garbage. Quality craters, error rates spike, human review time multiplies.

Optimize for autonomy alone?
You get an agent that confidently makes wrong decisions independently. The worst outcome.

The right approach is to set constraints on each, not targets.

Example constraints for an HR agent:

Quality: GCR ≥ 85% on monthly test set
Speed: p99 latency ≤ 3 seconds, token cost ≤ $0.20 per task
Autonomy: AIx ≥ 70%, escalation rate ≤ 20%

Now you measure: "Are we satisfying all three constraints?" If yes, you're good. If one breaks, you've got a specific problem to solve.

Measurement in practice:

Define your constraints (not targets) for quality, speed, autonomy based on your business. For HR systems, "quality is non-negotiable because wrong competency mappings cascade into hiring decisions." So constraint GCR ≥ 88%. For speed, "we don't need sub-second because this is async reporting." So constraint p95 ≤ 5 seconds. For autonomy, "our HR team is small, we need AIx ≥ 75%." So that's your constraint.
Measure baseline (pre-AI state). How long did the work take? What quality? How much human involvement? Baseline is your control group.
Run A/B or gradual rollout, not big-bang. Start with 5 developers on a specific use case. Measure time savings rigorously. Scale only after proving value. Same applies to any AI system. Test on 10% of actual work first.
Measure continuously. Not quarterly dashboards. Weekly reviews of your constraints. Monthly deep-dives into failure modes.
Track ROI separately from performance. Utilization: How developers adopt and use AI tools. Impact: How AI affects productivity, quality, and developer experience. Cost: Whether AI spending delivers positive return on investment. The framework provides research-based metrics across three dimensions that mirror the typical adoption journey. These are independent. You can have great performance (quality/speed/autonomy) but negative ROI if costs are high enough.

Part 4: The Measurement Pattern You're Probably Missing

McKinsey's 2025 State of AI report found that 88% of organizations have adopted AI, but only 39% can report any EBIT impact. That's not because the AI isn't working. It's because people are measuring activity (we deployed it), not outcome (it changed business metrics).

The three-layer measurement problem:

Layer 1 (What nobody skips): Adoption
How many people are using it? How often? This is easy to measure. It's also almost useless for ROI.

Layer 2 (What most teams measure): Output
How much did the system produce? Tasks completed, reports generated, lines of code written. This feels meaningful because there are big numbers. It's still not ROI.

Layer 3 (What almost nobody measures): Outcome
Did any of this actually matter to the business? Did it change cycle time, quality, revenue, retention? This is where ROI lives.

The actual ROI question is cross-enterprise: which teams adopted which tools, what changed in their output, and did any of it move a business metric? That question requires connecting three dots: adoption data (who's using what), productivity signals (what changed in their work), and business outcomes (did it matter).

For HR specifically:

❌ Layer 1: "We deployed a skills agent, 400 employees used it"
❌ Layer 2: "It processed 2,000 skill assessments"
✅ Layer 3: "Those assessments reduced time-to-hire in engineering by 3 days and improved internal mobility match rates from 62% to 71%"

Only Layer 3 matters. Get there.

Part 5: The Honest Risks (And How We Handle Them)

There are three things that regularly go wrong, and no framework fixes them completely. You have to know they're coming.

Risk 1: The Hallucination Trap

An AI agent confidently generates wrong data. The report looks official. Nobody questions it until it's too late. AI agents fail in repeatable ways that differ from traditional model errors because they emerge from interaction, sequencing and state. Hallucinated tool calls occur when an agent invents tools, parameters or APIs that do not exist, often passing superficial validation while failing at execution time.

How we handle it: We require explicit verification steps. For HR agents, every output that goes into a system of record passes through a secondary check—either automated rules validation or human review. The agent doesn't know this is happening, but it's non-negotiable for downstream systems.

Risk 2: The Context Cliff

An agent works great on clean, well-structured data. Real-world data is 60% edge cases. The agent's performance tanks when you ship it. Configure AI tools with project-specific context before expecting results. Teams skipping this step report frustration and abandonment.

How we handle it: We test on representative data, not synthetic. If your HR system has 5% of records with incomplete information, your test set needs 5% incomplete records too. Otherwise you're lying about what the agent can do.

Risk 3: The ROI Drift

You measure ROI positive at 6 months. By month 12, the cost structure changed (pricing went up), adoption plateaued, or rework increased (because the agent's suggestions started getting worse). ROI looks different now.

How we handle it: ROI is not measured once. Most organizations achieve satisfactory ROI within 2–4 years. This exceeds typical technology payback periods of 7–12 months. We track quarterly, not annually. Costs and benefits change, metrics drift, and you need to catch it early.

Part 6: Building Your Measurement System

You don't need fancy software. You need discipline.

Minimum viable measurement system:

1. Baseline (Week 1)
   └─ Pre-AI performance on quality/speed/autonomy

2. Weekly metrics (ongoing)
   ├─ Quality: Sample 20 outputs, check GCR, tool selection
   ├─ Speed: P50, P95, P99 latency, token costs
   └─ Autonomy: Escalation rate, AIx, handoff quality

3. Monthly review (first Friday of month)
   ├─ Are we meeting constraints?
   ├─ What failed? Why?
   └─ Do we need to adjust?

4. Quarterly business review (end of quarter)
   ├─ Impact on business metrics (time-to-hire, cost-per-hire, etc.)
   ├─ ROI calculation (savings - costs)
   └─ Go/no-go for expansion

Tools you actually need:

Spreadsheet (yep, that's it for small teams)
OR: monitoring platform if you have 10+ agents (we use custom dashboards for complex systems)
Alerting if a constraint breaks (Slack notification is fine)

That's the operational system. Now for the harder part:

The cultural system:

You need one person who owns the truth. Not whoever launched the project, but someone who measures independently and reports numbers that make people uncomfortable. This is unpopular but necessary. Formality, actual numbers, and longitudinal data are often lacking. Pressure from the board keeps increasing, so it's paramount that teams are able to provide that data.

You need to accept that the numbers will sometimes be bad. Somewhere between pilot and production, the reality of the work (data quality challenges, integration complexity, and unclear ROI) caught up with the enthusiasm. When that happens, you don't hide it. You debug it.

Part 7: One More Framework—For Comparing Agents

If you're evaluating multiple AI solutions (Copilot vs. Cursor, different HR frameworks, custom vs. off-the-shelf), you need a comparison framework.

Robust assessment of agents requires a systematic approach that goes beyond simply running an arbitrary selection of standard benchmarks. Practitioners need to make deliberate choices about which benchmarks to use, and need to understand the limitations of the validity of these benchmarks such that the results inform decision making rather than mislead it.

Single-dimension comparisons are noise. "Agent A is 15% faster than Agent B" means nothing if you don't know if quality degraded and autonomy dropped.

Compare across all three dimensions:

Agent	Quality (GCR)	Speed (P95ms)	Autonomy (AIx)	Token Cost/Task	ROI
Agent A	87%	2,400	72%	$0.18	4.2x
Agent B	91%	4,100	68%	$0.24	3.1x
Agent C	79%	1,200	85%	$0.12	2.8x

Now you see: A is the balanced play. B is high-quality but slow and expensive. C is fast and cheap but low quality and risky.

Your choice depends on what you constrained. If quality is non-negotiable (hiring, compensation decisions), B might be worth the cost and speed tradeoff. If speed matters more (daily tasks), C might work. If you need balance, A.

The Bottom Line

Teams establishing evaluation practices during experimental stages experience 60% fewer implementation delays when scaling, while organizations without mature evaluation frameworks systematically underestimate production risks.

Measure early. Measure continuously. Measure three dimensions, not one.

The teams that win with AI aren't the ones who deploy first. They're the ones who measure accurately.

Appendix: For the Builders

If you're building AI systems (agents, assistants, automation), you're accountable for measurement from day one.

In your spec document, before you write code:

Define quality constraints
Define speed constraints
Define autonomy constraints
Define how you'll measure each

In your CI/CD:

Automated quality checks (does the agent's output meet GCR threshold on test set?)
Performance monitoring (are we within latency and token budgets?)
Autonomy tracking (are escalations within expected range?)

In your production deployment:

Weekly metrics review
Monthly retrospective on failures
Quarterly business impact assessment

This isn't extra work. This is the work. Without it, you're shipping blind.

And yes, HRPulsar does this from the first line of code. We've learned the hard way that measurement is not a post-launch nicety—it's a launch requirement.

What's your biggest measurement challenge with AI systems? Drop it in the comments. We read them.

Why AI Agents Have Become a Core Feature: Analyzing the Pricing Strategies of Lattice and Its Competitors

HR Pulsar — Tue, 16 Jun 2026 15:26:56 +0000

2025 - the Moment Everything Changed
An HR director opens the Lattice dashboard. They notice the AI-powered functionality and think, "Okay, that's a nice feature."
Then they see the invoice. Then they put their face in their hands.

Six months later, that same HR director looks at a competitor whose AI features are included in the base plan by default. No extra fees. No separate "AI Package." It's just there.

That's not a coincidence. It's a signal that a paradigm shift has taken place.

What Happened: AI Stopped Being Optional

A few years ago, AI in HR software was positioned as a premium feature.
A luxury add-on. Something like leather seats in a car—nice to have, but not essential.
Companies paid $50–100 per employee per year for core functionality (assessments, PDPs, organizational structures) and viewed AI as an exotic extra.

Lattice was one of the first major players to recognize where things were headed.

In 2024–2025, Lattice made a move that only looks rational if you understand what comes next: They embedded AI directly into their entry-level plan.
Not as a separate "AI Premium" package. Not as an add-on. Into the plan that everyone pays for. At first glance, it looked irrational. Why reduce average revenue per user when you could sell AI as an additional module?

Because the base plan stops being attractive without AI.

Why It Happened So Quickly: The Vocational School Effect

By 2026, every employee uses between three and eight AI tools as part of their daily work.
This isn't a hypothesis. It's an observable reality: ChatGPT. Claude. Perplexity. GitHub Copilot. Specialized internal bots. People have become accustomed to AI being part of the background fabric of work itself.

Now imagine an employee opening a talent management system that feels like a web application from 2015. No AI. No assistant. No personalized recommendations.

When someone has Claude in one tab and your system offers checkboxes in a form, that's not a contrast. It's incompatibility.

Lattice understood this. If they didn't integrate AI into the core product, customers would eventually move to someone who did.
This wasn't a marketing decision. It was a survival decision for the category.

Pricing Strategy: How This Changes ROI

Let's talk about the economics.
The Old Model (2020–2023)

Base Tier: $50/user/year
└─ Оценки, PDP, org structure

Premium Tier: $100/user/year
└─ + Аналитика, интеграции

AI Add-on: +$30/user/year (опция)
└─ Рекомендации по развитию, автоматизация ревью

The problem: Only 10–15% of customers paid for the AI add-on.
Most customers chose the base plan and stayed there.

The New Model (2025–2026)

Base Tier: $65/user/year
└─ Assessments, PDPs, organizational structure,
   AI assistant included by default

Premium Tier: $130/user/year
└─ + Advanced analytics,
   Custom LLM,
   Enterprise integrations

At first glance, ARPU appears to decline in the base tier. It looks like a strategic mistake.

In reality, it was cross-subsidization.

Here's what actually happened:
1. Reduced Churn Customers who previously viewed AI as too expensive no longer needed to make a separate purchasing decision. Retention improved by 40–50%.

2. A Clear Upgrade Path Customers experienced AI in the base plan and started asking: "What could we do with even better recommendations?". Conversion from Base to Premium increased by 2–3x.

3. The Data Network Effect When everyone uses AI, more data is generated. More data improves machine learning models. Better models produce better recommendations. Better recommendations improve the product. It's a self-reinforcing cycle.

4. A Market Signal The message is straightforward: "Without AI, you're no longer competitive." That puts pressure on Workday, Personio, and everyone else in the category.

Real ROI for Customers
Previously:

The system helped users fill out assessment forms.
PDPs were created manually by managers (4–6 hours per employee annually).
Leveling and grading required HR meetings (40–80 hours annually per team).

Now, with AI included in the base plan:

AI generates assessment drafts (30 minutes instead of 2 hours).
AI recommends PDP items based on competencies (saving roughly 3 hours per employee).
AI suggests grade levels with supporting rationale (reducing alignment time by about 50%).

For a team of 100 employees, that's 250–300 hours saved per year. At an HR labor cost of $50–100 per hour, that's $12.5K–30K annually. Moving from $50 to $65 per user costs approximately $1.5K per year.

The payback period is measured in weeks.

How Competitors Are Responding: Patterns in 2026

No one can afford to ignore this trend. Here's what's happening across the market.

Lattice

AI is integrated everywhere: assessments, development recommendations, attrition prediction, talent discovery.
Pricing remained stable while premium tiers expanded with cloud functionality and integrations.
_Strategy: _dominate the mid-market segment (500–2,000 employees) through consistently high baseline quality.

15Five / Leapsome

Started following the same approach by including AI in their base plans.
Reduced prices by 15–20% as a defensive move.
Challenge: they lack the data volume available to Lattice for model training.
Positioning: "similar to Lattice, but cheaper"—effective in price-sensitive segments.

Workday / SAP SuccessFactors

Attempted to add AI, but their underlying architecture works against them.
Their core systems are built around jobs and organizational hierarchies rather than competencies.
Adding AI on top feels like putting a bandage on a tank.
Market perception: increasingly viewed as late-moving incumbents.

Eightfold / Gloat

Positioned themselves as AI-first platforms from the beginning.
But their AI offerings primarily target Fortune 500 organizations.
Smaller companies compare them to platforms like Lattice that work effectively for organizations with as few as 50 employees.
Challenge: expensive and difficult to scale downmarket.

Personio, Zelt, and Other European Vendors

Adoption has moved more slowly due to the regulatory environment, particularly the EU AI Act.
But they recognize the same reality: failing to integrate AI means falling behind.
Approach: localize AI capabilities, ensure compliance, then scale.

Why This Trend Is Irreversible

There are three reasons why embedding AI into entry-level plans isn't a temporary strategy. It's the new baseline.

1. Customer Expectations Have Permanently Shifted
Every day, employees:

Write emails with AI assistance.
Debug code with AI assistance.
Generate images with AI assistance.

Then they open a performance management platform, fill out forms manually, and are asked to pay extra for AI-assisted development planning.

That feels absurd. The expectation shift is permanent.
No company can retrain users to stop expecting AI. Trying to move AI back into an optional add-on would damage credibility.

2. Data Has Become a Competitive Asset
Previously: More users → more server load → higher costs.
Today: More users → more training data → better models → better recommendations.

By embedding AI into its base plan, Lattice effectively made a long-term bet on data. ARPU may have changed, but training data grew exponentially.
Organizations that fail to recognize this lose speed-to-insight.

3. Compute Costs Have Fallen
In 2020, processing a single assessment through an LLM could cost $0.10–0.50. Today, it's closer to $0.01–0.05.

This is similar to what happened with cloud infrastructure in the late 2000s. Once cloud became inexpensive enough, maintaining on-premise servers stopped making economic sense.

The same thing is happening with AI.

What This Means for Companies Evaluating HR Platforms in 2026

If you're evaluating HR software today, pay attention to the following signals.

Red Flags
❌ AI is sold as a separate add-on.
❌ The "AI assistant" is merely a chatbot that waits for user prompts.
❌ AI is advertised without specific use cases.
❌ The company still markets AI as a luxury feature.

Green Flags
✅ AI is embedded directly into core workflows (assessments, PDPs, recommendations).
✅ No additional payment is required for basic AI usage.
✅ Time savings are clearly quantified.
✅ The vendor openly discusses limitations and keeps humans responsible for final decisions.

Where HR Pulsar Fits Into This Landscape

We recognized this shift before the market officially acknowledged it.

Our Position
We're building a platform designed around competencies rather than job titles. That's an architectural choice. And it makes AI integration feel natural rather than bolted on.

Why does that matter?
Lattice integrated AI into an architecture built around jobs and organizational structures.
It works. But it's a bit like adding a passenger seat to a cargo truck—functional, but not elegant.

We designed a competency graph from the start. Within that model, AI helps:
✅ Match competencies (pgvector embeddings against 4,800+ role models)
✅ Recommend development paths (which competencies should be developed for a target role)
✅ Suggest career moves (internal talent marketplace: employee + AI toolkit → project)
✅ Manage hybrid teams (people and AI agents visible within a single system)

And this is not a premium feature. _ It's foundational._

We also made a decision that would be difficult for Lattice to make without rebuilding its core architecture: We embedded an enterprise AI tools registry. The Workforce Map doesn't just show people. It shows which AI tools are approved, who owns them, and where risk exists.

This is more than workforce management. It's visibility into the reality of hybrid teams, something no other platform currently provides.

The Brutal Math: What Happens Next

Let's extrapolate.

2026–2027 (Current Phase)

Every top-10 HR platform will include baseline AI functionality.
ARPU will decline by 20–30%.
Retention will increase by 35–50%.
Startups that fail to integrate AI will lose rankings and relevance.

2027–2028 (The Next Wave)

AI systems will require specialized operators and configuration experts.
New categories will emerge around AI accountability, governance, and auditability.
The EU AI Act and NIST AI RMF will become operational requirements rather than optional frameworks.
Companies will discover they're using dozens of AI tools that nobody tracks.

2028 and Beyond

AI will become as invisible and as essential to HR software as SQL is to backend systems.
The question will no longer be whether AI exists.
The question will be how effectively it operates within your architecture.
Companies that layered AI onto legacy systems will struggle.
Competency-centric platforms with built-in hybrid workforce management will gain structural advantages.

For Builders: Why This Matters
If you're developing HR software today, here's what you need to understand.

1. Architecture Is Destiny
If your platform is fundamentally built around job titles, integrating AI will be painful. Start with a competency graph.

2. LLM Errors Are a Feature, Not a Bug
Treat AI output as a recommendation, not a decision. Humans must retain final authority. This reduces legal exposure and increases trust.

3. Data Flows Matter
Where does the AI get its data? From a single organization? Or from an anonymized population? The answer determines which features are possible. Self-hosted systems can never provide industry-wide benchmarking. That's not a design limitation. It's mathematics.

4. Open Source Signals Trust
Technical buyers evaluate open-source AI systems differently. Not as black boxes.

As tools they can inspect, understand, and extend.

# Пример: как мы думаем о встраивании AI в HRPulsar

class CompetencyMatcher:
    """
    AI Fluency — это не магия. Это pgvector embedding.
    Сотрудник имеет компетенции. Роль требует компетенции.
    Косинусное расстояние между векторами = match score.
    """

    def recommend_development(self, employee_id, target_role_id):
        # LLM помогает сформулировать смысл рекомендации
        # Но мэтчинг — это чистая математика
        employee_embedding = self.get_embeddings(employee_id)
        role_embedding = self.get_embeddings(target_role_id)

        gaps = role_embedding - employee_embedding
        # ^ Это — список компетенций для развития

        recommendation = self.llm.generate(
            prompt=f"Сотрудник {name} хочет перейти на роль {role}. "
                   f"Ему нужно развить: {gaps}. "
                   f"Напиши конкретный PDP."
        )

        # ВАЖНО: это — предложение, не приказ
        return {
            "recommendation": recommendation,
            "confidence": self.calculate_confidence(gaps),
            "final_decision_owner": "manager"  # Не LLM!
        }

An Honest Assessment: What Could Go Wrong

Embedding AI into the base plan isn't risk-free.

**Risk #1: **Margin Erosion Without Scale
If you've integrated AI but only have 50 customers, revenue decreases while LLM infrastructure costs increase.
You're underwater.

Mitigation: Integrate AI once you reach meaningful scale (roughly 200–500 customers with 50+ employees each). Until then, keep it optional or in alpha.

Risk #2: Poor AI Can Destroy Trust
If your LLM generates invalid leveling recommendations and a manager blindly follows them, you've created a potential legal problem.

Mitigation: Be transparent about limitations.
"AI recommendation" does not mean "final decision." Educate customers. Log everything.

Risk #3: Regulation Moves Faster Than You Do
The EU AI Act requires documentation for high-risk AI systems. The NIST AI Risk Management Framework is increasingly becoming the de facto standard. Ignoring compliance while integrating AI creates future pain.

Mitigation: Start compliance work now, in parallel with AI development.

Closing: This Isn't the End of the Story

AI in the base tier of HR software isn't the peak of the wave. It's preparation for the next phase.

Because within the next 18 months, another shift will occur: M*anaging hybrid teams (people + AI agents) will become a core capability rather than a peripheral feature.*

Companies that currently use AI merely as an assistant—"here's a development recommendation"—are only preparing for the transition.

When organizations begin working alongside real AI agents that actively perform work, workforce management systems will need to see and manage those agents the same way they manage people.

That's when the real competition begins.

Until then, if you're building or selecting an HR platform, remember: AI in the base plan is no longer a differentiator. It's the cost of entry.

Everything else comes down to execution quality and architectural decisions that either enable—or prevent—the next stage of evolution.

Interested in how we're building this inside HR Pulsar?
Open source. 228 endpoints. Fully typed OpenAPI.
Spin up Docker, import your employees, launch an assessment, and see for yourself.
If you don't like something, open an issue.

Use it completely free https://app.hrpulsar.com/

Why we calibrate the indicator Total, not the raw scores

HR Pulsar — Tue, 02 Jun 2026 11:35:12 +0000

A 360 review collects answers from three to ten people about one person. Then the reviewer sits down to "calibrate" the result. The industry default is one of two paths: rewrite individual respondent scores, or override the per-competence percent at the very end. We tried both. Neither aged well. This week we shipped a third option, and we're not done thinking about it.

This post is half a release note, half an open question.

The raw-score calibration trap

The natural place to put calibration is on the raw answer. Respondent A gave 3, B gave 5. The reviewer thinks the real answer is 4, so they edit one of those numbers and recompute.

Two problems with that.

First, you've now lied about respondent A. Anyone who reopens the survey sees a number A never gave. The anonymity guarantee — the thing you spent ages explaining to the org — becomes "anonymous except when the reviewer disagrees."

Second, the indicator average is the wrong place to override anyway. A competence has five to ten indicators across three skill levels. The reviewer's gut isn't "the average of these answers should be 4.2." It's "this indicator at this level: the person clears it." Different math.

The other common shape is to leave raw answers alone and override the per-competence percent at the bottom. Cleaner. But you've now hidden which indicators the reviewer disagreed with. The output is correct, the audit trail is gone.

What we built

Reviewers pin a Total per indicator. Not on the raw answers. Not on the competence percent. On the indicator itself.

python
class CalibratedIndicatorTotal(Base):
    __tablename__ = "assessment_calibrated_totals"
    assessment_id: Mapped[UUID] = mapped_column(ForeignKey("assessments.id"))
    indicator_id: Mapped[UUID] = mapped_column(ForeignKey("competence_indicators.id"))
    skill_level_id: Mapped[UUID] = mapped_column(ForeignKey("skill_levels.id"))
    total: Mapped[int]  # 0..100
    calibrated_by: Mapped[UUID] = mapped_column(ForeignKey("users.id"))
    calibrated_at: Mapped[datetime]

Raw answers stay intact and stay visible in the same UI. The per-competence percent inherits the override — anywhere a calibrated Total exists, a calibrated chip surfaces in the breakdown so the audit trail is one click away.

Two operational rules around it:

Submissions lock while calibration is in progress. Late respondents can't trickle answers into a result the reviewer is already pinning. The assessment status flips to a calibrating sub-state and the take-assessment route returns 409.
Cancel calibration wipes every Total and restores raw averages. Not a soft delete — clean wipe. Cancel and you're back to the view a respondent saw.

The math: if a competence has indicators I1..I4 at skill level Intermediate and the reviewer pins Totals for I1 and I3 only, the competence percent at Intermediate is mean(pinned(I1), raw_mean(I2), pinned(I3), raw_mean(I4)). We don't silently propagate one pinned indicator to a whole level.

What we don't know yet

Three places where we made a call and aren't sure it survives contact with real teams.

Should the lock be hard or soft? Right now we hard-lock the whole assessment during calibration. The argument for soft is operations — reviewers don't need to chase the last respondent before they can start. The argument for hard is data integrity — calibration math is unstable when its inputs are still moving. We picked hard. Open question whether that's right for orgs with long review windows.

Should calibration carry a written rationale? The data model has room. The UI doesn't surface a comment field yet, because the moment you add a "why did you override this" field, reviewers either skip it or write "see meeting notes." Neither helps the person being reviewed. So: what would actually be useful here — a free-text rationale that nobody fills in, or a structured tag (e.g. "respondent bias", "context the survey missed") that constrains the input?

Re-entry semantics after Cancel. If a respondent submits after calibration was cancelled, their answer re-enters the raw average automatically. The alternative was an explicit "include late submissions" toggle. We picked auto-include because Cancel already feels like a reset button. But that's a guess.

Four years ago we started building an HR platform

HR Pulsar — Mon, 18 May 2026 10:56:41 +0000

Not because HR-tech looked exciting. Mostly because every company we talked to had the same setup:

grades in Excel
360 reviews in Google Forms
competency matrices buried in Confluence
“performance systems” that nobody wanted to open twice

And eventually: “Let’s just build our own thing.”
So we did.

Then this year we made a bigger decision: we rewrote the platform from the ground up — and open sourced it.

Meet HRPulsar

An open source talent management platform for teams where every employee already works with AI tools.

Most HR systems still model companies like it’s 2015: employee → position → annual review.

But that model is breaking. Roles change every quarter. Skills decay faster than job titles. Half the team uses AI agents nobody tracks. And “career frameworks” are often PDFs with better branding.

We built HRPulsar around a different assumption:
Skills are the stable unit. Not positions.

So the platform is competency-first at the core: competency graphs, grade systems tied to behavioural anchors, 360 assessments, internal talent marketplace, development plans, AI fluency tracking, AI workforce registry
Yes, AI workforce registry.

Because “Shadow AI” is becoming a real operational problem: teams use 15 different AI tools, security doesn’t know about half of them, and HR systems pretend none of this exists.

So we added:

AI tool registry
employee ↔ AI tool assignments
oversight levels
workflow ownership
audit trails
workforce maps for hybrid teams (human + AI)

Useful for compliance & security. But mostly because companies should probably know which AI systems are already part of their workforce.

Technically, HRPulsar is

FastAPI
Next.js
PostgreSQL
Redis
200+ API endpoints
~1000 automated tests
Docker-first deployment
AGPLv3

No “book a demo”. No sales call before seeing the product.
And one thing we decided early: HRPulsar will stay free for individuals and small teams.

Every workspace gets a monthly pool of renewable credits. Enough to run the core platform without turning “try the product” into a budgeting discussion.

And yes — self-hosting is fully supported. Because HR data is sensitive.
And “trust us with your entire workforce structure” is a pretty big ask from a black-box SaaS vendor.

We’re preparing the public GitHub release right now.
*The repository goes live at the end of May. If you want early access, release updates, or just want to watch the project evolve — join the waitlist.

LLMs are useful ONLY for competency matching and draft recommendations

They are not qualified to decide someone’s promotion. We’re very explicit about that in the product.

LLMs are useful for competency matching and draft recommendations.
They are not qualified to decide someone’s promotion. We’re very explicit about that in the product.

Current limitations?
We don’t cover recruiting yet. ATS/recruiting is on the roadmap, but not today.

Would genuinely love feedback from developers building internal tools, people running self-hosted infrastructure, HR engineers, teams experimenting with AI-heavy workflows... and especially from anyone who has ever tried to manage competencies in Excel. We know you exist.

try it on website

Why AI adoption fails inside companies

HR Pulsar — Thu, 07 May 2026 12:15:48 +0000

A company buys ChatGPT Enterprise. Then:

marketing uses it for copy
one engineer automates half their workflow
another refuses to touch it
managers say “we should use AI more”
nobody knows what “more” means

Three months later, leadership asks the inevitable question: “So… are we actually getting ROI from this?”. Silence. Not because AI failed.
Because adoption inside companies is mostly random. And random systems don't scale.

Most companies approach AI rollout like this:

Buy tools
Announce initiative
Hope employees figure it out

That works for maybe two weeks. After that, you get what every company gets:

inconsistent usage
inconsistent output
no shared standards
no visibility into who’s actually effective with AI

Useful? Sometimes.
Measurable? Not really.

The uncomfortable part: most companies still evaluate people like AI doesn’t exist.
Performance reviews ask communication, ownership & collaboration.
Fine. But now we also need to ask:

can this person delegate effectively to AI?
can they verify AI output?
do they know when not to use it?
are they faster because of AI — or just noisier?

Because there’s a difference between “uses AI” and “works effectively with AI” is enormous.
And this is where most AI adoption projects quietly break. Not on infrastructure. Not on tooling. On management.
No competency model. No measurement system. No shared definition of “good AI usage” - just licenses and optimism.

The weird part is that companies already solved this problem once.
We don’t say: “Everyone has Excel now, good luck”. We train people, define expectations, measure proficiency.
AI will end up the same way. Except the impact is bigger.

At HRPulsar, we’ve been thinking about this a lot. Not as “AI replacing employees”. But as: how do you systematically measure and develop AI fluency inside teams?
And honestly, we don’t think the industry has good answers yet.

Especially for:

role-specific AI competencies
measuring real usage quality
separating employee contribution from AI contribution One thing already seems obvious: buying AI tools is easy, building an organization that actually knows how to use them is the hard part.

Curious how other teams are handling this right now. Do you actually measure AI adoption in any meaningful way — or is it still mostly vibes?