How Ovii Structures Job-Specific Hiring Pipelines

Many recruiting products reduce pipeline customization to a rename screen. A recruiter changes Screen to Recruiter Call, adds one extra stage, and the product calls the workflow tailored. That sounds flexible, but it is not enough for teams that need structured evaluation and defensible decision flow.

Ovii is working at a different layer. In the current product, job customization is not only about stage labels. It shapes how interview evidence is collected, how candidates move through the workflow, and how resume fit is scored for that specific role.

That distinction matters because once hiring starts, configuration becomes governance. If the evaluation lens, stage order, and ranking logic are unstable, the recruiter loses trust in the process even if the UI still looks neat.

Ovii treats pipeline customization as job-level operating configuration, not as a cosmetic stage editor.

One of the strongest design choices appears at job creation time. Ovii first ensures the company-level status catalog exists, then snapshots that catalog into job-specific `JobStatusDefinition` records for the new role. In other words, a job does not keep reading a shared company pipeline live forever. It gets its own copy.

That matters because per-job customization becomes safer. A recruiter can reshape one role without silently mutating the operating model for every other job in the company. The system preserves the company baseline, but the live workflow that candidates move through is scoped to the job itself.

The service also has a separate `ensureIntakeStatus` path for source-style stages such as `APPLIED`, `UPLOADED`, `REFERRED`, and `VENDOR`. Those can be created lazily when resume upload or application flows need them, which is another sign that the pipeline is treated as real workflow infrastructure rather than a static list.

The help-doc view is correct to group customization into one panel, but the code shows that the panel is actually governing three different systems. One path manages interview feedback templates. Another manages the stage pipeline. A third manages resume-match scoring weights.

That separation is important because each control solves a different problem. Feedback forms standardize interviewer evidence. Pipeline stages define operational movement and handoffs. Resume-match weights tell the ranking engine what matters most for this role before a recruiter starts reviewing large volumes of resumes.

A mature hiring product should keep those concerns separate while still presenting them as one job setup surface. That is exactly what Ovii is doing here.

The feedback-form path is more structured than a lot of recruiter tools. Ovii tries to load a job-level template first. If none exists, the UI can fall back to the category template so the recruiter still starts from a sensible baseline instead of an empty screen.

When the recruiter edits the form, the builder converts comma-separated criteria into a normalized section structure where each criterion becomes a rating field under a named evaluation section. That means the recruiter is not only saving some freeform notes about what to ask. They are saving the rating shape that the interviewer will use later.

There is also governance around approval and locking. After save, the UI explicitly approves the feedback template. On the backend, approval metadata is stored on the job, and the approval endpoint itself is restricted to HR, org-admin, or org-sensitive roles. Once actual interview feedback exists for the job, template editing can be locked so the rubric does not shift halfway through live evaluation.

Ovii stores feedback forms as structured job-level rubrics, then locks them once real interview evidence starts accumulating.

A subtle but important implementation detail sits inside the pipeline replacement service. Ovii does not blindly delete every stage and recreate the whole pipeline from scratch on each save. It uses an upsert-style replacement path that updates existing stage records in place when their IDs are already known.

That is a stronger design than it may seem at first glance. Candidate applications already point to specific job-status records. If the system threw those away carelessly, stage history, references, and reporting could become brittle very quickly.

Instead, existing stages can have labels, order, category, and active state updated in place. New stages receive unique codes derived from their labels. The result is that customization stays flexible without treating stage identity as disposable.

Ovii replaces pipelines with an upsert strategy so live application references do not break every time a recruiter edits the workflow.

The strongest trust signal in this area is that Ovii becomes more conservative once the workflow is live. At the controller level, pipeline replacement is blocked if interview feedback has already been submitted for the job. That is a full lock, because by that point the evaluation workflow is already underway.

Inside the pipeline service, the rules get even more specific. The code checks whether candidates already exist in pipeline stages, not merely whether the job has any applications at all. If a specific stage already has candidates in it, that stage cannot simply be deactivated. And if candidates exist anywhere in the pipeline, removals are handled conservatively instead of letting recruiters delete their way into broken state.

That is exactly how a serious workflow tool should behave. Early configuration can be flexible. Midstream configuration should protect the evidence trail and stage history that live candidates already depend on.

The pipeline code also distinguishes between ordinary recruiter-defined stages and system-significant stages. Labels containing Assessment, Async Video, or Video Screen are treated as protected stages. They can be deactivated in some flows, but they are not supposed to behave like disposable custom labels.

Source and intake codes such as `APPLIED`, `UPLOADED`, `REFERRED`, and `VENDOR` are treated even more carefully. Those are explicitly preserved outside ordinary pipeline customization, because resume upload, job-board application, referral, vendor, and candidate-discovery flows all rely on them.

This is one of the clearest reasons the blog should not talk about pipeline management as if it were a simple drag-and-drop feature. Stages in Ovii are part of how assessments, async video invitations, uploads, and downstream application handling stay connected.

Assessment, async video, and intake-source stages are workflow infrastructure in Ovii, not decorative stage text.

Ovii also treats approval as a real state, not as a UI flourish. Jobs store whether the pipeline is approved, along with approval timestamps and actor metadata. If a recruiter edits an already approved pipeline, the backend resets approval before replacing the statuses. The UI then explicitly approves again after a successful save.

That explicit approval state matters because other parts of the hiring workflow depend on it. In the recruiter drawer and related flow checks, Ovii reads pipeline approval and feedback-template approval before encouraging candidate progression. Assessment and async video stages also check whether the relevant question sets exist before recruiters push candidates into those automated paths.

In practice, this means job setup is expected to stabilize before the process goes operational. That is a much stronger story than letting half-configured stages, templates, and question banks drift into live use.

The third control in the customize panel is easy to underestimate, but the implementation is stronger than a generic slider demo. The current scoring config defaults to 45 percent experience match, 40 percent skill match, and 15 percent education match, while certifications, domain relevance, and notice period start at zero.

Those weights are validated to sum to 100 both in the UI and in the backend DTO and controller. Saving them creates or updates a job-specific scoring configuration. Resetting the job to defaults is not a visual reset only. The backend deletes the custom config so the job truly falls back to the system baseline.

Most importantly, the scoring engine actually reads these weights later. The resume scoring router loads the job config and passes it into the scoring path for that job. The prompt builder then uses the chosen weights in the explicit match-score formula and asks for evidence-for, evidence-against, and reasoning for each weighted category.

Resume-match weights in Ovii are not display preferences. They become the actual scoring formula used for that job.

The weighted resume-scoring path is also more inspectable than a single opaque percentage. Experience is broken into sub-criteria such as years of experience, seniority alignment, role relevance, and industry fit. Skill match looks at required skills, tools and technologies, and soft-skill evidence. Education checks degree level and field relevance.

If the recruiter allocates weight to optional categories, the breakdown expands further. Certifications can be evaluated separately. Domain relevance can cover industry match and regulatory familiarity. Notice period can become part of the scoring logic when time-to-join matters operationally.

That is worth explaining in a blog because it shows Ovii is not only storing recruiter preferences. It is translating those preferences into a more explicit ranking contract.

The pipeline path is also governed at the platform level. Custom pipeline editing is protected behind the `PIPELINE_CUSTOMIZATION` feature gate, and the backend records usage once per job rather than pretending these are invisible UI tweaks.

Pipeline updates are also written to the audit log as a `JOB_PIPELINE_UPDATED` action with the job title, status count, and saved stage list. That matters because in enterprise hiring, one of the most important questions is not only what the workflow is, but who changed it and when.

This is another reason the blog should lean into trust instead of generic flexibility language. The product is already treating customization as part of the governed hiring system.

These details become important the moment a role stops being a setup screen and starts becoming a live process. Candidate progression, interviewer feedback, assessment readiness, async video readiness, application intake, and recruiter review all depend on job-level configuration staying coherent.

If the feedback form is too generic, the panel records weak evidence. If the stage map is unstable, recruiters lose track of where candidates really are. If resume scoring is generic, ranking becomes harder to defend. And if all three are changed carelessly after candidates are already in motion, the workflow stops feeling trustworthy.

Ovii's current implementation is strongest when we explain it as a governed hiring surface: set the operating model for the role early, lock the parts that should not drift later, and let recruiters make deliberate changes before the workflow becomes live.

The help doc explains how to use the panel. The stronger blog story is what the panel really represents. It is not merely a place to customize labels. It is where the recruiter defines the evaluation lens, the candidate movement map, and the ranking policy for a specific job.

That is a much better trust story for Ovii. Buyers and recruiters can see that the product is already doing the hard parts: job-scoped pipeline snapshots, scope-aware rubric resolution, stable stage identity, explicit approval, conservative midstream edits, and job-specific resume scoring.

When we write feature blogs at this level, the product starts reading less like a marketing claim and more like a hiring system that has actually been thought through.