← Back to Liora
AgentLiora

Skill · Version 1.0.0

Connect your learning tools

Connects learning platforms, assessment tools and learner lists using shared standards, so data can move between them consistently.

learning-interoperability

See how it helps

When is it useful?

Use this skill when a learning platform needs to connect to external learning tools, question banks or roster systems. It checks the exact supported versions of LTI, QTI or OneRoster before promising compatibility.

What does it help you do?

  • Maps users, courses, enrolments and grades between systems without confusing identities or organizations.
  • Checks secure tool launches and imports assessment content with explicit feedback for unsupported question types.
  • Plans roster and grade synchronization so interrupted imports, delayed events and duplicates do not overwrite valid learning records.

Try asking this

Assess whether our LMS can launch an external learning tool and receive grades through LTI. List the supported versions, required permissions and tests for duplicate grade updates.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Learning interoperability

When to use

When an LMS exchanges launches, assessment content, grades or rosters with another product. Identify the exact standard and vendor implementation before designing the integration; supporting one LTI service does not imply support for QTI or roster synchronization.

Workflow

  1. Inspect both installed products, versions, plugins, configuration and available API metadata. Build a compatibility table listing the exact LTI, QTI or OneRoster version/profile, optional services, transport, authentication, requested scopes and implemented subsets on each side. Resolve gaps using the relevant 1EdTech specification and vendor documentation for those releases; do not infer compatibility from a product logo.
  2. Define stable, tenant-scoped mappings for users, organizations, courses/classes, enrolments, activities and grade items. Record the source of truth for each field. A remote user ID or email is not permission to link to a local account or another organization's learner; require the established account-linking and course-authorization flow.
  3. For an LTI integration, verify the chosen version's registration and launch contract. Where the profile uses OIDC and JWTs, validate issuer, audience/client, deployment, signature against trusted keys, expiry, nonce and state, and bind the launch context to the intended organization and course. Keep role claims scoped to that launch context. Use only approved endpoints and granted service scopes; check grade-service and roster-service capabilities independently of basic launch success.
  4. For QTI import/export, inspect supported item types, response processing, scoring, metadata, media and accessibility support at the exact version. Validate packages before import, restrict archive paths and external resource fetching, and preserve original item identifiers/version mappings. Return explicit unsupported-item diagnostics rather than dropping questions or changing their scoring silently. Compare a round trip against representative source items, including accommodations and partial credit when applicable.
  5. For roster exchange, establish the supported OneRoster version and CSV or REST profile, stable source identifiers, pagination, term boundaries and delta/deletion semantics. Decide whether an absent record means unchanged, inactive or removed; do not treat an incomplete page or failed export as a full roster replacement. Apply enrolment changes through the LMS's access policy without erasing attempts or certificates.
  6. Make grade and roster writes idempotent and reconcile against authoritative records. Handle duplicates, revoked access, rate limits and delayed results. After a timeout with an unknown write outcome, inspect the remote state using the operation's stable identity before retrying. Keep a bounded recovery queue with visible failures instead of repeatedly applying uncertain updates.

Evidence and verification

Deliver the compatibility table, permission/scopes map, field ownership map and a minimal integration proof against the specified versions. Test a valid launch plus wrong issuer/deployment and replay rejection; unsupported QTI content; a paginated roster interrupted midway; duplicate grade delivery; and a learner whose enrolment was revoked before a delayed event arrived.

Separate schema validation, a passing vendor sandbox test, production verification and formal certification. A successful sample launch or import is not evidence of complete standards conformance. Claim certification only when a verifiable certification record covers the exact product, version and profile.

Boundaries

  • Do not request broad roster or grade-write scopes just because an integration key allows them.
  • Do not change production registrations, enrolments or grades without authorization for that operation. Local implementation and test fixtures do not imply permission to enroll real learners.
  • Do not assume LTI, QTI, OneRoster, SCORM and xAPI are interchangeable. Use the actual requested contract and state unsupported requirements clearly.

Primary reference

Select and verify the exact versioned specification from the standards index:

Included files 1

  • SKILL.md