How Ovii Reviews Job Descriptions Before They Go Live

The strongest story for JD review is not that it can rewrite text. It is that it gives recruiters a structured quality check before a role becomes the source of truth for candidates, approvers, interviewers, and downstream automation.

That distinction matters because a weak job description creates problems long before a recruiter notices low application quality. It confuses scope, distorts seniority, attracts the wrong applicants, weakens employer trust, and gives every later evaluation step a worse starting point.

Ovii's current implementation is much easier to trust when it is described as a publishing guardrail. The system is trying to catch structural gaps, clarity issues, bias language, tone problems, and role mismatch before the draft becomes candidate-facing.

Ovii is strongest when JD review is framed as a pre-publish quality gate, not as a one-click copy generator.

The create-job flow does not let the recruiter fire JD review blindly. The review handler checks for three minimum inputs first: job title, job category, and job description. If any of those are missing, the recruiter gets a direct prompt instead of a weak or meaningless review request.

The broader role-summary validation layer is also opinionated. It expects meaningful job-description content, not placeholder text. The schema strips HTML for analysis, requires at least 50 characters and 10 meaningful words, rejects descriptions with excessive repetition, and flags some discriminatory or unprofessional phrases such as ninja or native speaker.

At the same time, Ovii does not make the feature fragile by requiring every optional field to be perfect before review can run. The review payload normalizes missing experience, salary, currency, and timezone fields into safe defaults so the recruiter can still get structured feedback while the job draft is in progress.

One of the most important implementation details lives in the prompt builder. JD review does not analyze the description as a detached block of prose. It builds a structured input package around the description first.

Today that package includes job title, employment type, job category, minimum and maximum experience, country, city, currency, salary range, timezone, and the recruiter-written description. That is a much better review frame than asking a model to clean up text without knowing what kind of role the company is actually hiring for.

This is why the feature can evaluate seniority fit and context more credibly. A product-manager JD should not be reviewed like a backend engineer role, and a two-year role should not sound like a principal-level mandate. Ovii is explicitly giving the review engine the context it needs to make those distinctions.

The review is role-aware because Ovii sends structured hiring context with the JD, not just the JD alone.

The response contract is stricter than the UI first suggests. The prompt requires the review to return all ten dimensions every time: structure, clarity, inclusivity, engagement, transparency, relevance, employer branding, tone consistency, SEO, and problematic phrases.

Each dimension must return a score plus arrays for reasons, problematic snippets, suggestions, and rewrites. If a category is effectively perfect, the response is still required to include that category with a positive reason and null issue fields instead of skipping it.

That is exactly the kind of structure a recruiter-grade feature needs. It turns the review into something auditable. The recruiter can compare the full framework across jobs instead of getting an inconsistent blob of advice that changes shape every time.

Ovii does not treat the ten dimensions as a flat average. The prompt explicitly requires a weighted overall score rounded to one decimal place, with heavier weight on structure, clarity, and inclusivity than on SEO polish or red-flag phrasing.

That weighting is a meaningful product choice. It signals that a JD should not earn a flattering overall score just because it uses the right keywords or sounds polished while still missing core responsibilities or inclusive wording.

The scoring rules are also opinionated about absence versus quality. For example, if important sections are completely missing, structure should score four or below. If SEO is effectively absent, the score should stay near zero rather than drifting into a safe middle band. That makes the score more useful as a hiring-quality signal.

The overall score is a weighted judgment about JD quality, not a soft average that flatters incomplete drafts.

The output is not limited to category scores. The prompt also requires a benchmark summary with its own score, disclaimer, and notes comparing the draft against similar roles, levels, and regions. That gives the recruiter relative context instead of only an isolated number.

The frontend then turns that benchmark into something readable. It compares the JD score with the benchmark score and labels the draft as above, around, or below similar roles based on the difference between the two.

Ovii also asks for a separate candidate-perspective layer. That matters because a structurally complete JD can still create the wrong emotional impression. High-pressure cues, unprofessional wording, or confusing expectations may not always show up clearly in a pure category score, so the product keeps that lens explicit.

The rewrite path is more structured than simply asking for a better version. The prompt requires the enhanced JD to come back as a complete draft that can include an introduction, responsibilities, required skills, preferred qualifications, employer-value context, benefits, and an apply call to action where appropriate.

On the frontend, Ovii then formats that returned text into editable HTML. Section-like lines become headings, bullet-style lines become lists, and plain text becomes paragraphs so the recruiter can review it in the same WYSIWYG environment used for the original JD.

The important trust point is what does not happen. Accepting the enhanced JD only writes the rewrite back into the editor. It does not publish the job, bypass approvals, or replace recruiter judgment. The rewrite is assistive, not authoritative.

Accept JD writes the enhanced draft back into the editor, but it does not auto-publish or override recruiter ownership.

The backend path is also more deliberate than a raw one-shot API call. The review client sends a low-temperature structured request, retries transient failures up to three times with exponential backoff, strips JSON code fences if they appear, and only then attempts to parse the result into JSON.

If the review still fails after retries, the client returns an empty JSON object instead of crashing the recruiter flow with a null pointer. That is a small but important product-quality detail. It means the UI can fail gracefully, surface an error, and let the recruiter keep moving.

That does not make the feature infallible, but it does show the feature is being treated like infrastructure rather than a demo flourish.

Ovii adds retry, backoff, JSON cleanup, and safe fallback behavior so JD review behaves like a real product feature.

The controller does more than forward a prompt. It resolves the acting user and company from auth, blocks the operation if company context is missing, and enforces premium access through the subscription service before running the review.

After a successful review, Ovii records usage with company, feature, user, and job context. There is even extra logic to resolve the relevant job when the request is tied to an existing role: the controller can use an explicit `jobId`, infer one from the page referer, or resolve it through the job requisition ID within the company.

That is the kind of detail that makes the feature easier to govern at scale. JD review is not an anonymous sidecar call. It is a tracked hiring action inside the company workflow.

The help doc explains how to read the drawer. The stronger blog story is why the feature deserves trust. Ovii checks for minimum role inputs, carries structured job context into the review, forces a consistent ten-part scoring contract, weights the overall score toward the dimensions that matter most, returns benchmark and candidate-perspective outputs, keeps the rewrite editable, and governs access and usage as a real product capability.

That is a much stronger narrative than saying the system can improve your job copy with AI. What Ovii is really doing is helping recruiters publish cleaner, fairer, more role-accurate job descriptions before those drafts shape the rest of the hiring workflow.

That is the feature story worth publishing, because it shows the product is trying to improve hiring quality at the point where clarity and trust first enter the funnel.