--- title: 4 The platform today --- # 4 The platform today **At a glance** | **Component** | **What it does today** | **How it is validated** | **Known limitation** | |---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------| | Ontology Store | Canonical skills taxonomy (ESCO, ISCO, Competentiegids Rijk); semantic search; extraction of concepts from vacancies and CVs; skill matching in three buckets | precision@k on a labelled query set; p95 latency; ingestion success | Semantic false positives; stale index; similarity is discovery, not proof of fit | | Generation Service | Vacancy text, questions, rubrics, interview sets – each with a judging counterpart; tenant configuration | LLM-as-judge on clarity, alignment, cognitive load, faithfulness, unsupported claims; MLflow runs; reviewer approval before use | Fluent but misaligned items; generic output | | Candidate Evaluation | Asynchronous scoring per rubric criterion with explanation; evaluator → score model → summariser → validation; Rasch-calibrated targets | Held-out error and calibration; AI–human agreement (κ .67–.70); override monitoring | Score compression at the ends of the scale; valid only for validated rubrics and populations | | Bias Monitoring Framework | Three scopes: AI–human and reviewer consistency; group parity; threshold impact | Applied to two DNB pilots (913 candidates, \> 13,000 scores) | Group variables limited to gender so far; thresholds and escalation not yet formalised | | AI lifecycle framework | Functional contracts, model cards, run evidence, release conditions | MLflow-tracked runs; documented release decisions | Documentation is a bridge to validation, not validation itself | *Table 2 – The current system at a glance; sections 4–6 describe each row.* ## 4.1 Services and the gateway ObjectivEye is a skills-based, explainable hiring platform. It reads vacancies and candidate material, resolves what they say against a shared ontology, and generates and scores against that ontology rather than against free text – which is what makes a result something that can be accounted for afterwards \[17\]. Technically it is a handful of services, each with its own API, behind one service gateway, and one document store holding every document the platform has read or written. The Ontology Store holds the General Skills Taxonomy – ESCO, ISCO and the Competentiegids Rijk – with semantic search over it and the resolution of free text into the concepts it names. The Generation Service writes what a hiring process needs written: a vacancy from a brief, questions for a role, a rubric to score answers against, and for every writing task a counterpart that judges an existing text. The Candidate Evaluation Service scores a candidate against a vacancy asynchronously and returns the reasoning alongside the score; its worker runs the pipelines. The Document Store keeps categorised documents, their Markdown and parsed structure and the templates learned from them; the Search Worker provides semantic search over the in-repo index. Every service is reached through one gateway address and a path prefix; a service moving is a routing change rather than an announcement. The Ontology Store is the one exception: it runs in a different Azure environment and the application calls it directly \[17, 18\]. ![Figure 5 – The platform today: caller, service gateway and the six services it routes to (drawn from the gateway documentation, dev environment).](../media/image6.png) *Figure 5 – The platform today: caller, service gateway and the six services it routes to (drawn from the gateway documentation, dev environment).* ## 4.2 The Ontology Store Everything the platform generates or scores resolves its language against the Ontology Store first. That is what makes a downstream result explainable: a score that points at a concept with a stable URI can be accounted for and compared across candidates, where a score pointing at a phrase that happened to match cannot \[18\]. The store answers two kinds of question – what concept does this text mean, and what does this concept connect to – and it decouples the platform from any single framework: ESCO, CompetentNL and internal terminology are normalised into one canonical shape through adapters, so internal workflows never learn which source a skill came from. Search is semantic, not lexical: the query is embedded (Azure OpenAI ada-002) and compared by cosine distance against vectors computed from each record's label and description in PostgreSQL with pgvector; asking for "strategisch beleid" returns "organisatorisch beleid" and "strategische planning implementeren" although neither label contains the query. The General Skills Framework behind it models occupations, competencies, tasks, knowledge, outcomes and behavioural indicators with their relationships, and around it sit skills profiles per role, behaviour-anchored rubrics per criterion, an OWL/SHACL concept model and crosswalks between frameworks. Three operations matter for the extension: extraction (/v1/extract-skills for a vacancy, /extract-skills/cv for a CV, /extract-skills/profile for a profile in which each skill carries a proficiency, a year last used and the evidence for it), matching (/v1/match-skills, returning three buckets – shared, asked for but missing, brought but not asked for – with an overall score) and the neighbourhood of an entity (/v1/entities/{uri}/neighbours). The service is judged on precision@k against a labelled query set, p95 latency and ingestion success \[18\]. ![Figure 6 – The General Skills Framework and its relationships, as modelled in the Ontology Store.](../media/image7.png) *Figure 6 – The General Skills Framework and its relationships, as modelled in the Ontology Store.* ## 4.3 Data: what the platform reads, stores and measures Three kinds of data flow through the current methodology. Content data: vacancies, the templates they are generated from, questions, rubrics and this documentation, all held in the Document Store and searchable by meaning. Assessment data: candidate answers, the AI's judgement per rubric criterion with its reasoning, the final score, and the human reviewer's scores – one run per application, one case per answer, persisted in the evaluation ledger (PostgreSQL) which is the source of truth for polling; a configuration is addressed by the hash of the model that produced it, so a past result stays reproducible \[19\]. Monitoring data: the Bias Monitoring Framework reads candidate scores, human reviewer scores, AI-generated scores, candidate group variables where legally available, question and competency identifiers, pseudonymous reviewer identifiers, selection thresholds and progression outcomes \[14\]; the Box 3 analysis adds per-criterion scores from a re-run, the experiment bundle with configs and model outputs, and the Forms exports of the reviewer questionnaires \[1\]. Personal data stays in the platform database and in named SharePoint folders; the Data Registry – the controlled home for data sets with personal data – is being prepared and the integration of the training pipeline with it moved to Sprint 3. This is the data the extension starts from: it is the training and validation base of the current scorer, and it is what any new scorer will be compared against.