Workforce Decision Layer

Avelin does not simply expose workforce data. It applies a governed layer of interpretation so applications and reviewers can see the proposed result, the strength and limits of its support, and the cases that need human attention.

High-level Avelin Decision Layer architecture connecting evidence, context, confidence and human decisions.

What is a decision layer?

A decision layer is a controlled workflow that turns workforce inputs into structured decision support. It makes evidence, confidence, uncertainty, and review guidance explicit.

For Avelin, this means exposing, where the endpoint contract supports it:

what was evaluated,
how it influenced the outcome,
which source families informed the result,
and when a human should review before action.

What makes this a workforce decision layer?

The workspace is workforce-focused:

role and workforce context,
occupation intelligence,
labor-market context,
tenant-scoped frameworks and policies through Customer Grounding,
request context (for example role text, role title, and location).

These inputs support role calibration, hiring intake, market-aware planning inputs, and customer-grounded role analysis. They do not constitute an autonomous hiring or workforce-planning engine.

Why data or analytics alone is insufficient

A data layer or analytics layer can return scores and matches, but it may not answer:

whether evidence is missing,
whether signals disagree,
whether confidence is strong enough,
whether the result should be routed to review.

A workforce decision needs traceable evidence handling before automation or escalation.

Evidence and source authority

Avelin keeps four currently available evidence roles distinct:

Request evidence: role title, description, and other caller-supplied context for the case being evaluated.
Occupational reference evidence: the local O*NET 30.3 model describes occupations, skills, tasks, and related attributes; it is not proof of current demand.
Observed market evidence: Avelin market aggregates describe represented job postings for the returned scope, country, and time window; they are not official employment statistics or universal totals.
Customer Grounding evidence: approved tenant-scoped sources describe that organization’s roles, frameworks, rubrics, policies, or operating guidance; they do not become shared market facts.

Source authority answers “what can this source support?” Provenance answers “where did this item come from?” They are related but not interchangeable. Job-intelligence endpoints expose input and O*NET-grounded result context. Grounded reports go further by returning source, artifact, evidence, snapshot, and trace references.

Confidence, trust, and coverage are different

The job-analysis contract exposes several signals with different meanings:

top-level confidence is the calibrated winner-strength signal for the response;
results[].confidence is a probability distribution within the returned ranked list;
trust_score combines raw winner strength with top-result quality support;
uncertainty, ambiguity, weak-signal, and quality fields explain limits that a single score cannot;
decision.decision provides AUTO_ACCEPT, REVIEW, REJECT, or AMBIGUOUS routing under the runtime policy.

These values are not accuracy guarantees, source-authority scores, or interchangeable measures. Use the Response Field Reference for exact field semantics.

Coverage and freshness are also endpoint-specific. Market responses expose scope, represented counts or percentages, and defined time windows. Customer Grounding preserves source versions and retrieval references. The current public contract does not provide one universal freshness or evidence-coverage score across every endpoint, so applications must retain the returned scope and avoid filling gaps with unsupported assumptions.

Decision Passport relation in this slice

Decision Passport is an optional projection for a controlled-beta Customer Grounding report.

It is only an output shape on top of:

POST /api/v1/grounding/role-intelligence/reports
the existing report payload fields
the same tenant-aware trace semantics already returned by Grounding endpoints

There is no separate Passport endpoint.

Confidence, trust score, coverage, authority, and freshness are distinct in this slice:

confidence is an endpoint-specific support signal.
trust_score is not yet a governed metric for this slice and can be not_assessed.
evidence coverage can be measured, limited, or unavailable depending on declared focus areas.
evidence authority explains what family of inputs supported each piece of evidence.
freshness is not_assessed where no governing freshness policy is available.

Treat these values as complementary, not interchangeable.

How disagreement and uncertainty are handled

Avelin does not force certainty.

Weak or incomplete inputs can produce lower confidence, weak-signal or quality indicators, ambiguity, and REVIEW or REJECT routing on job-intelligence endpoints. Occupation candidate retrieval can return no candidates when support is insufficient. There is no universal abstain field across the API; applications should treat endpoint-specific low-support outcomes as a reason to clarify, stop, or review.

These outputs can be routed by policy:

keep low-confidence outcomes in a human review queue,
avoid overconfident automation,
preserve traceability for investigation.

What workforce decisions it can support

Current supported decision-support areas include:

role alignment and role intake standardization,
skill evidence and related context,
grounded role intelligence,
market-aware workforce planning context.

Avelin is used by applications and reviewers to make better decisions. It does not make final hiring or placement decisions.

When is human review required

Human review is appropriate when evidence quality is low, context is missing, signals are ambiguous, or the downstream policy mandates review for high-impact outcomes. Avelin’s routing fields support that policy; they do not define the customer’s legal, professional, or approval obligations.

The layer is intentionally designed to expose these cases.

How this differs from adjacent pages

Why Avelin explains the problem and commercial boundary.
Architecture explains system boundaries and information flow.
API explains the integration surface and endpoint usage.

Decision flow

Workforce question + context
    |
    v
Endpoint-specific evidence gathering
    |
    v
Decision support output
  + confidence
  + uncertainty
  + evidence references where available
  + review guidance
  + trace references for grounded reports

Availability boundary

Job, occupation, and market intelligence are available through the documented REST API. Customer Grounding, grounded reports, trace summaries, and its customer-operated MCP adapter remain controlled beta and require an authorized Runtime API Key contract. Future evidence sources and portable decision-record formats are roadmap work, not current public capabilities.