Evaluation criteria — technical guide

For implementation, support and integration teams. SMR = nextgen frontend/backend; SML = legacy Symfony application. For SMR Performance, the PRD defines the target behavior. Repository references identify the implementation components involved. Customer-facing workflows and settings are in the functional and configuration guides.

Architecture and responsibilities

Verified in code: SMR CriteriaConfiguration.vue renders the four criterion tabs. The CompanySettings API/store/mapper load configuration, questions and history. Review campaign configuration resolves Performance inputs; OPRGenerator computes the review rating. People Review has separate scale, weighted and Performance answer calculators. These paths must not be treated as one interchangeable scoring algorithm.

Observed in application: the supplied /company/space/admin/settings/criteria page embeds an SMR screen inside the company shell. SML indicator and section paths remain separate; no automatic bridge or migration was established. Targeted searches in aihub/src did not establish an AI scoring dependency for these four criteria. This is a search result, not proof of absence throughout the system.

SMR data model and configuration

Configuration key	Expected referenced question type
PERFORMANCE_ASSESSMENT	CompanyPerformanceQuestion
POTENTIAL_ASSESSMENT	CompanyScaleQuestion or CompanyWeightedQuestions
RISK_OF_LOSS_ASSESSMENT	CompanyScaleQuestion
IMPACT_OF_LOSS_ASSESSMENT	CompanyScaleQuestion

Verified in code: criterion configuration values reference company questions by identifier. AbstractQuestionConfigurationValidator checks an integer reference exists, matches the expected type and is not already referenced by a conflicting criterion key. These are type/reference checks, not a replacement for access control.

Questions carry scale/options and translated content. The Performance entity includes included-skills filters, skill-type filters, employeeVsEvaluatorSkillWeight, employeeVsEvaluatorObjectiveWeight, weightDistribution and computeOverScaleOption; its DTO also exposes manual/advanced selection through useCustomScore. ReviewOverallPerformanceRating stores the computed components, detail and evaluator score/justification. ReviewUserScore in SML is a different entity, with a participant, section question and numeric score.

SMR request flow and contracts

Verified in frontend API call sites; not exercised as write requests. Paths are application API contracts, with no tenant IDs or credentials shown.

Method / path	Purpose
GET /api/v1/company	Company metadata and skill rating maximum.
GET /api/v2/company/configuration/public	Configuration list; the client requests page 1, 25 entries, with nested groups.
GET /api/v2/company/configuration/{slug}/history	Version history; the client fetches subsequent pages.
GET /api/v2/company/question/{id}	Read referenced question and translations.
POST /api/v2/company/question/{type}	Create a question; type is scale, weighted or performance.
PUT /api/v2/company/question/{type}/{id}	Update a question of that type.
PUT /api/v2/company/configuration/{slug}	Associate the criterion configuration value.
POST /api/v2/company/question/{id}/translate	Translate from source_locale to target_locale.
GET /api/v2/review/{userReviewId}/overall-performance-rating	Read an existing rating; used for a locked review.
POST /api/v2/review/{userReviewId}/overall-performance-rating	Generate/retrieve computed rating for an unlocked review.
POST /api/v2/review/{userReviewId}/overall-performance-rating/evaluator-score	Save evaluator score and justification.

The review API function names the route argument userReviewId; do not substitute an arbitrary employee ID. Configuration association payload shape is {"value": <question identifier>}. Evaluator-score payload shape is {"raw_score": <number or null>, "justification": <string or null>}. These are contract shapes, not runnable production instructions or full authorization/validation schemas.

Question creation/update and criterion association are separate client calls; do not assume they form a single atomic transaction. Verify both question content and active configuration after a failed save. The configuration client can return null after a failed read, while mutation errors are rethrown; the review client parses responses and has a narrow GET fallback for a computation error mentioning missing skill/objective setup. A fallback can retrieve a manual result; it does not prove the automatic calculation succeeded.

SMR — target review Performance calculation

Target behavior defined by the PRD: Standard Score is entered by the primary evaluator during the interview. Advanced Score is calculated from skills, performance goals, or both, according to campaign sources. Source Smart Questions are mandatory.

Company configuration defines included skills (all or job-related), skill types, employee/reviewer weighting for skills and independent employee/reviewer weighting for goals. Within each component, the reviewer share is split equally between two contributing evaluators; without the second evaluator, it goes to the primary evaluator. Available partial answers are used; participants without a contribution are excluded.

Calculation has two levels:

Component = employee rating × employee weight
            + reviewer rating(s) × reviewer weight
Performance = skills score × skills weight
              + goals score × goals weight

Components use their respective participant distributions. If the campaign uses only skills or only goals, the overall source split does not apply. The normalized result is an integer from 0 to 100, then converted to points, percentage or letters according to the configuration version.

Implementation components involved are OPRGenerator, OprManager, campaign configuration resolution and skills/goals answers. The target result-retention and visibility contract is described below.

SMR — People Review score normalization

Verified in code: CompanyAnswerValueNormalizerTrait normalizes stored scale/Performance answers by display format. Points use bounds and the shared matrix converter; percentage is numeric and clamped to 0–100; letters map A to the highest bound. Null, empty and unsupported values return zero.

CompanyScaleAnswerScoreCalculator normalizes a scale answer; CompanyPerformanceAnswerScoreCalculator normalizes its stored Performance value, rather than running OPRGenerator. CompanyWeightedAnswerScoreCalculator first uses an overridden score when present; otherwise:

score = sum(normalized answered subquestion score × positive weight)
        / sum(included positive weights)

It skips nonpositive weights, missing options and null values; returns zero if no eligible weight remains. It does not enforce that runtime included weights total 100%. The configuration UI’s 100% validation and runtime denominator serve different purposes. A matrix value of zero can therefore represent missing/invalid data in these calculators; it is not always a genuine lowest assessment.

SML — indicator storage and section calculation

Verified in code: the legacy routing prefix is /company/review. ReviewIndicatorController reads/saves campaign indicators and their options. Supported branches include choice, select and range. ReviewIndicatorItem holds options; ReviewUserIndicator holds a participant’s selected value.

DefaultController::performanceAction serves /company/review/update/performance: reads option, participant review and indicator, creates or updates a ReviewUserIndicator, persists the selected option and returns the indicator label. It does not calculate a skills/goals Performance score. Its action name is not evidence of equivalence to SMR Performance.

ReviewAssessmentController::getSectionsScoreAction requires an AJAX request and an existing participant, questionnaire and user; it calls SectionScoreHelper::calculatesScoreOfSections, then saveCalculatedScoreOfSections, returning sectionsScore. This read-like calculation flow also persists results: do not invoke it merely to inspect production data.

The helper walks questionnaire questions in position order:

1. A section initializes sum, average and answered-question count at zero; reads its associated indicator and result bands.
2. A choice question contributes only inside an indicator-bearing section when choices_scores exists and sums to a positive value. For an existing answer, it sums the selected items’ extra.score values and increments the denominator once per answered question, not per choice.
3. A range question contributes when hints_scores exists with a positive sum and the stored answer response is greater than zero. It uses hints_scores[response − 1], then increments the denominator.
4. For indicator-bearing sections with an eligible count, average = sum / answered-question count, formatted to two decimals. Missing answers do not increment that count. Empty sections retain an average of zero.
5. It checks inclusive indicator bands (from ≤ average ≤ to); without a match, the initial label is pas d’étiquette. Overlapping bands are iterated in order, so a later match can replace an earlier label.
6. The save helper upserts a ReviewUserScore by participant and section question with the section average.

Illustrative code-based example: one answered choice question totals 6, one eligible range question scores 4: (6 + 4) / 2 = 5.00. An unanswered third question is excluded from the denominator. This is not SMR’s weighted participant/component formula.

The SML mechanism can support business-named indicators, but the inspected code does not establish a universal mapping to all four SMR scores, independent company version histories, compatible normalized scales, or automatic migration. These remain not verified.

SMR Performance — target contract and history

The Performance PRD, version 3 (21 October 2026), defines the target behavior documented here.

Element	Target rule
Versions	Every company configuration change creates a new version; each score has an independent history. Historical versions are read-only.
Label	A required configurable label is reused in the review, PDF and history.
Normalized value	Advanced Performance is represented by an integer from 0 to 100, independently of display format.
Contributions	Use available partial answers and exclude participants without a contribution. Split reviewer weight equally between two evaluators; without the second evaluator, that share goes to the primary evaluator.
Letters	Convert the normalized value to the letter range; +/− modifiers indicate rounding direction. Preserve the underlying normalized value.
Override	Preserve calculated and final values, justification, author and the visibility policy used for the review.
Visibility	After override, original score, detail and justification are shown together to Employee and Second Evaluator according to Always, Never or Only when overridden score is higher. Compare normalized values; equality does not qualify.
PDF	Apply the same visibility rules as the review.
Profile history	At finalization, retain displayed and normalized results, comments, campaign/review reference and configuration version. A new version does not recalculate past reviews.

PRD section 44 leaves precise letter conversion anchors, partial-data aggregation normalization and the complete historical schema to detailed engineering specifications.

Permissions, failures and runtime

Verified in code: the SMR criteria route requires authentication. This alone does not prove administrator-only server access. The PRD defines company setup as Admin and scoring/override as primary evaluator; effective tenant permissions and complete backend guards need verification before an integration relies on them. Legacy AJAX checks likewise do not establish authorization. See Roles and permissions.

Investigate failed question/configuration calls, incompatible criterion references, incomplete required labels, missing Performance source data, signed/finalized review locks and unexpected zeros separately. Frontend errors/logs can identify the failing operation, but no dedicated score monitoring dashboard, asynchronous calculation job, refresh schedule or retry guarantee was established. Use redacted diagnostics; never include employee assessment payloads, credentials or private comments in support examples.

The verified runtime paths use frontend components, backend services and persisted review/question entities; SML uses Symfony controllers, Twig and Doctrine. No new deployment service is established for this feature. Extension points are criterion metadata, question types/validators, campaign source resolution, score calculators and display conversion. A new type must preserve type checks, version references and participant visibility across consumers. The target profile history retains the configuration version and normalized values for later reuse.

Evidence and limitations

Inspected local repositories on 28 October 2026; these paths identify sources, not a deployed commit guarantee.

Repository	Sources / responsibility
smartmobility-nextgen-front	src/modules/CompanySettings/CriteriaConfiguration.vue; BasicConfiguration/criteria.constants.ts; BasicConfiguration/components/Performance/PerformanceConfigurationStep.vue, EvaluationSkillConfiguration.vue, ObjectivesConfiguration.vue, SkillsGoalsWeightDistribution.vue; Potential/RiskOfLoss/ImpactOfLoss configuration step components; api/company.api.ts; src/router/private-routes.ts. Paths under BasicConfiguration are relative to CompanySettings.
smartmobility-nextgen-front	src/modules/ModuleConfig/Campaigns/modules/Reviews/api/review.api.ts; review Performance display components and campaign advanced-score settings.
smartmobility-nextgen-back	src/Infrastructure/Persistence/Validator/Company/Configuration/ criterion validators and shared abstract validator; src/Domain/V2/Company/DTO/Question/Performance/CompanyPerformanceQuestionDTO.php; Performance entity under src/Infrastructure/Persistence/Entity/Setting/Question/Performance/.
smartmobility-nextgen-back	src/Infrastructure/Persistence/Service/Review/OPRGenerator.php, OprManager.php; Service/PeopleReview/CompanyAnswerValueNormalizerTrait.php, CompanyScaleAnswerScoreCalculator.php, CompanyWeightedAnswerScoreCalculator.php, CompanyPerformanceAnswerScoreCalculator.php under the same Persistence root.
smartmobility-legacy	src/Company/ReviewBundle/Controller/DefaultController.php, ReviewIndicatorController.php, ReviewAssessmentController.php; src/Company/AssessmentBundle/Service/SectionScoreHelper.php; entities ReviewIndicator, ReviewIndicatorItem, ReviewUserIndicator, ReviewUserScore under src/Main/ConfigBundle/Entity/; config/routes.yaml and ReviewBundle routing.
aihub	Targeted search in src for the four score concepts; no scoring dependency established.

Observed in application: eight full-window Chrome screenshots of SMR company configuration, 28 October 2026. Verified in code: paths and formulas above. PRD specification: the supplied PRD, including section 12 on goal participation weights. Inferred: meaning of the business criteria where no numerical model is defined. Not verified: live SML workflow, client mappings of four business names, deployment parity, complete access-control coverage, full review/override/PDF/profile lifecycle and migration. No application source, settings or database was modified.