How It Works

TL;DR: The Timeback platform stack

| Component | What it provides | |-----------|------------------| | Timeback APIs | 1EdTech standards (OneRoster, LTI, QTI, Caliper, CASE, CLR) for rosters, launch, content, events, and credentials | | Timeback Desktop App | Student launcher that collects engagement signals (waste detection, time-on-task) | | Dashboards | Progress visibility for students; analytics and outcome correlation for developers | | The closed loop | External validation via standardized tests, connecting in-app activity to real outcomes |

Timeback is a platform for building educational software where outcomes are measurable. It provides the data infrastructure, APIs, and feedback loops that let developers focus on learning experiences instead of rebuilding rostering, progress tracking, analytics, and school integrations from scratch. This page covers the architecture developers interact with. For learning science constraints and the motivation system, see The Principles. For integration guides, see Build on Timeback.

​

Platform architecture

Timeback is built as a three-layer system. Each layer builds on the one below it, and the entire stack is designed around a single goal: connecting what happens in apps to what students can demonstrate on credible assessments.

​

Layer 1: Standards backbone

The foundation is a set of 1EdTech-compliant APIs that implement industry-standard data models. Schools already speak these standards for rostering, assessments, and analytics. By building on them, Timeback apps integrate with existing school infrastructure without custom bridges. 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. When a student completes an activity, the learning system updates their mastery state, calculates XP, and feeds signals into the analytics pipeline. 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. The platform handles everything below.

​

The Timeback stack

Here is what developers actually interact with when building on the platform:

​

Timeback APIs

Rather than inventing proprietary interfaces, the platform implements industry specs directly. For developers, this means:

• No lock-in. The APIs you learn here work with other compliant systems. Your skills and code are portable.
• Schools already trust it. Procurement conversations are easier when you’re implementing specs schools already require.
• Skip years of infrastructure. Rostering, identity, event logging, and analytics are solved. Build what differentiates you.

​

1EdTech Standards

The Timeback APIs are 1EdTech standards. 1EdTech (formerly IMS Global) maintains the most comprehensive set of education interoperability standards, and most LMS platforms, SIS systems, and assessment tools already implement some subset of these specs. Timeback extends these standards where necessary to support learning science requirements (mastery thresholds, XP calculations, closed-loop validation) while maintaining compatibility with the base specs.

​

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:

​

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: Proof that works in sales. If students using your content show better standardized test outcomes, the data demonstrates it. You can walk into a procurement meeting with evidence, not promises. 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? The loop tells you.

​

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. When a student scores below mastery on a standardized test (less than 90%), the platform analyzes which standards were missed and generates a targeted remediation course containing just the lessons needed to fill the specific gaps. The student completes the hole-filling content, retests, and only advances once mastery is demonstrated. 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. You don’t have to build the diagnostic or routing logic yourself.

​

Where your app fits

Apps integrate with Timeback at different depths depending on what they need:

​

What you build versus what the platform provides

​

Integration paths

Launch via LTI: Students start in the Timeback Desktop App or an LMS. When they select your app, they are launched with identity and context already provided. You do not need to build login flows or user management. Emit events via Caliper: As students complete activities, you send events to the Caliper endpoint. The platform captures them, updates progress, and feeds them into analytics. You do not need to build analytics infrastructure. 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.

​

What this enables for developers

Building on Timeback means inheriting infrastructure that would otherwise take years to build: Skip the commodity work. Rostering, identity, progress tracking, analytics, and school integrations are solved. Focus on the learning experience that differentiates your app. Know if your app works. The closed loop validates whether your content produces measurable learning gains. Iterate based on outcomes, not just engagement. Reach students through existing channels. Apps on Timeback reach students through Alpha School, partner schools, and direct-to-consumer channels without additional distribution work. Compound with the ecosystem. Apps that follow Timeback’s learning science principles work together. A tutoring app can pick up where a lesson app left off because both share the same progress model.

---