Key Dimensions and Scopes of Technology Services

Technology services in the learning systems sector occupy a complex delivery landscape defined by overlapping standards, vendor categories, institutional requirements, and regulatory obligations. The scope of any engagement — whether a platform license, implementation contract, integration service, or managed learning operation — is determined by technical specifications, institutional context, and applicable compliance frameworks. Misaligned scope assumptions are among the most common causes of failed procurement and deployment outcomes in enterprise learning technology.

• Dimensions that vary by context
• Service delivery boundaries
• How scope is determined
• Common scope disputes
• Scope of coverage
• What is included
• What falls outside the scope
• Geographic and jurisdictional dimensions

Dimensions that vary by context

Learning technology services do not carry a fixed definition across all deployment contexts. The same platform — a learning management system, for example — can represent infrastructure, a managed service, or a SaaS subscription depending on the contracting model, the institution's internal capacity, and the service level agreement in place. Four primary dimensions shift based on context:

Institutional type. A corporate training environment, a higher education institution, and a K–12 district each impose distinct service requirements. Learning technology for corporate training is governed primarily by internal HR policy and industry regulation (e.g., OSHA 29 CFR Part 1910 for safety training records). Learning technology for higher education falls under the Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g, which restricts data handling and third-party disclosures. Learning technology for K–12 adds the Children's Online Privacy Protection Act (COPPA), enforced by the Federal Trade Commission, and the Children's Internet Protection Act (CIPA).

Deployment model. Cloud-based versus self-hosted LMS architectures define who bears responsibility for uptime, patching, backups, and data residency. In a cloud model, the vendor retains operational responsibility for infrastructure; in a self-hosted model, the institution absorbs those obligations. This single variable shifts the scope of the technology service contract substantially.

Content standards in use. Platforms that must support SCORM 1.2, SCORM 2004, xAPI, or AICC operate under protocol-specific interoperability constraints. SCORM, xAPI, and AICC standards carry different data payload capacities, affecting what learner activity data a service can capture and report.

User population scale. A platform serving 500 internal employees carries different infrastructure, support, and licensing obligations than one supporting 50,000 learners across an extended enterprise learning system. Concurrent user thresholds, API rate limits, and storage allocations are scope variables that scale nonlinearly.

Service delivery boundaries

Technology service delivery boundaries define what a provider is contractually and technically responsible for, and where that responsibility ends. In learning systems contexts, four boundary types are operationally significant:

System boundaries separate the core platform from adjacent integrations. LMS integration with enterprise systems — including HRIS, ERP, CRM, and identity providers — typically falls outside the core platform service unless explicitly contracted. A vendor providing a hosted LMS does not automatically assume responsibility for data synchronization with Workday or SAP.

Data boundaries define which data sets the service processes, stores, and governs. Learning analytics and reporting services may access only completion and score data, stopping short of behavioral analytics from video learning technology or engagement signals from gamification in learning technology unless those modules are within scope.

Support boundaries specify response time tiers, escalation paths, and what categories of issues trigger support versus professional services billing. A standard SaaS support agreement covers platform defects but not configuration errors introduced by the customer's administrators.

Security boundaries define the provider's obligations under shared-responsibility models. Under frameworks such as NIST SP 800-53 (Rev. 5), security controls are partitioned between the cloud service provider and the consuming organization. Learning technology security and compliance obligations — encryption at rest, audit logging, penetration testing schedules — must be explicitly allocated in service agreements.

How scope is determined

Scope determination in learning technology services follows a structured sequence of inputs. The process is neither linear nor purely technical; it involves procurement standards, legal review, and functional requirements elicitation.

Scope determination sequence:

1. Needs analysis — Identify learner population size, geographic distribution, content types (video, simulation, ILT, mobile), and mandatory compliance requirements.
2. Standards mapping — Determine which content and interoperability standards apply. SCORM 1.2 remains the most widely deployed standard as of the ADL Initiative's published compatibility guidance, though xAPI adoption has grown in enterprises requiring granular activity tracking.
3. Regulatory inventory — Catalog applicable federal and state regulations governing data privacy, accessibility, and records retention. Section 508 of the Rehabilitation Act (29 U.S.C. § 794d) requires that electronic and information technology procured by federal agencies meet accessibility standards — a requirement that flows through to vendor contracts.
4. Integration mapping — Document all upstream and downstream systems the LMS must communicate with, including SSO and authentication for LMS providers, content repositories, and skills and competency management systems.
5. Delivery model selection — Choose between cloud-hosted, self-hosted, or hybrid configurations based on data residency, IT capacity, and cost structure.
6. Contract scope drafting — Translate functional and regulatory requirements into service-level definitions, including uptime guarantees, support tiers, data ownership clauses, and exit provisions.
7. Vendor capability verification — Validate that the vendor's published capabilities — including LMS pricing and licensing models — align with contracted scope before execution.

LMS selection criteria published by procurement specialists and professional associations such as the Association for Talent Development (ATD) provide structured frameworks for completing steps 1 through 4.

Common scope disputes

Scope disputes in learning technology services cluster around predictable fault lines. Understanding these disputes protects institutional interests during contract negotiation and renewal.

Integration ownership. The most common dispute involves who owns the integration layer between the LMS and third-party systems. Vendors typically provide documented APIs; building and maintaining the connector is often treated as out-of-scope unless a managed integration service is explicitly contracted.

Content migration. Learning technology migration costs are routinely underestimated. Vendors rarely include historical content conversion — particularly from legacy AICC packages to modern xAPI — in base contracts. Migration of 1,000 legacy SCORM modules can involve 400 to 800 hours of conversion effort depending on interactivity complexity.

Customization versus configuration. Vendors draw a hard line between configuration (adjusting available settings within the platform) and customization (code-level modification). Customizations typically void standard support coverage and require separate professional services engagement.

Accessibility remediation. When audits reveal learning technology accessibility standards failures under WCAG 2.1 AA criteria, disputes arise over whether remediation is a platform defect (vendor responsibility) or a content production failure (customer responsibility).

Analytics scope. Clients frequently assume that enterprise learning analytics and reporting capabilities are bundled in base licenses. Many vendors tier advanced analytics, predictive reporting, and dashboard customization into premium SKUs.

Scope of coverage

The following reference table maps service categories in the learning technology sector against their typical scope boundaries, delivery models, and governing standards.

What is included

Standard scope in a managed learning technology service engagement typically encompasses the following elements, subject to contractual confirmation:

• Platform licensing — access rights for a defined user count or concurrent session volume
• Infrastructure operation — server provisioning, scaling, patching, and uptime management (cloud-hosted only)
• Core feature set — course catalog management, enrollment workflows, assessment delivery, and completion tracking
• Standard reporting — pre-built report templates covering completion rates, assessment scores, and enrollment counts
• Tier-1 support — help desk response for platform-level issues within contracted SLA windows
• Security baseline — encryption in transit (TLS 1.2 minimum per NIST guidelines), access control, and audit logging
• Standard integrations — published API access for identity management and SCORM/xAPI content delivery
• Content management for learning — storage and version control for uploaded learning objects within licensed storage quotas
• Taxonomy and metadata in learning systems — metadata fields and tagging frameworks native to the platform

Microlearning platforms, simulation-based learning tools, and mobile learning technology modules may be included or excluded depending on platform tier and licensing structure — a distinction that must be confirmed before deployment planning begins.

What falls outside the scope

The following elements are consistently outside standard technology service scope unless explicitly contracted as additions:

• Custom content production — eLearning authoring tools and content development labor are separate from platform services; vendors do not produce client-specific courseware under platform licenses
• Instructional design services — curriculum architecture, learning objective mapping, and pedagogical framework selection are professional services, not platform features
• Third-party content libraries — off-the-shelf course catalogs from providers such as LinkedIn Learning or Coursera require separate licensing agreements
• Advanced analytics and learning experience platforms — behavioral analytics, recommendation engines, and learner journey orchestration fall outside core LMS scope in the majority of vendor architectures
• Regulatory compliance filing — a compliance training technology platform tracks completion; it does not submit records to OSHA, FINRA, or state licensing boards on the client's behalf
• LMS administration and governance — platform administration (user provisioning, role management, course building) is the client's operational responsibility unless a managed services contract is in place
• Hardware and end-user devices — client endpoints, network infrastructure, and bandwidth provisioning are outside vendor scope
• Learning technology migration from legacy systems — data export, content conversion, and historical record migration are professional services, not standard onboarding

A common misconception is that onboarding technology solutions are inherently part of an LMS deployment. Onboarding workflows — including preboarding communication, document collection, and role-specific orientation paths — require either a dedicated HR technology integration or explicit configuration work that falls under professional services billing.

Geographic and jurisdictional dimensions

Learning technology services operating across US state lines encounter jurisdictional variation that affects data handling, accessibility requirements, and procurement rules.

Federal baseline. FERPA, COPPA, Section 508, and the Americans with Disabilities Act (ADA, 42 U.S.C. § 12101) establish federal floors that apply nationally. The learning technology accessibility standards framework under Section 508 applies directly to federal agency procurement and flows through to contractors via the Federal Acquisition Regulation (FAR) 39.2.

State-level variation. California's Consumer Privacy Act (CCPA), as amended by the CPRA, imposes data subject rights obligations — including deletion and portability — that exceed federal FERPA requirements. Illinois' Biometric Information Privacy Act (BIPA) affects platforms that use facial recognition for proctoring or identity verification. At least 5 states had enacted comprehensive consumer privacy laws as of the National Conference of State Legislatures' 2023 tracking report, each with distinct applicability thresholds and enforcement mechanisms.

International scope triggers. US-headquartered organizations deploying extended enterprise learning systems to learners in the European Union trigger GDPR obligations under Regulation (EU) 2016/679, including data processing agreements (DPAs) with platform vendors. Cross-border data transfer mechanisms — Standard Contractual Clauses or adequacy decisions — become contractual scope requirements rather than optional additions.

Procurement jurisdiction. State and municipal government agencies are subject to state procurement codes that prescribe competitive bidding thresholds, contract term limits, and approved vendor list requirements. Technology service contracts for public K–12 districts and state universities must comply with these rules, affecting contract structure and permissible scope modifications mid-term.

The intersection of these jurisdictional layers makes geographic scope a non-trivial variable. A platform service that is compliant in a pure federal context may require contractual amendment to operate in California, Illinois, or within the EU — dimensions that the learning systems authority index catalogs across the full range of platform and service categories covered in this reference network.