Output Interpretation
AvelinLabs outputs are designed as decision-support signals for applications, dashboards, and workflows.
Complete executable examples belong in the AvelinLabs API examples repository.
Shared Decision Fields
Section titled “Shared Decision Fields”confidence
Section titled “confidence”Meaning: Overall confidence signal. It helps rank or route results but should not be treated as absolute truth.
confidence_level
Section titled “confidence_level”Meaning: Human-readable confidence category intended for display and review workflows.
trust_score
Section titled “trust_score”Meaning: Trust-oriented score combining result strength and quality support.
uncertainty.aleatoric
Section titled “uncertainty.aleatoric”Meaning: Signal for uncertainty associated with noisy or ambiguous input evidence.
uncertainty.epistemic
Section titled “uncertainty.epistemic”Meaning: Signal for uncertainty associated with limited support in available evidence.
uncertainty.total
Section titled “uncertainty.total”Meaning: Combined uncertainty signal.
decision.decision
Section titled “decision.decision”Meaning: Routing label such as AUTO_ACCEPT, REVIEW, REJECT, or AMBIGUOUS.
decision.decision_score
Section titled “decision.decision_score”Meaning: Numeric signal supporting the routing label.
decision.reason
Section titled “decision.reason”Meaning: Human-readable explanation for the routing label.
decision.applied_rule
Section titled “decision.applied_rule”Meaning: Rule identifier for the routing decision. Treat as metadata that may evolve.
is_ambiguous
Section titled “is_ambiguous”Meaning: Indicates that the output should be treated carefully or routed to review.
domain_is_ambiguous
Section titled “domain_is_ambiguous”Meaning: Indicates ambiguity about whether the input fits the supported domain.
How to Interpret AvelinLabs Outputs
Section titled “How to Interpret AvelinLabs Outputs”- Scores are decision-support signals, not absolute truth.
- Confidence indicates how reliable or complete the available evidence appears to be for the requested task.
- Occupation matches are structured suggestions grounded in occupation intelligence.
- Skill signals may come from explicit text or inferred context, depending on endpoint behavior and available input.
- Recommendations should be reviewed in the context of the user’s workflow, risk tolerance, and automation policy.
- Ambiguous, weak-signal, or low-confidence outputs should generally be reviewed before being used for automation.
- Weak, vague, repeated-keyword, or non-occupational inputs may still receive a best-effort match, but public confidence is intentionally damped when occupational evidence is limited.
Response Stability During Beta
Section titled “Response Stability During Beta”AvelinLabs is currently in beta / early access.
Core public response concepts are intended to remain stable: job inputs, occupation outputs, ranked matches, confidence, uncertainty, skill evidence, explanations, and market context.
During beta:
- additive fields may be introduced
- optional fields may be absent for some requests
- clients should ignore unknown fields
- clients should not depend on debug-only fields
- examples are illustrative and may evolve with the beta