A job title is not a decision

A hiring team asks for a Senior Analyst.

The role description mentions stakeholder workshops, SQL analysis, and client-ready communication. The title is familiar. The requirements sound reasonable. A generic AI system can immediately produce a polished assessment:

The role requires business analysis, stakeholder communication, SQL, and problem solving. Interview for those capabilities.

The answer is plausible. It is also insufficient for a consequential decision.

It does not show what the customer means by client-ready. It does not establish the required level of SQL. It does not say whether evidence documentation is mandatory. It cannot identify when ambiguity must be escalated because it has not been given the customer’s review policy.

The central problem is not that the model failed to recognize the occupation. The problem is that a generic description has been mistaken for the customer’s decision criteria.

The hidden gap

A standard occupation profile and a customer role framework answer different questions.

Evidence	Question it can answer	Question it cannot answer alone
Occupation taxonomy	What established occupation does this role resemble?	What does this customer require from the role?
Market evidence	What does the external labor market look like?	Which constraints can this customer relax?
Job description	What has been written about the opening?	Which statements are essential, preferred, or accidental?
Customer framework	How does this organization define and review the role?	How common or available is the role in the market?

Each evidence family answers a different question. The assessment should preserve those boundaries instead of silently blending them.

A defensible assessment keeps these evidence families separate. It should not silently blend them into one confident paragraph.

The customer adds one source

In the public synthetic example, the customer source contains a criterion that cannot be inferred safely from the title:

Senior analysts translate ambiguous client needs into decision-ready requirements.

The request then provides the specific role context and asks AvelinLabs to focus on requirements clarity, stakeholder communication, and evidence review:

{
  "include_passport": true,
  "role_title": "Senior Analyst",
  "role_context": "The role supports HR advisory clients with intake clarification, requirements workshops, SQL analysis, and evidence-backed review guidance.",
  "focus_areas": [
    "requirements clarity",
    "stakeholder communication",
    "evidence review"
  ],
  "source_ids": ["synthetic-role-criteria"],
  "top_k": 5
}

Inspect the complete request on GitHub.

This changes the question.

Instead of asking:

What does a Senior Analyst usually do?

the workflow can ask:

Which customer-defined criteria are supported by the available source, and what remains unresolved?

What the grounded response adds

The synthetic response returns a criterion linked to customer evidence:

Clarify ambiguous client requirements and maintain traceable review evidence.

It also returns the supporting excerpt:

Senior analysts translate ambiguous client needs into decision-ready requirements.

The connection between conclusion and source remains visible through the evidence, source, artifact, and trace identifiers.

Returned signal	Synthetic fixture value	Why it matters
Evidence relevance	0.78	Shows the retrieval relationship instead of hiding it
Report confidence	0.72 / medium	Communicates assessed strength without claiming certainty
Evidence scope	customer_private	Preserves the tenant boundary
Citation locator	paragraph 1	Makes the supporting passage inspectable
Trace ID	trace_rg_synthetic_001	Connects the output to its decision record

These values are part of a synthetic contract fixture. They are not model-performance metrics, a customer outcome, or proof of hiring validity.

Inspect the complete grounded response.

What the response refuses to imply

A useful evidence system must show absences as clearly as supporting evidence.

The example states that evidence freshness is not_assessed. It records that the assessment is grounded only in customer-owned evidence available for the request. It does not claim that the role is easy to hire, correctly compensated, or aligned with current regional demand.

Those questions require other evidence families:

• O*NET or SOC references for occupation structure;
• OEWS for occupational employment and wage evidence;
• QWI for separate industry workforce-flow evidence;
• current, approved demand evidence when available;
• human confirmation of local constraints and trade-offs.

Customer grounding makes the answer locally relevant. It does not make the answer complete.

The Decision Passport preserves the boundary

The optional Level 1 Decision Passport packages the decision context so that another reviewer can understand how the output was produced.

In the fixture it records:

• the decision type and status;
• purpose and tenant scope;
• evidence coverage and references;
• confidence and evidence sufficiency;
• limitations;
• abstention and human-review status;
• decision-contract and policy versions;
• request and decision trace identifiers.

The trace connects the final review to the original request, evidence, limitations, and decision contract.

This is materially different from attaching a confidence number to generated prose. The Passport preserves both the supporting chain and the declared limits of the decision.

See Decision Passport documentation for the public contract and boundaries.

Why a better benchmark may make the model look worse

Once the customer’s actual criteria are visible, an earlier assessment may lose confidence or require clarification.

That is not necessarily regression. It can reveal that:

• the title covers more than one occupation;
• a stated requirement is underspecified;
• customer policy conflicts with the generic market pattern;
• available evidence supports only part of the requested decision;
• the workflow should abstain or route the case to review.

A system optimized only to produce confident answers will tend to hide these conflicts. A decision layer should expose them because they determine the next responsible action.

A practical review sequence

For a customer-grounded role assessment, the reviewer should be able to follow this sequence:

1. Confirm the decision. What action will this assessment support?
2. Inspect the customer source. Which document or framework defines the local criteria?
3. Separate requirements. Which criteria are required, preferred, or still ambiguous?
4. Review the evidence link. Which excerpt supports each returned criterion?
5. Check confidence and limitations. What was assessed, and what was not?
6. Add external evidence where needed. Occupation, wage, industry, and demand evidence answer different questions.
7. Record human judgment. Accept, revise, clarify, or abstain—with a reason.

The result is not an automated hiring decision. It is a reviewable evidence package for a human-led workflow.

Run the public example

The examples repository contains three useful entry points:

• Customer Grounding workflow — requests, responses, sample files, and validation.
• Level 1 Decision Passport response — the complete synthetic fixture discussed above.
• Local demo application — a guided API-backed workflow using synthetic content.

The local demo registers a source, ingests approved synthetic context, generates a grounded Role Intelligence report, exposes evidence and trace details, and deletes the temporary source when the exercise is complete.

The real difference

The job title did not change. The model did not suddenly learn a better definition of Senior Analyst.

The decision improved because:

• customer criteria became explicit;
• the supporting passage became inspectable;
• confidence and uncertainty became separate signals;
• unsupported claims remained outside the boundary;
• the output could be traced and reviewed.

That is the practical purpose of customer grounding: not to make generated text sound more specific, but to make a workforce decision show its work.