| Component | What it provides |
|---|---|
| Timeback APIs | 1EdTech standards for rosters, content, events, and more |
| Desktop App | Student launcher with waste detection and time-on-task |
| Dashboards | Progress for students; analytics for developers |
| Closed loop | External tests connect in-app activity to real outcomes |
### Layer 1: Standards backbone
The foundation is a set of **APIs based on 1EdTech data models** that implement industry-standard data models. Schools already speak these standards for rostering, assessments, and analytics. Interoperability still requires supported operations, identity mapping, authorization, and app-specific integration.
This layer handles the data you would otherwise need to define and store yourself: students, classes, enrollments, courses, content, results, and learning events.
### Layer 2: Learning system
The middle layer provides **mastery tracking and the closed-loop feedback system**. It takes raw events from apps and turns them into progress signals that are comparable, analyzable, and tied to outcomes.
As a student engages with an activity, the learning system tracks time spent continuously via periodic heartbeats. When the student completes the activity, the system records the result, updates mastery state, and feeds signals into the analytics pipeline. The SDK supports [two activity models](/beta/about-timeback/concepts/activity-models): single-session activities where the client reports everything, and stateful activities where the client tracks time per session while the server records completion. Apps provide XP based on their own reward logic, and the platform aggregates it across the ecosystem. When standardized test results arrive, the system correlates them with in-app behavior to identify what worked and what needs adjustment.
### Layer 3: Student experience
The top layer is where students and educators interact with the platform. This includes **learning apps** (both first-party and third-party), **dashboards** for progress visibility, and the **Timeback Desktop App** for monitoring and launching content.
Developers build at this layer. Your app must still configure identity, validate outcomes, handle failures, and render its learning experience.
## The Timeback stack
Here is what developers actually interact with when building on the platform:
| Component | What it does |
| ------------------------ | --------------------------------------------------------------------------------------- |
| **Timeback APIs** | Endpoints based on 1EdTech models for rosters, launch, content, events, and credentials |
| **Timeback Desktop App** | Student-facing launcher that collects engagement signals (waste, time-on-task) |
| **Student Dashboards** | Progress visibility including XP, mastery state, and time-back tracking |
| **Developer Dashboards** | Analytics and outcome correlation for monitoring app performance |
### Timeback APIs
Rather than inventing proprietary interfaces, the platform implements industry specs directly. For developers, this means:
* **Shared models.** Standard concepts reduce translation work; extensions and service-specific behavior still need explicit mapping.
* **Integration requirements.** Confirm the exact standards, versions, and compliance evidence required by each school.
* **Reusable services.** Use the supported APIs for rostering, events, and analytics while handling your integration's identity and failure modes.
### 1EdTech standards
Timeback services use 1EdTech data models and service-specific extensions. Consult each API's current paths, schemas, and authorization requirements; the existence of an implementation is not a certification claim or a guarantee that every operation in the standard is supported.
| Standard | Role in Timeback | Integration responsibility |
| ----------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| OneRoster | Users, courses, classes, enrollments, results | Map identities and use supported operations/scopes |
| LTI | Learning-tool launch contracts where configured | Implement the relevant launch flow; SDK OIDC SSO is a separate contract |
| QTI | Assessment content and response-processing interfaces | Render supported interactions and handle processing results |
| Caliper | Learning event vocabulary and payloads | Select the correct receiver/profile, send accurate metrics, and verify downstream processing |
| CASE | Competency frameworks and standards associations | Supply and maintain the content mappings your app needs |
| CLR | Learner credential records | Supply a valid credential body; raw credential storage does not itself sign or verify it |
| Open Badges | Achievement credentials | Use the service's issuance and verification contracts; do not infer revocation or external verification from storage |
A shared data model helps interoperability. It does not automatically make two apps' identifiers, progress scales, or mastery policies interchangeable. See [API reference](/beta/api-reference/overview) and [SDK identity](/beta/build-on-timeback/sdk/identity).
### Timeback Desktop App
Students launch learning apps through the Timeback Desktop App. Beyond serving as a launcher, it collects **engagement signals** that feed into the analytics pipeline:
* **Waste detection**: Identifies when students are idle, distracted, or multitasking
* **Time-on-task measurement**: Distinguishes active learning from passive screen time
* **Session context**: Captures which apps are in use and for how long
For developers, these signals answer a question you can't answer on your own: **is the problem your content, or is the student disengaged?**
If a student is struggling, the platform can distinguish between "low effort" (motivation issue) and "content too hard" (curriculum issue). This means you can diagnose problems with your app that would otherwise be invisible. When engagement is high but outcomes are low, you know to fix the instruction. When engagement is low, the problem is upstream of your content.
### Student and developer dashboards
**Student dashboards** expose progress in a way that reinforces motivation: XP earned, mastery achieved, time reclaimed. Students see exactly where they stand and what is left to complete.
**Developer dashboards** show how your app performs across the student population: completion rates, accuracy distributions, time-to-mastery, and correlation with standardized test outcomes. When something is not working, you see it in the data.
## The closed loop
Most edtech products operate in an **open loop**: students use the app, some metrics are collected, but nobody knows if learning actually happened. Engagement is tracked because it can be measured. Outcomes are not tracked because they require external validation.
Timeback operates in a **closed loop**: in-app activity is tied to standardized test performance, and the correlation is used to improve instruction.
### What the loop measures
The platform captures signals at multiple levels:
| Signal | What it indicates |
| ---------------------------- | ---------------------------------- |
| **XP earned** | Volume of productive learning time |
| **Accuracy** | Quality of understanding |
| **Time-to-mastery** | Efficiency of instruction |
| **Waste percentage** | Behavior and motivation issues |
| **Standardized test scores** | Transfer to external assessments |
### Why the loop matters for developers
Most edtech companies can't prove their product works. They show engagement metrics, completion rates, and testimonials. But when a school asks "did students learn more?", the honest answer is usually "we don't know."
The closed loop changes this. For developers, it provides:
**Evidence for evaluation.** Linked activity and assessment data can support analysis. Correlation alone does not establish that an app caused improved learning.
**Diagnosis when things break.** If outcomes aren't improving, you see exactly where the breakdown happens:
* **Motivation issues** (low minutes, high waste, inconsistent effort): the problem is upstream of your content
* **Placement issues** (accuracy too high or too low): students are in the wrong place in the curriculum
* **Curriculum issues** (students complete content but scores don't improve): your instruction needs work
**Faster iteration.** Instead of waiting months for anecdotal feedback, you see the impact of changes in the data. Did the new lesson sequence improve time-to-mastery? Did the redesigned practice set increase transfer to assessments? Evaluate those questions with an appropriate study design; the presence of telemetry alone does not answer them.
### External validation
Timeback ties in-app progress to rigorous external assessments:
* **MAP Growth**: Norm-referenced achievement and growth measurement
* **State assessments**: Criterion-referenced mastery verification
* **SAT/AP**: College readiness and advanced placement
When test results arrive, the analytics pipeline correlates them with in-app behavior. This enables comparisons: Did 30 minutes in App A produce more measurable learning than 30 minutes in App B?
### Hole filling
External validation reveals gaps. Hole filling addresses them.
Supported remediation workflows can use assessment results and missed standards to select targeted content and schedule a retest. Eligibility, score thresholds, grade bands, available content, and progression steps vary by subject, app, and workflow. A score below 90% does not universally or immediately create a hole-filling course.
This is the second half of the closed loop. Validation tells you *what's wrong*. Hole filling *fixes it*.
For developers, hole filling means your content participates in a system that actually responds to failure. If students struggle with specific lessons, the platform can route them to remediation (from your app or another) and bring them back to retry. An adapter or configured workflow must support the required content and routing.
## Where your app fits
Apps integrate with Timeback at different depths depending on what they need:
| Integration level | What you use | What you get |
| ----------------- | -------------------------------------------------------- | --------------------------------------------------- |
| **Basic** | LTI launch, OneRoster enrollments | Single sign-on, roster sync |
| **Events** | Caliper events (heartbeats + completions), progress APIs | Analytics, XP tracking, dashboards |
| **Assessments** | QTI content, adaptive delivery APIs | Adaptive quizzes, mastery gating |
| **Full** | All APIs, standards alignment | Complete curriculum integration, outcome validation |
### What you build versus what the platform provides
| You build | Platform provides |
| -------------------------------- | -------------------------------------------- |
| Learning experiences and content | Rostering and identity management |
| Question items and lesson flows | Authentication and permissions |
| UI and interaction design | Progress tracking and mastery state |
| Game mechanics and motivation | XP tracking, aggregation, and reward systems |
| Subject-specific pedagogy | Analytics and outcome measurement |
| Your unique value proposition | Standards compliance and school integrations |
### Integration paths
**Launch and identity**: LTI launch and SDK OIDC SSO are separate integration contracts. For the SDK, configure SSO or custom identity and own a secure application session. Do not assume every launcher uses LTI or that a launch URL alone authenticates the user.
**Emit events via Caliper**: Activity telemetry is split into continuous time-spent heartbeats and completion submissions. The SDK correlates these events per run, and stateful apps can record completion from the backend while still reporting time from the frontend. The platform captures the stream, updates progress, and feeds analytics.
**Read and write via OneRoster**: Query enrollments to know what content a student should see. Write results to the gradebook so scores appear in dashboards and reports. You do not need to define your own data models for courses and progress.
**Deliver assessments via QTI**: Store questions in QTI format. Use the platform's adaptive delivery APIs for placement tests and mastery-based progression. You do not need to build quiz engines or adaptive algorithms from scratch.