Skip to main content
Golux Group

Work Transcendence: A Match You Can Check

Work Transcendence: A Match You Can Check

A matching platform built so that every percentage can be traced back to the sentence a person actually said.

Open the live product
  • Backend
  • Application
  • Business
Location
Belgrade, Europe
Team
Golux Group
Project type
Platform · AI product
Year
2026

Business challenge

Hiring tools score people with numbers nobody can explain. A candidate is a 78 percent fit, and neither the candidate nor the company can say what the missing 22 percent is made of. CVs get rewritten by tools until they say what the filter wants, so the claims mean less every year, and a person's own words disappear under someone else's summary.

What we did

We built the product around evidence. A person talks to an agent about what they have done or uploads a CV, and the agent asks back where something is unclear instead of guessing. Every skill, role, company and goal becomes part of a graph that keeps the sentence it came from and the date it was said. Nothing a person says is rewritten: when the interpretation improves it is rebuilt, and the original claims stay. Matching runs requirement by requirement, so a percentage shows which claim met each requirement and which requirements nobody has met yet. Companies describe a role in conversation and correct the extracted requirements before anything is published.

What shipped

  • Every claim tied to the sentence that proves it and the date it was said
  • Matching requirement by requirement, with the evidence for each match and each gap
  • Role listings created in conversation, with extracted requirements the company corrects
  • A job-hunt agent that compares a person against open listings and introduces the fits
  • Export everything or delete the account at any time, with quotes kept in the language they were said in

How we built it

The question written down first was not how to match people to jobs. It was what a match is allowed to claim. A number that cannot be explained is worse than no number, because people act on it, so every later decision had to keep a path from the percentage back to something a person actually said.

That made the data model the product. Each skill, role, company and goal is stored with the sentence it came from and the date it was said. We kept the claims apart from their interpretation: the interpretation can be rebuilt as the system improves, and the claims never change. A system that rewrites what people say eventually cannot prove anything.

Intake came next, and it is a conversation rather than a form. The agent asks back where something is unclear instead of filling the gap with a guess, because a guessed skill turns into an unearned match later on.

Matching was built last, requirement by requirement, so the output is a list of evidence rather than a bare score. The gaps are shown as plainly as the matches. A candidate learns what to work on, and a company sees exactly why someone ranks where they do.

Ownership was designed in rather than bolted on: quotes stay in the language they were said in, visibility in the pool is a choice, and export and deletion work at any time. AI was part of the work throughout, drafting, extracting and testing our own assumptions. What a match may claim was decided by people.

The method, in order

  1. Decide what the output may claim

    Before any model, we defined what a percentage has to be able to show. Everything after that was about keeping the path from number to evidence intact.

  2. Keep claims apart from interpretation

    Original sentences are stored with their dates and never rewritten. Interpretations can be rebuilt.

  3. Make intake ask instead of guess

    An agent that asks back where something is unclear, because a guessed skill becomes an unearned match.

  4. Show gaps as plainly as matches

    Every requirement is either met by a named claim or listed as unmet.

  5. Build ownership in from the start

    Export, deletion and visibility are part of the core model, not a settings page added before launch.

Built with

  • Python
  • FastAPI
  • Knowledge graph
  • LLM agents

For your product

What we would do on your product

If your product puts an AI-generated number in front of a customer, a score, a fit, a risk rating, we start with what that number is allowed to claim and how anyone could check it. We design the data so the evidence survives, then the generation. Building traceability in is far cheaper than explaining later why a number cannot be justified.

Run the free auditSee the product we built

Questions people ask

Why start with the data model?
Because traceability cannot be added later. If the original statements are not kept, no amount of interface work can show where a number came from.
How do you keep an agent from inventing skills?
By making it ask instead of guess, and by tying every stored claim to the sentence it came from.
Can you build explainable scoring or matching for us?
Yes. The pattern of claims with evidence, explicit requirements, and a result that shows both the matches and the gaps applies to hiring, lending, triage and any ranking a customer will question.

What the work covered

  • Backend development
  • Frontend development
  • Product design
See everything we do

More from Work Transcendence

Your project

Want an outcome like this one?

Start with a realistic budget and timeline for your own product, or bring the problem straight to the engineer who would work on it.

Calculate project costBook a strategy call

Keep going

Where to go next

The engineering notes

What we find inside AI-built apps.

The findings from the apps we audit, the fixes that worked, and what each one cost, written by the person who did the work. No roundups, no reposts.

A few emails a month. No spam, unsubscribe any time.

Golux Group

Already a client? Golux Club
is where your project lives: tickets, approvals, files, one record.

Open