--- title: 11 Engineering storyline --- # 11 Engineering storyline This section is written for the two teams that build the concept. It fixes who owns what, specifies the shared ontology both teams program against, and then walks through the employer, candidate and reviewer flows screen by screen, stating for each step what the front-end shows and what the back-end does. ## 11.1 Who builds what The split holds for every flow. The platform team builds screens, workflows, records and access: the employer, candidate and reviewer front-ends, the staging engine and the position lifecycle, the storage of Skills Passports and positions with versioning and consent, identity kept apart from records, the reveal policy and the audit log. It integrates the AI services through the gateway and renders the proposals, levels, certainty values and explanations it receives; it never computes a score itself. The AI & Data team builds extraction and taxonomy – vacancy to requirements profile, CV to entries and task phrases, mapping to the Ontology Store, autocomplete and suggestions – scoring – rule sets per requirement, the biographical scorer over taxonomy paths, Candidate Evaluation for questions and probes, certainty and explanations – and quality: validation, bias measurement per rule and requirement, agreement metrics, with the internal insights service feeding the fairness panel. The contract between them is simple to state: the platform sends documents and choices, the AI services return proposals, levels, certainty and explanations with provenance, and every number a reviewer sees can be traced back through the gateway. Mapped onto the services of Part II: the Ontology Store gains the requirements-profile extraction (deliverable 1.2), the passport record mapping and the link-type traversal behind coverage; its existing /extract-skills/cv and /extract-skills/profile operations are the starting point of the quick-fill step, and /match-skills with its three buckets – shared, missing, not asked for – is the ancestor of coverage per requirement. The Generation Service produces questions and probes per requirement and proposes default rule sets from templates. The Candidate Evaluation pipeline scores questions and probes unchanged and gains the biographical scorer as a sibling stage that reads passport records and rule sets instead of answers and rubrics. The insights service computes the Bias Monitoring metrics per requirement and rule. The platform application (Next.js front-end, NestJS back-end behind the API gateway, OE-655) owns every screen and record described below. ![Figure 23 – Who builds what: platform team and AI & Data team, and the contract between them.](../media/image23.png) *Figure 23 – Who builds what: platform team and AI & Data team, and the contract between them.* ## 11.2 The shared ontology The generalised evidence-based assessment ontology \[16\] is the data model both teams program against. It connects what work requires, what evidence a candidate provides and how that evidence is evaluated, in one graph with three namespaces. ESCO identifiers are reused where the meaning matches; ObjectivEye and customer concepts live in their own namespaces with explicit relationships to the shared vocabulary; the model is expressed in RDF/OWL with SHACL validation, PROV-O provenance and SKOS mappings, and it is to be integrated into the Ontology Store and followed across candidate profiles, requirements, evidence collection, generation, evaluation and matching, so that the same canonical concepts connect requirements, evidence and results throughout the system. **Namespace 1 – Work, tasks, skills and competencies** | **Concept** | **Definition** | **Alignment** | |-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------| | Task | A defined unit of work: an action performed in a context to achieve an intended outcome. The concrete reference for requirements and performance assessment. | ObjectivEye extension linked to ESCO capabilities and knowledge | | Behaviour | An observable action or pattern through which a person performs a task; makes performance describable through evidence and anchors. | ObjectivEye extension | | Outcome | A result produced by performing a task – a deliverable or a change in state; separates how work is done from what it achieves. | ObjectivEye extension | | Context | Setting, resources, constraints and conditions affecting task performance; supports judgements about transferability. | ObjectivEye extension | | Skills and competencies | Generalised capabilities to apply knowledge and methods to related tasks across contexts. | ESCO skill/competence concepts | | Knowledge | A body of facts, principles, theories and practices a person draws on when performing tasks. | ESCO knowledge concepts | | Occupation | A category of positions with substantial similarity in recurring tasks, responsibilities and expertise. | ESCO occupations with essential / optional capability relations | | Occupation group | A broader category grouping occupations by shared characteristics of their work. | ISCO-08 hierarchy | *Core relationship: a task requires skills, competencies and knowledge applied in a context; its performance is expressed through behaviour and produces an outcome; occupations generalise recurring work patterns and occupation groups organise them.* **Namespace 2 – Organisation, position and requirements** | **Concept** | **Definition** | **Relationship to Namespace 1** | |----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------| | Organisation | A collective whose members collaborate to achieve a common purpose. | Establishes the setting – context | | Position | A defined role within an organisation: assigned tasks, expected outcomes, responsibilities. | Classified under an occupation; includes tasks and outcomes | | Responsibility | An obligation attached to a position concerning the performance of work or achievement of outcomes. | Obligations concerning tasks and outcomes | | Requirements profile | A structured specification of a position's responsibilities, tasks, expected outcomes, required capabilities and knowledge, with context and performance expectations; the reference for vacancy content, evidence collection and assessment. | Specifies expectations using task, outcome, context, skills, knowledge | | Requirement | An individual expectation within a profile, with its expected level or conditions; individually assessable and traceable. | Refers to a task, result or capability; may specify criteria through behaviour and context | | Vacancy | A document format that advertises a position and communicates its relevant requirements. | Communicates selected requirements using the shared concepts | **Namespace 3 – Candidate profiles, assessment evidence and scoring guides** | **Concept** | **Definition and purpose** | **References** | |------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------| | Applicant profile · evidence profile | The candidate-level record, and the collection of evidence available for assessing the candidate: answers, education, experience, demonstrated tasks. | – | | Candidate answer | A response to an assessment item, kept separate from its interpretation and score. | Assessment item | | Education record | Normalised: programme, institution, qualification, completion status. | Knowledge, skills / competencies | | Experience record | Normalised previous work or practical experience – positions, activities, circumstances; background, not demonstrated performance. | Organisation, position, occupation | | Demonstrated task | A recorded instance of a task reportedly or observably performed, with context, behaviour and outcomes; concrete performance evidence. | Task, context, behaviour, outcome | | Evidence claim | A proposition about knowledge, capability or task performance supported by identified evidence; makes interpretation explicit and traceable. | Task, skills / competencies, knowledge | | Assessment item · scoring guide · score format | The prompt that elicits evidence against criteria; the criteria and rules (rubric levels, anchors); the permitted values and their meaning. | Requirement and associated work concepts | | Assessment method | A defined combination of evidence collection and a scoring guide; the unit for research justification and validation. | Requirement | | Assessment · evidence evaluation | The process of evaluating evidence against a requirements profile; a documented judgement of how evidence supports an item criterion, claim or requirement, with its limitations. | Requirements profile | | Scorecard · scorecard entry | The structured result with requirement-level entries, supporting evidence, judgements and scores; each entry independently traceable. | Requirement | Work-probe submissions remain evidence – no new class is needed for them. Extracted requirements stay drafts until the employer confirms them. Evidence and evaluations connect to Namespaces 1 and 2 through the references in the right-hand columns; that is what lets the scorecard translate between a candidate's evidence and a position's requirements without copying either. ![Figure 24 – The three namespaces as presented to the team (concept presentation, slide 13).](../media/image24.png) *Figure 24 – The three namespaces as presented to the team (concept presentation, slide 13).* ## Flows Defintion flow: -\> inital info -\> assessment config -\> design -\> publish Application flow: -\> visit -\> create skills-profile -\> answer questions -\> complete and submit Assessment flows -\> review -\> score -\> select ## 11.3 Employer flow The employer flow follows one rule: the AI proposes, the employer decides, the platform stores. The platform team owns the position screens – create position, requirements editor with tags and taxonomy search, scoring-rules editor, package and staging screen, publish – the position record in which the confirmed requirements profile, the rule sets and the package are stored versioned together and frozen on publish, and the workflow settings for staging, reveal and knock-out handling, which are enforced server-side. The AI & Data team owns the requirements extraction (vacancy spans to requirements to taxonomy concepts with provenance, in the Ontology Store, deliverable 1.2), the default rule sets per requirement derived from the taxonomy and templates with validation that proxies are off, and the package generation in which the Generation Service produces questions and probes only for requirements that need them. ![Figure 25 – Employer flow: create position from vacancy, scoring rules per requirement, assessment package and staging, review screen.](../media/image25.png) *Figure 25 – Employer flow: create position from vacancy, scoring rules per requirement, assessment package and staging, review screen.* Step 1, create position from vacancy. The employer pastes or uploads the vacancy text and sees a proposed requirements profile: each requirement with its taxonomy concept and a must / should / knock-out tag, which can be edited, and a search over the skills list to add requirements. Confirming the profile stores it versioned; from then on it is the reference for scoring, package and review. Behind the screen the extraction service turns vacancy spans into requirements and links each to ESCO or task concepts with provenance to the span. Step 2, scoring rules per requirement – the counterpart of defining questionnaire items today. For a requirement the employer switches evidence sources on or off (passport, question, work probe; interview is listed but off), reads and edits the anchors of the biographical scoring guide – level 4 for the same task with at least three years, own responsibility and recent; level 3 for the same task under three years or a related task via a shared skill; level 2 for a related occupation only or the same task long ago in a supporting role; level 1 for the same occupation group without shared task or skill; no path, no evidence – and chooses the attributes that count: task match, duration, recency and responsibility are on, years alone, employer name and education level are off by default. A template per organisation or role family pre-fills these; changed anchors are flagged for review; the rules can be applied to all requirements at once. In the back-end scoring guides are configuration, not code: a versioned rule set per requirement with link-type weights, attribute rules and knock-out logic, fixed before the first candidate is scored. Step 3, package and staging. A matrix shows which requirement is measured with which evidence; the employer chooses the staging strategy – all at once, sequential for everyone, or staged by invitation with the passport first and questions for a shortlist – and sees the effort the candidate will be shown. Publishing composes the package from the rule sets (questions and probes only where needed), stores the staging strategy as a setting on the position and freezes profile, rules and package together. ## 11.4 Candidate flow The candidate flow follows the rule that the platform owns the passport and the AI services fill and map it, and the promise that nothing a candidate recorded is asked again. The platform team owns the passport screens – record types with add forms, CV upload and proposal review, edit forms with pickers, the status overview, apply and reuse – the passport record itself (typed records with taxonomy references, source span, validation status and versions; identity stored apart; consent for reuse across positions) and the assessment delivery that shows per position what is covered and runs the staged package for the uncovered requirements only. The AI & Data team owns the CV extraction and mapping (the existing extraction producing entries and task phrases, a mapper to occupation, task, skill and knowledge nodes with a confidence per proposal), the taxonomy services for autocomplete and suggestions and the normalisation of duration, recency and level, and the coverage computation of the matching service. ![Figure 26 – Candidate flow: start a passport, quick fill from the CV, adjust an entry, confirm and apply.](../media/image26.png) *Figure 26 – Candidate flow: start a passport, quick fill from the CV, adjust an entry, confirm and apply.* Step 1, start a passport. The candidate sees five record types – education, experience, certificates, skills and tasks, achievements – each with an add form and an empty state that explains what a record is, and the shortcut to fill the passport from a CV. Step 2, quick fill from the CV. After one upload, proposals appear per record type, each to accept, edit or remove; suggested skills are marked as suggestions; nothing is saved until it is accepted. The extraction produces the entries and task phrases, the mapper links them to taxonomy nodes and keeps the source span; proposals are drafts with a confidence flag, and accepting turns a draft into a record with the status confirmed. Step 3, adjust and complete. The edit form offers the role from the occupation list, the tasks as chips with suggestions from the Ontology Store, period and responsibility as structured fields, and a visibility switch for the employer name that is off for blind review; the source span and the status are shown. Normalisation computes duration, recency and level; the edited record keeps its provenance. Step 4, confirm, apply, reuse. The overview lists the records with their statuses; for a position it shows the coverage – three of four requirements in the example – and what the package still asks, so that the candidate starts an assessment that contains only the missing evidence, or reuses the passport for another position. Coverage is computed by the matching service from passport and requirements profile through the taxonomy; the staging engine builds the package from the uncovered requirements; reuse across positions is consent-based, and records are versioned when they change. ## 11.5 Reviewer flow The reviewer flow follows the rule that the AI scores each source and the platform keeps the sources apart. Three scorers produce the levels: the biographical scorer applies the rational key over taxonomy paths, Candidate Evaluation scores the anchored questions, and criteria scoring handles the work probes; each has its own guide. For each level the AI side also returns a certainty – derived from the number of independent sources, the validation status of the record, the agreement between sources and the length of the taxonomy path – and an explanation built from the stored path, rule, anchor and source span, not from free text. Aggregation happens per source; combination happens only per requirement, and only for the reviewer's eyes. The platform owns the review screens, the review record (judgements, comments and reveal events per requirement, with the rule-set and profile versions that produced the levels) and the no-total rule: it never sums levels, sorts and filters per requirement only, and treats knock-outs as filters rather than ranks. ![Figure 27 – Candidate profile view: overview, skills profile per requirement with the three source levels and their certainty, evidence detail per source.](../media/image27.png) *Figure 27 – Candidate profile view: overview, skills profile per requirement with the three source levels and their certainty, evidence detail per source.* The candidate profile view is structured from overview to detail. At the top, coverage, the knock-out status, the number and status of records and the agreement between sources – and, deliberately, "total score: none by design". In the middle, the skills profile as a picture: for each requirement the passport, question and probe levels as separate bars against the requirement's threshold band, with the certainty indicator beside them. At the bottom, the evidence per source, opened one at a time; for the biographical source every level with its taxonomy path, the record, the rule that produced it and the source span; questions and probes collapsed with their aggregates until opened. Certainty is about support, not quality: three independent sources that agree on a confirmed record with a direct path give high certainty; a single self-reported source gives low certainty; missing evidence lowers certainty, never the level. ![Figure 28 – Comparison view across candidates: per requirement, source by source, with filters and decision chips – no total column.](../media/image28.png) *Figure 28 – Comparison view across candidates: per requirement, source by source, with filters and decision chips – no total column.* The comparison view shows all candidates of a stage in one table, per requirement the three source levels with certainty, with filters for knock-out met, coverage and certainty, sorting per requirement only, and a decision chip per candidate. It draws on the same scorecard entries, aggregated per source across candidates. Group-gap monitoring per requirement column runs in the insights service and flags a column, not a candidate. Identity stays hidden throughout; reveal is a logged action governed by the position's workflow setting.