General lesson: move evidence, not confidence
Learning platforms often describe portability as data export: send a course identifier, completion state, score, and timestamp to the next LMS or learner record store. That is enough to reproduce a dashboard row. It is not enough for a receiving organization to understand what the learner actually demonstrated, whether the result matches its own competency model, or whether the evidence is still valid for a consequential decision.
The sharper lens is evidence portability. The useful unit is not a confidence-bearing label such as completed, passed, or 82 percent. It is a bounded claim connected to a competency definition, an attempt, an assessment policy, supporting evidence, an authorized issuer, and a validity window. The receiving system imports the claim and its provenance, then makes its own explicit decision rather than inheriting the source system's confidence by default.
Define a competency-evidence package
A portable package can use {package_version, subject_id, activity_id, competency_ref, attempt_id, evidence_manifest, assessment_policy, result, issuer, issued_at, validity, corrections}. competency_ref needs a stable identifier and definition version, not only a local label. The evidence manifest points to artifacts, observed decisions, simulations, assessments, or signed event digests without forcing every private artifact into the receiving platform. The assessment policy identifies the rubric, threshold, evaluator type, and conditions under which the result was produced.
The operating invariant is that a result cannot travel farther than its evidence and policy can explain. A receiving system may map the claim to a local competency, but it should preserve the original identity, issuer, and assessment version. Translation creates a new decision record; it must not rewrite the source package. That separation makes corrections, audits, expiry, and disputed mappings possible without pretending the two systems share identical semantics.
Project example: keep rich runtime evidence behind the standard adapter
Kaptia / IA Learning provides public portfolio context around immersive authoring, learner analytics, runtime workflows, and LMS interoperability. The E-Learning portfolio area connects standards mapping, adaptive delivery, and analytics-friendly outputs. Public project context: portfolio projects. These are architecture references, not a claim that a cross-provider credential exchange is deployed or externally validated.
Consider an immersive safety exercise where a learner chooses a response, revises it after feedback, and succeeds in a changed scenario. A conventional export may report completion and a final score. A portable evidence package can instead reference the competency version, scenario constraints, decision trace, rubric, evaluator, retry policy, and evidence digest. The receiving LMS does not need every scene event, but it receives enough provenance to decide whether the result satisfies its own requirement or needs another assessment.
Implementation pattern: issue, validate, map, and reconcile
Issue the package only after internal learner state has reached a defined assessment boundary. Resolve stable subject and competency identities, freeze the relevant evidence manifest, identify the policy version, and sign or otherwise protect the package against undetected mutation. On receipt, validate schema, issuer authority, integrity, revocation or correction status, and validity before attempting semantic mapping. Keep transport success separate from acceptance of the claim.
Use receiver states such as received -> integrity_verified -> mapped -> accepted, with branches to unknown_issuer, competency_mismatch, expired, needs_evidence, superseded, and rejected. Record the mapping policy and reason with the local decision. When a source corrects or revokes a claim, reconcile affected local decisions through a new event; do not delete the old package and silently recalculate the learner's history.
Measure semantic acceptance, not export volume
Export count and API success rate show that records moved, not that meaning survived. Track integrity-validation failures, unknown competency versions, automatic mapping rate, manual-review rate, acceptance by issuer and competency, evidence retrieval failures, expired-claim usage, correction propagation latency, and decisions reversed after a mapping or policy change. Separate technical rejection from semantic rejection so transport reliability does not hide model disagreement.
Sample accepted claims and ask whether a reviewer can answer five questions: what capability was claimed, which evidence supports it, which policy converted evidence into a result, who was authorized to issue it, and why the receiving system accepted the mapping. If those answers require opening the source product or trusting a free-text note, the exchange moved a status but did not deliver portable evidence.
Failure modes, privacy limits, and trade-offs
The most common failure is semantic flattening: two competencies share a similar label, so an integration treats them as equivalent despite different scope, difficulty, evidence, or recency requirements. Other risks include replaying a superseded claim, accepting a package from an unauthorized issuer, exposing learner artifacts beyond their consent, treating self-reported evidence as observed performance, and recalculating old results under a new rubric without preserving the original policy.
Evidence portability adds identity governance, schema evolution, signature or integrity management, mapping review, retention, and learner-rights work. Not every low-stakes activity needs a full portable dossier; a simple completion signal can be proportionate for optional orientation content. The stronger contract is justified when progress affects certification, role readiness, access, compliance, personalization, or credit transfer. Minimize the exported evidence, use revocable references where appropriate, and avoid turning portability into permanent surveillance of learner behavior.
Run a five-package portability diagnostic
Apply this tomorrow to one learning integration. Test five synthetic packages: a valid claim with an unknown competency version, a familiar competency issued under a weaker rubric, an evidence link that has expired, a corrected result arriving after the original was accepted, and a high score whose source artifact contains unnecessary personal information. Inspect the receiving decision, not only the API response, and verify that each package reaches a reasoned state without overwriting its source history.
The workflow passes only if integrity and issuer authority are checked before mapping, semantic mismatches become visible review work, private evidence stays bounded, corrections propagate without erasing prior decisions, and operators can explain every acceptance from the stored receipt. If a receiving team cannot distinguish a transported completion flag from a verified competency claim, the integration provides record mobility but not trustworthy learner progress portability.