Skip to content
AvelinLabs

Decision-Layer Architecture

Avelin is built around a workforce decision architecture with explicit boundaries:

  • shared workforce evidence and references,
  • tenant-scoped Customer Grounding,
  • decision interpretation,
  • stable delivery channels.

The same decision semantics are preserved across REST and MCP so behavior does not depend on transport.

Why this matters

Section titled “Why this matters”

Each signal family serves a different purpose. An occupational reference is not the same as a market signal; customer policy is not the same as shared evidence. Separating these roles improves explainability.

Architecture flow

Section titled “Architecture flow”
Shared workforce sources       Account-scoped customer sources
  +-- O*NET 30.3                 +-- Approved customer evidence
  +-- Market signals              +-- Grounding artifacts
  +-- Request context             +-- Frameworks, policies, rubrics
            |                                |
            +---------------+----------------+
                            |
                            v
                     Evidence Layer
                            |
                            v
                   Workforce Decision Layer
        +-------------------+-------------------+
        | confidence        | uncertainty       |
        | review guidance   | provenance        |
        +-------------------+-------------------+
                            |
                            v
                  REST API / MCP integration
                            |
                    Applications / AI agents

Source and grounding boundaries

Section titled “Source and grounding boundaries”

Shared sources and tenant sources remain distinct by design. This keeps customer policies from silently overriding shared evidence and shared references from being incorrectly treated as organization-specific.

Customer Grounding expands role context and policy relevance without changing the meaning of all shared evidence.

Decision layer responsibilities

Section titled “Decision layer responsibilities”

The Decision Layer determines whether a result is:

  • directly supportable,
  • weak and uncertain,
  • or likely requiring review.

It returns structured signals that downstream systems can integrate into governed policies.

Delivery channels

Section titled “Delivery channels”

REST is the stable integration contract for Runtime and platform routes. MCP remains a customer-operated adapter model over the authenticated Runtime API.

Neither channel defines the decision semantics.

Section titled “Architecture links”

Current scope

Section titled “Current scope”
  • Job analysis and classification,
  • occupation detail,
  • labor-market APIs,
  • Customer Grounding,
  • decision-support output structure.

The platform is bounded by documented current capabilities and review requirements.