An interoperability requirement is useful only when it identifies the exchange the organisation needs. LTI procurement illustrates why a protocol name, a service and a conformance certificate answer different questions.
Evidence CDecision horizon NowUpdated 09 Oct 2026Proof patterns 1
Ask for evidence of the workflow you intend to buy.
LT Horizon generated editorial illustration · not evidenceImage provenanceLT Horizon owner-supplied editorial assetView diagram at full size
Read diagram text
Keep roadmap plans separate from tenant evidence. Roadmap: Record the planned feature and its stated availability. Preview: Check configuration and behaviour in your tenant. Dependencies: Identify access, data and implementation requirements. Decision: Plan adoption only around behaviour you have verified.
Start with the exchange being purchased
Learning Tools Interoperability provides a standard way for a learning platform to connect with an external tool. LTI 1.3 supplies a core launch and security model; LTI Advantage adds services for particular exchanges.
The cited 1EdTech guidance distinguishes Deep Linking, Names and Role Provisioning, and Assignment and Grade Services. Their presence matters according to the workflow: placing an external activity, exchanging permitted participant context and returning outcomes are not the same requirement.
What certification establishes
1EdTech tests LTI Core and applicable Advantage services separately. Its procurement guidance consequently calls for the precise supported version, the services required and current certification evidence, including a conformance registration number.
Certification supports a claim about the standard components that were tested. It does not certify an organisation's entire access, support or reporting process. A technically conformant product can still require platform-specific registration, scopes and privacy configuration, as the cited Canvas example illustrates.
Why an operating integration has a wider boundary
An external-tool journey also depends on which users are permitted to launch it, what data is shared and what happens when the tool is unavailable. Some lifecycle or data requirements may sit outside LTI and need separate integrations or operational handling.
This is the distinction behind the procurement recommendation below. Buying a standards capability can reduce bespoke work, but the specification still needs to describe the actual exchange and the responsibilities that surround it. A generic standards logo cannot supply that explanation.
How to read this briefCheck the sources to see what is documented. Our recommendation explains what that means for your decision. Proof patterns add specific design or implementation examples and explain their limits.
LT Horizon DECISION BRIEF
Answer
Ask for the exact LTI version, services and current certification the vendor supports. Test your intended workflow and confirm any configuration or custom work it needs.
Who should care
Learning technology buyers, enterprise architects, procurement teams, security teams and implementation partners.
Recommended action
ACT — replace generic 'supports standards' procurement questions with evidence-based workflow and conformance requirements.
LT Horizon interpretation · Evidence confidence C
What changed
No new event is asserted. This brief converts an interoperability standard into concrete procurement evidence requirements.
Why it matters
Generic standards claims can hide meaningful differences in supported versions, services, security configuration and implementation effort.
Use cases & proof
Where this holds up in practice
These examples show how a specific claim is supported by documentation or an implementation. Read their limits before applying them to your own environment.
Proof pattern · Evidence C
LTI 1.3 conformance narrows integration risk but does not remove deployment design
Scenario
An organisation evaluates or procures an external learning tool that claims LTI 1.3 or LTI Advantage support and needs to determine whether the target workflow will actually operate securely in its learning environment.
Architecture pattern
Learning platform ↔ OIDC/JWT trust and keys ↔ LTI tool launch; optional Deep Linking, Names and Role Provisioning and Assignment and Grade services sit on top, while platform-specific registration, scopes, privacy and operational support remain part of the deployment.
Observed / documented outcome
1EdTech defines LTI 1.3 Core and the LTI Advantage services separately, provides conformance testing for the applicable components and publishes procurement language asking buyers to verify exact versions, services and current certification. Canvas implementation documentation shows that a real LTI 1.3 deployment still requires client and deployment registration, OIDC and key configuration, scopes, placements and privacy choices.
What this proves
A standards claim should be decomposed into exact version, services, certification state and target workflow. Certification meaningfully reduces protocol-conformance uncertainty, but a buyer still needs to validate deployment configuration, permissions, privacy, failure handling and any responsibilities outside the standard.
What it does not prove
It does not prove that every certified pair will require zero vendor-specific configuration, that all LTI 1.3 products support all LTI Advantage services, that certification covers availability or support quality, or that LTI replaces provisioning, reporting, data-governance or API requirements outside the selected services.
Apply with these constraints
Specify the target launch and data workflows, required Advantage services, current certification, identity and privacy requirements, keys and rotation, service scopes, roles, disabled-user behaviour, error handling, support ownership, version lifecycle and any non-LTI interfaces before contract signature or production rollout.
Last checked 18 Sept 2026 · Reviewed before publication.
Implementation implications
Prerequisites
Define the target integration workflows, required data exchange, identity model, required LTI services, expected scale, support model and fallback behaviour before issuing requirements.
Architecture implications
Procurement requirements should reference specific workflows and standards capabilities rather than generic integration labels, allowing architecture decisions to be tested before contract signature.
Risks
Buying based on logos or protocol names, discovering missing services late, dependence on proprietary extensions, weak security ownership and unexpected implementation cost.
Testing implications
Require a representative integration proof using production-like identity and permissions, validate required services, inspect security configuration and document any vendor-specific extensions or manual steps.
Source register
What the evidence establishes
When does LTI 1.3 matter in an enterprise learning stack? — 1EdTech evidence
Public summary awaiting review. See the original source.
Publication review is recorded in the evidence and correction history. Images illustrate the article; they are not evidence.
History and corrections
Article body revision 1 · added 09 Oct 2026. Explanatory text added to the published evidence snapshot; evidence confidence, availability and source verification dates are unchanged.
Published revisions are retained. Update dates change only after a change to the content or evidence.
Correction: Evidence grade corrected from B to C. The cited documentation or standard supports the guidance; independent implementation proof has not been reviewed. Wording reviewed for clarity; source verification dates are unchanged. · 30 Sept 2026
Keep a clearer view of learning technology.
Get occasional email updates when LT Horizon publishes new Intelligence and Horizon articles. Free to read, with no account required.
Our practical newsletter format brings one question, one idea and one exercise, alongside selected source-linked articles. Editions follow useful reviewed evidence.
