How Ceravio interprets preparation evidence

Scope and limits

This version describes the controlled software preparation pilot and the separately identified role-discovery, target-planning and Job Inbox features. Software depth currently supports frontend, backend and full-stack preparation. The discovery catalog spans 13 families, with a small authored set of role names and aliases; it is not a complete occupation directory or a reviewed preparation pack for every family.

Thresholds, weights, tasks and freshness windows are provisional product policies. They are not employer hiring bars, offer probabilities or validated measures of intelligence or employability. Reliability, fairness, real-world transfer and workload suitability need evidence from real participants. A recorded activity, a passed bounded drill and reviewed work have different meanings.

Evidence authority, freshness and uncertainty

SELF_REPORTED means the learner supplied a claim. OBSERVED means a bounded activity or check produced a record; it does not establish broad mastery. VERIFIED means a trusted review supplied evidence for a defined scope and rubric. Verification does not extend to unrelated skills or employer outcomes. Missing evidence means not assessed, not incapable.

Freshness is separate from authority: reviewed evidence can become stale. Policy confidence values are weights or thresholds used by a particular method, not calibrated probabilities that a learner is competent. A result should name its evidence, rubric or algorithm version, assessment time where retained, remaining uncertainty and the work that could change the decision.

Software depth: reviewed evidence coverage

Software depth uses software-depth-2026-09-v1. For each competency it selects stronger-authority evidence before weaker-authority evidence, then the newest within that authority. A newer failure at the same authority replaces an older pass. An expired selected record stays selected so an old pass cannot reappear as current mastery. Invalid, unsupported and future-dated evidence is excluded.

To meet a competency threshold, selected evidence must be VERIFIED, have confidence at least 0.8, and have a raw score of at least 70 for foundation, 75 for application or 80 for interview depth. Evidence is stale after 90 days, or at an earlier explicit expiry. Required prerequisite competencies must also meet their thresholds.

A dimension's evidence coverage is the rounded weighted mean of reviewed score multiplied by confidence. Foundation, application and interview-depth competencies have weights 3, 2 and 1. A competency with missing prerequisites contributes zero; self-reported, observed and stale evidence also contribute zero. A reviewed score below its mastery threshold can contribute partial coverage. The separate count of competencies meeting their thresholds is not this percentage.

Target benchmark and legacy preparation engine

The target page's software benchmark is a separate company-neutral preparation measure. It uses broader legacy skills and curated required levels, rather than the software depth competency calculation. Its score must not be read as the same measure as reviewed evidence coverage.

The legacy engine reduces measured levels over time using skill-specific half-lives and rounds the resulting effective level. A confidence value below 0.6 makes the skill contribute zero to the score. For required levels above one, 65% of attainment is allocated across progress from level one to the requirement, and 35% is reserved for reaching that requirement. A required level of one counts only once level one is reached. Skill weights also reflect requirement importance, listing cues and authored AI-exposure weights.

Target plans distinguish mapped requirements, unknown wording and authored role foundations. Their feasibility and time estimates depend on those inputs, evidence and cost assumptions. They support preparation decisions; they do not predict recruitment success or resolve hard eligibility. This page does not establish empirical percentile calibration for preparation times.

Why a practice task is scheduled

The software schedule uses deterministic rules based on the chosen role, selected evidence, prerequisites, recent failures, overdue work, approaching milestones and declared fatigue. It explains why a task comes next, the proof expected, and what a pass or failure changes. Completing a task does not itself award verified authority.

Declared weekly time is capped at 40 hours. Planned pilot work is capped at 450 minutes, using fatigue multipliers of 1 for low, 0.8 for moderate and 0.5 for high fatigue. Time below a 50-minute effective budget leads to a short review and deferred categories rather than five full sessions. Unused time remains available for recovery or other commitments. Some observed passes can unlock guided practice without meeting verified mastery requirements.

What the bounded assessments measure

duplicate-detector-v1 and first-unique-integer-v1 evaluate a small, bounded JSON algorithm configuration; they do not execute arbitrary learner JavaScript. The second task differs from the first and requires a current owned successful first attempt. Passing a second bounded task is not validated real-world transfer.

Both results combine correctness, testing, complexity, debugging and explanation at 45%, 25%, 15%, 10% and 5%. Passing requires correctness, complexity and debugging at 100%, and testing at least 75%; it is not a total-score cutoff. Correctness uses this version's bounded cases. Testing measures how many of four authored faults valid learner tests distinguish, with a penalty for incorrect expected outputs. The second drill deduplicates submitted tests before calculating that penalty.

The first drill's explanation component checks four keyword-pattern groups. The second records four required explanation sections. Neither judges semantic correctness, originality or communication quality. Assessment evidence remains OBSERVED, with fixed policy confidence 0.65 for objective dimensions and 0.35 for explanation. A perfect explanation component therefore does not mean a human reviewed the reasoning. Hidden cases and answer keys are not published here.

Interview rehearsal feedback

software-interview-2026-09-06.1 provides six authored rehearsal modes: coding, debugging, project discussion, low-level design, system design and behavioral discussion. Five written sections are recorded for review, and one scenario checkpoint has an objective answer. Written-section presence is not scored as solution quality.

The result remains OBSERVED with fixed confidence 0.35 and a 30-day rehearsal freshness window. Code is not executed and linked artifacts are not inspected. Technical correctness, originality and communication quality still need executable evidence or human review. The next drill is a preparation suggestion, not a hiring decision.

Reviewed projects and supported application material

software-projects-v1 separates problem/architecture, implementation/testing/documentation/delivery, and reflection/demonstration milestones. A human review passes a milestone only when every applicable criterion scores at least 3 out of 4. Latest trusted, current-version milestone status controls progression. A submitted link or learner note alone is not approval.

Supported project bullets use a stricter, separate freshness rule: every current-version milestone must have a trusted approval reviewed within the last 90 days. The bullet describes only that reviewed delivery scope. It does not invent employment, impact metrics or employer outcomes. A draft sentence outside the allowed canonical bullets remains unsupported by this tool.

Software job comparison splits bounded listing text into requirements and matches authored competency phrases and aliases. Mapped competencies must meet their reviewed thresholds before a requirement can be marked supported. Language-specific, degree, experience and eligibility wording still requires manual review. Unmapped wording is not silently treated as satisfied. Review the full employer listing before relying on the comparison.

Role discovery and alias overlap

ceravio-discovery-v1.0.0 searches a small authored catalog of display names and aliases. Queries need at least two characters; matching is case-insensitive substring matching. Search results are discovery suggestions. Every family remains discovery-only until it has its own reviewed preparation pack. A link to the software pilot offers guided practice, not role qualification or eligibility approval.

The target report uses ceravio-role-resolver-v1.0.0. Its percentage is the largest fraction of words from a role name or alias found in the input. It is alias-token overlap, not a probability or a measure of transferable competence. It keeps at most three candidates above its overlap cutoff and marks competing or weak candidates ambiguous. Suggestions never automatically lock the learner's role.

An alternative with similar words is not evidence of an adjacent career pathway or a feeder route. The learner must compare actual responsibilities and confirm the interpretation. This resolver supplies no personalized preparation-time estimate or P50/P80 distribution, and does not check education, location or other hard eligibility conditions.

Listing confirmation and reported outcomes

The Job Inbox retains a captured listing and extraction history. Confirmation means the learner checked the listing fields. It does not mean an employer confirmed an application, interview or offer. Applied, interview, offer and rejection statuses are user-reported lifecycle records unless a separate verification process is explicitly identified.

Permitted corrections append transition history rather than silently rewriting the event trail. The current status describes the latest recorded stage. It is not verified placement evidence or proof that Ceravio caused an outcome. Learners can inspect exported history and correct a stage using the available controls.

Where models are used

The software coverage, schedule, bounded assessments, interview checkpoint, project gates and application phrase comparison described here use deterministic rules. Project, competency and governance reviews require human judgments. Recording text does not mean a model or a human has reviewed its quality.

The separate target-plan input may use an LLM to propose job requirements. Its proposals are processed by deterministic resolution and planning; unmapped or failed extraction must remain uncertain. Target narration is deterministic. Job Inbox extraction uses JSON-LD or deterministic text parsing. Other product features may have different model use and are outside this version's scope. No provider or model identifier should be inferred when it was not retained with the result.

Legacy assessment and resume scores and the general interview use separate evaluators; they do not inherit the software-drill or six-mode rehearsal formulas on this page. Their saved explanations describe the scope of the recorded result and retain only available provenance. If an evaluator, model or complete input was not stored, it remains unavailable. A methodology link does not supply the missing scoring history.

Human review and supervised pilot decisions

Mentor rehearsal compares authored examples; it does not certify reviewers. Governance reference versions instead preserve a staff author's proposed judgments, two other staff members' blind reviews and a separate coordinator's decision. Reference approval requires matching score vectors under the current pilot rule. Agreement with a reference does not establish real-world reviewer reliability.

A mentor's prospective assignment reserves unseen fixed tasks. First complete judgments and decisions are retained. A different staff coordinator decides supervised pilot participation, with approval duration limited to 1–90 days and a recheck due date. Task exposure, cancelled work, expiry and staff revocation can restrict subsequent use. The current two-set bank supports one initial assignment and one distinct recheck; further unseen work needs a new authored set and approved reference. These decisions do not change learner evidence or grant general professional certification.

Versions, history and unavailable methods

First published version: ceravio-methodology-v1, dated 2026-09-08. This release documents the methods and limitations above. Published versions are retained; a later scoring, threshold, source-handling or model-use change needs a new method entry and a stated change history.

New results should identify the method and algorithm version retained with them. A historical result without a method identifier may be explained as a reconstruction only when its stored algorithm version supports that mapping. Otherwise the original method is unavailable. Linking this page does not retroactively stamp an old result, recreate missing provenance or recalculate its score. Current profile computation time is separate from the time each piece of evidence was assessed.