Skip to main content
HUMΛN
Capability Graph
Capability Graph

The routing engine that understands what you mean, not what you typed

HUMΛN Team··14 min·Workforce + ML product

A task lands in the wrong queue. Not because someone mistyped “React,” but because the request said “Core Web Vitals for LCP” and the only labeled specialist said “React performance.” String overlap is a coin flip. The human who could help never sees the work.

That is the routing problem HUMΛN’s Capability Graph exists to solve—meaning first, keywords second.

Capability-first, cost-informed second

When HumanOS routes work, it filters for who can do this, then considers cost among capable options. Invert that order and you get cheap failure: the cheapest agent that cannot do the job, dressed up as optimization.

The graph engine logs match scores, surfaces ontology gaps when similarity is high but labels disagree, and gives operators something to fix besides “watch the queue rot.”

Scroll-stopper: If your router optimizes for price before it proves capability, you have built a discount aisle—not a trust layer.

Evidence beats claims

Carlos never filed a formal TypeScript certification. High-rated completed tasks across telemetry still support an inferred edge a reviewer can promote into a durable capability link. The graph learns from what people produce, not what they typed on a form.

That is revelation, not ranking: confidence intervals, human review where inference proposes, and no gaming leaderboards as a product surface. Capability exists so the right human becomes visible—not so a vendor can sell opaque tiers.

Cross-org without mapping hell

Acme and GlobalCo use different internal labels for similar work. Canonical capability mappings align namespaces so routing finds the right human without every admin hand-wiring synonyms. The point is interoperable meaning—a shared language for capability across org boundaries—not a surveillance dossier or a hidden scorecard.

Principle check (Canon)

Capability is for revelation, not exclusion. If a feature smells like “secret score,” ship uncertainty and appeals, not opaque tiers. Pair semantic matching with HumanOS policy so low-confidence routes escalate instead of silently assigning the wrong person.

What to refuse

Refuse products that:

  • Rank humans for exclusion behind a “match score”
  • Treat string equality as capability truth
  • Hand-wire every synonym forever instead of investing in a canonical layer

So that when two job posts mean the same skill in different words, the graph can still find the human who has shown the work.

Pair with


HumanOS policy: Safety at business speed.