Answerable by Design: The AI Decision Engine Behind CANDID8.AI, Built by Teque

CANDID8.AI is an AI-native recruitment platform. Teque built the decision engine that helps it evaluate candidates, and built it so that every call it makes can be seen, explained, and overridden. In a domain the EU AI Act treats as high-risk, that is not a nice-to-have. It is the product.

The situation

CANDID8.AI helps decide who gets a shot at a job. That is the whole weight of it. When AI sits that close to someone’s livelihood, “it works in the demo” is not a standard you can build a company on, and it is not one CANDID8.AI’s own customers, or a regulator, will accept.

Faisal Saleem, CANDID8.AI’s founder, was clear from the first conversation: he did not want a clever black box. He wanted a system he could stand behind when someone asked why a candidate was ranked where they were. Hiring AI is classed as high-risk under the EU AI Act, so “defensible” is a legal bar as well as a moral one.

The challenge

The naive build is easy and wrong: wire an LLM to a prompt, feed it a CV and a job spec, take the answer. It demos beautifully. Then it fails in exactly the ways you cannot afford in hiring:

• You cannot see what it actually did, only what it returned.
• You cannot prove why it reached a given decision, to a customer, a regulator, or yourself six months later.
• You cannot guarantee a human is in front of the consequential call, or stop the system cleanly when something looks wrong.
• It drifts silently as models and data change, and you find out from an incident, not a dashboard.

The bar was accountability on decisions that affect real people. Meeting it meant treating observability, evaluation and control as first-class parts of the build, not things bolted on after the model worked.

The approach: answerable by design

We built to a simple test: before you trust an AI decision, you should be able to see it, prove it, and stop it. Here is what each looked like in CANDID8.AI.

The build. The system is a set of bounded pipelines, each doing one job, rather than an open-ended autonomous agent. No self-directed tool use, no ability to take actions in the outside world. The decision to keep each pipeline narrow was deliberate: an inspectable pipeline is something you can actually account for. You cannot hold a black box to account, so we did not build one.

See it. Every model call the system makes is traced end to end and given a readable name, so in production you can watch the actual path a decision took, not a reconstruction. When the system falls back to a safer default, that fallback is recorded as its own event, so “how often did we degrade, and where” is a question with an answer. Where a step did not call a model, we instrumented it by hand rather than let it go dark.

Prove it. This is the part most teams skip, and it has two halves. Explainability is being able to answer “why did it rank this person here”, and CANDID8.AI answers it two ways. Because every model call is traced under a named run, a match can be replayed after the fact from its actual inputs, the steps it took, and the model version that produced it. On top of that sits a dedicated explanation pipeline that reads the score components and produces a plain-language summary of the strengths and gaps behind a match. It is deliberately additive: it explains the decision, it never changes the score, and it falls back to a rule-based explanation if a model call fails. Evaluation is knowing the system is still behaving: a golden-set evaluation runs every night against a hand-built reference set of scored candidate-role pairs, wired into the build as a gate rather than a report nobody reads, so a drop in quality has to be looked at before code ships. That same outcome data is what lets the system get better over time: as more shortlisted and hired candidate-role pairs accumulate, they can be fed back to refine the scoring calibration, so the matching sharpens as real hiring decisions teach it what a good match looked like.

Stop it. The recruiter is the decision-maker, always. The AI ranks and explains; it does not hire, reject, or advance anyone on its own, and it structurally cannot write to the system of record or act externally. There are per-pipeline kill switches that can take any part of the AI offline, re-checked while work is in flight, so stopping means stopping, not “after this batch”. Standard guardrails sit around the edges: input limits, output clamping, timeouts, rate limiting.

And the data itself. Protecting candidate data was a first-order priority, not an afterthought. Matching a person’s skills, experience and capability to a role does not require their personal identity, so CANDID8.AI de-identifies the data before it reaches a language model: the identifying details are simply not part of what the model sees. Data is stored securely, never sold or shared, and passed only to the infrastructure providers CANDID8.AI holds contractual agreements with. Store it securely, share nothing, and keep personal data out of the AI.

What building this taught us

Real systems teach you things a demo never will. Three that shaped how we build:

1. “Everything is traced” is a claim you have to test, not assume. The stages that call a model are the easy ones to observe. The stages that do not fall straight through a “we trace all the AI” statement and go dark exactly when you need them. Coverage is a thing you verify, not a thing you declare.
2. A quality check is only worth what someone acts on. An evaluation that emails a number to a channel nobody reads is theatre. The value came from making the nightly check a gate that a human has to look at before anything ships.
3. Failing safe is not the same as failing loud. A component that degrades gracefully and quietly writes a warning has still failed, and if nothing surfaces that warning, you can run degraded for a long time without knowing. Accountability means the quiet failures have to become visible ones.

The result

What shipped is a production AI decision engine CANDID8.AI can operate with confidence: every decision watchable, a nightly gate that catches quality drift before it reaches a candidate, and a system the recruiter stays firmly in control of. The business outcomes, candidate volumes and commercial results are CANDID8.AI’s to speak to.

When you’re building AI that helps decide who gets a shot at a job, the thing that keeps you up at night is being wrong about someone. Get it wrong and it isn’t a bug, it’s a real person who didn’t get a fair look. Teque understood that from the first conversation. They built us something I can see inside, question, and stop if I need to. That is the difference between dreading this technology and being proud of what we’ve built.

Faisal Saleem, Founder, CANDID8.AI

The takeaway

If you are putting AI in a seat where being wrong has real consequences, the test is the same every time: see it, prove it, stop it. Can you watch what it actually did? Can you show why, to someone who is not you? Is there a human who can stop it before it does harm? CANDID8.AI is what it looks like when the answer to all three is yes.

This is the full technical teardown behind our CANDID8.AI case study.