Bridging Competency Definitions and Evidence: Introducing the Rubric Assertion Profile (RAP)

The Problem I'm Trying to Solve​

• xAPI profiles for a domain don't exist yet or are incomplete
• Evidence spans multiple learning experiences (different registrations)
• We need granular progress indicators, not just binary "achieved/not achieved"
• We want to prototype competency assertion quickly without waiting for formal profile development

The Proposed Solution: Rubric Assertion Profile (RAP)​

What's in a RAP?​

1. References to SCD rubric components by URI— Specifically:
   • scd:CompetencyDefinition instances (the competency being assessed)
   • scd:RubricCriterion instances (the evaluative dimensions—e.g., "Safe Handling Procedure")
   • scd:RubricCriterionLevel instances (the proficiency thresholds—e.g., "Proficient" with score 3)
     
     These reference the same globally unique URIs/IRIs that the SCD standard requires, ensuring RAP consumes the standard's own identifiers rather than inventing a parallel addressing scheme.
2. Assertion rules— Logic for evaluating xAPI evidence:
   • Statement templates and patterns (can reference existing xAPI profiles)
   • Thresholds (e.g., "completed 5 of 7 activities")
   • Sequences (e.g., "must complete A before attempting B")
   • Multi-registration handling (evidence across multiple courses/experiences)
   • Confidence calculation methods (how scores, completion counts, and qualitative evidence combine into a confidence value)
3. References to xAPI profiles — When formal profiles exist, RAP leverages their statement templates and patterns. When they don't, RAP can bootstrap patterns from actual LRS data, with a pathway to contribute those patterns back to formal profile development.
   
   
4. References to LMT metadata (optional) — When operating within a TLA ecosystem, RAP can reference IEEE 2881-2025 metadata in the Experience Index (XI) to discover which CompetencyDefinitions are relevant for a given learning activity, rather than duplicating that activity-to-competency mapping internally.

How It Works in Practice​

1. Start with an SCD that includes a rubric (CompetencyFramework → CompetencyDefinition → RubricCriterion → RubricCriterionLevel)
2. Check if relevant xAPI profiles exist:
   • If YES: Link to existing statement templates and patterns
   • If NO: Use TLA Toolbox to query/mock an LRS, analyze statements, and infer patterns
3. Use the statement crafter to inject sample statements and test assertion logic
4. Build assertion rules in the RAP editor, binding each rule to specific scd:RubricCriterion and scd:RubricCriterionLevel URIs
5. Export as a portable JSON-LD file
6. Use Audit/Suggest feature to propose additions to existing xAPI profiles or new profile creation

1. Learning activities emit xAPI statements to an LRS
2. Assertion engine loads relevant RAP(s)
3. Engine evaluates evidence against RAP rules
4. Emits "progressed" xAPI statements when partial thresholds are met (event-driven, reduces polling load). These statements reference the scd:RubricCriterionLevel URI to indicate which level was reached, using verbs from the ADL vocabulary (e.g., progressed) or a RAP-defined extension vocabulary.
5. Emits final "achieved"/"mastered" statement when all rubric criteria are satisfied at or above the mastery threshold defined by the CompetencyDefinition's competencyLevel property
6. All assertions link back to the evidence trail via xAPI statement references

How This Fits With Existing Specs​

The Four Concerns​

Diagrams​

1. Conceptual relationships between SCD, RAP, LMT, and xAPI profiles
2. RAP development workflow (with both "use existing profile" and "bootstrap from data" paths)
3. Runtime competency assertion process
4. Complete data flow and file relationships

​

​

1. Get feedback — Does this approach make sense? Are there obvious problems I'm missing?
2. Learn from the community — Am I reinventing something that already exists? Are there existing specs or approaches that already solve this problem? (I've looked at CASS's assertion processing and IEEE LOM Classification, but I may be missing something.)
3. Invite collaboration — If this resonates with others facing similar challenges, I'd love to work together on refining the model
4. Contribute back — The goal is to create something that can inform future standards work, not to create a proprietary silo

• Should RAP be proposed as an extension to the IEEE SCD spec, or remain a separate but linked specification? (The SCD standard's own extensibility mechanism via Application Profile Schemas could potentially accommodate RAP-style rules, but assertion logic may be too far outside SCD's scope.)
• How should we handle versioning when SCDs, LMT metadata, and xAPI profiles all evolve independently?
• What's the right level of expressiveness for assertion rules? (Too simple = not useful; too complex = nobody uses it)
• How do we balance the need for quick prototyping with the rigor needed for formal standards?
• Should RAP define its own vocabulary for progress/assertion verbs, or strictly reuse existing ADL and cmi5 verbs?
• Are there existing competency assertion engines beyond CASS that already define assertion rules declaratively?

IEEE Standards​

• IEEE 1484.12.1-2020: Learning Object Metadata
• IEEE 1484.20.1-2007: RDCEO (Inactive)
• IEEE 1484.20.3-2022: Shareable Competency Definitions

W3C / Schema.org​

• Schema.org AlignmentObject: https://schema.org/AlignmentObject
• LRMI: Learning Resource Metadata Initiative

CASS​

• CASS Docs: https://docs.cassproject.org
• CASS Schema: http://schema.cassproject.org

The Three Standards​

1. IEEE 1484.12.1 LOM Category 9: Classification​

<classification>
  <purpose>competency</purpose>
  <taxonpath>
    <source>IEEE 1484.20.3</source>
    <taxon>
      <id>comp-uri</id>
      <entry>Competency Name</entry>
    </taxon>
  </taxonpath>
</classification>

2. Schema.org AlignmentObject​

{  "@type": "CreativeWork", 
    "url": "activity-url", 
     "educationalAlignment": {   
          "@type": "AlignmentObject",   
          "alignmentType": "teaches",   
           "targetUrl": "comp-uri" 
        }
}

3. CASS Assertion Processing​

1. xAPI statement arrives
2. Look up alignment (from LOM or AlignmentObject)
3. Extract competency URI
4. Create assertion

{ 
  "@type": "Assertion", 
  "subject": "person-pk", 
  "competency": "comp-uri", 
  "confidence": 0.85
}

Quick Comparison Table​

Complete Workflow: All Three Working Together​

• Author creates SCORM course
• Embeds LOM metadata with Classification category
• Specifies which competencies the course teaches
• Result: Learning object has metadata

• LMS imports SCORM package
• Reads LOM Classification
• Creates/publishes alignment in CASS
• Maps activity URL to competency URI
• Result: Alignment registered

• Learner completes course
• LMS emits xAPI statement with result/score
• Statement stored in LRS
• Result: Evidence recorded

• CASS xAPI Adapter sees statement
• Looks up alignment to find competency
• Extracts confidence from score
• Creates assertion
• Result: Competency asserted

• System asks: "Does person have competency X?"
• CASS retrieves assertion
• Applies roll-up rules if needed
• Returns: TRUE/FALSE with confidence
• Result: Competency verified

Where RAP (Reusable Assertion Profile) Fits In​

• IEEE LOM tells WHAT competencies
• Schema.org tells WHERE alignments are
• CASS processes assertions
• BUT: No standard for WHEN/HOW to create assertions
• No configuration format for assertion rules
• No way to define confidence calculation

• Defines WHEN to create assertions (triggers)
• Defines HOW to calculate confidence
• Defines WHERE to get competency URI
• Declarative (no coding required)
• Works WITH all three standards