Input quality examples

AvelinLabs is designed to return confidence-aware decision-support signals, not just a best-effort label.

Lower confidence, higher uncertainty, ambiguity flags, weak-signal warnings, or review routing can be useful and expected outputs when the input lacks enough occupational evidence. These examples show interpretation patterns, not guaranteed exact JSON output or fixed field values.

The practical question is:

What happens when I send AvelinLabs a strong job description versus a weak, vague, ambiguous, or noisy one?

Why input quality matters

Strong job descriptions usually provide enough evidence for higher-confidence occupation alignment. They often include a clear title, responsibilities, required skills, domain context, and enough text to infer both occupation fit and skill evidence.

Weak or ambiguous inputs should often produce more cautious signals. Depending on the endpoint response and available evidence, that may mean lower confidence, higher uncertainty.total, is_ambiguous, domain_is_ambiguous, weak_signal_detected, a decision.decision such as REVIEW or AMBIGUOUS, or less complete skill and explanation evidence.

Good evaluation should include both strong and weak inputs. The goal is not to force every response into a confident result. The goal is to see whether AvelinLabs gives your workflow enough structure to decide what can be automated, what should be reviewed, and what needs better upstream input.

Example 1: strong job description

Input

Title: Business Intelligence Analyst

We are hiring a Business Intelligence Analyst for our revenue operations team.
The role builds SQL queries, creates dashboards in Power BI and Tableau,
analyzes sales pipeline trends, partners with finance and customer success,
and presents reporting insights to leadership. Candidates should understand
data modeling, KPI design, spreadsheet analysis, dashboard QA, and stakeholder
requirements gathering in a B2B software environment.

Expected interpretation

• likely stronger occupation alignment because the title, tasks, skills, tools, and domain context point in a consistent direction
• clearer O*NET match or ranked occupation candidate set
• more useful job_signals and results[].matching_skills
• stronger results[].explanation.why_match because there is enough evidence to explain the match
• lower review burden when confidence, trust_score, uncertainty.total, ambiguity fields, and your product policy support it

Example 2: title-only input

Input

Support Specialist

Expected interpretation

• potentially ambiguous occupation space because the title could refer to customer support, technical support, operations support, HR support, or other areas
• limited skill evidence because there are no responsibilities, tools, domain details, or seniority signals
• lower confidence, higher uncertainty, ambiguity flags, weak-signal warnings, or more review-oriented routing may be appropriate
• evaluators should not treat lower confidence as a system failure when the input itself does not contain enough evidence

Example 3: vague or generic job text

Input

Title: Analyst

We need someone who can help the team with reports, communicate with
stakeholders, use internal systems, support projects, and improve processes.

Expected interpretation

• weak-signal handling is important because the text contains broad workplace language but little occupation-specific evidence
• the response may need review routing, lower confidence, higher uncertainty, or weak-signal context
• ranked candidates may still be useful for review, but should not be treated as final without more context
• this can reveal an upstream intake improvement opportunity: collect clearer responsibilities, tools, domain, seniority, and required skills before automation

Example 4: ambiguous role title

Input

Title: Implementation Consultant

Own customer implementations, configure workflows, train users, gather
requirements, coordinate launch plans, and help account teams resolve rollout
issues after kickoff.

Expected interpretation

• ambiguity signals are useful product outputs because the role could sit near customer success, software implementation, business operations, training, sales engineering, or consulting workflows
• is_ambiguous, domain_is_ambiguous, decision.decision, and decision.reason can help decide whether to show a result, ask for review, or request missing context
• ranked candidates can guide follow-up questions, such as whether the work is primarily technical configuration, customer training, project management, or business consulting
• reviewers should inspect results[], results[].matching_skills, and results[].explanation.why_match, not only the top title

Example 5: noisy or non-occupational input

Input

Q3 hiring notes: budget not approved yet. Move the planning meeting to Friday.
Need someone for the CRM rollout, maybe dashboards, maybe training. Remote is
preferred. Add the hiring manager's comments later.

Expected interpretation

• insufficient evidence or weak signal should be surfaced when the text is mostly planning notes rather than a job description
• AvelinLabs should not be expected to force a confident occupation match from mixed, incomplete, or non-occupational content
• review routing, weak-signal warnings, ambiguity flags, higher uncertainty, or limited explanation evidence can be the right product behavior
• customers should separate role requirements from notes, scheduling details, budget comments, or other non-role content before relying on automation

How to use these examples in evaluation

Use these examples with the Evaluate AvelinLabs in your workflow, Response Field Reference, and Output Interpretation guides.

Teams should test:

• strong known-good examples
• weak real-world examples
• ambiguous role titles
• noisy or incomplete inputs
• domain-specific job descriptions

Compare interpretation patterns across those inputs. Strong examples should usually provide clearer occupation evidence, better skill evidence, and stronger explanations. Weak, vague, ambiguous, or noisy examples should help you evaluate whether confidence, uncertainty, ambiguity, weak-signal, and review-routing signals behave usefully for your workflow.

What to measure

Use response-derived metrics rather than a single pass or fail result. The Response Field Reference metrics section describes practical measures you can derive from beta responses.

For input quality evaluation, measure:

• high-confidence occupation coverage
• review rate
• ambiguity rate
• weak-signal rate
• explanation coverage
• skill-evidence coverage
• uncertainty distribution

Interpret those metrics by input type. A higher review rate on title-only, vague, ambiguous, or noisy inputs may be expected and useful. A stronger output on high-quality job descriptions is only one part of the evaluation.

Practical evaluator checklist

• [ ] I tested strong and weak inputs.
• [ ] I reviewed how confidence changes by input quality.
• [ ] I inspected ambiguity and weak-signal fields.
• [ ] I reviewed matching skills and explanations.
• [ ] I decided which outcomes should route to automation versus human review.
• [ ] I identified upstream input-quality improvements.