# Activity models Source: https://docs.timeback.com/beta/about-timeback/concepts/activity-models Single-session vs stateful activities and when to use each Timeback supports two activity models. The right choice depends on the nature of your app, its architecture, and the learning material: specifically, whether students complete an activity in one sitting or across multiple sessions. ## Single-session The simplest model: a student starts and completes an activity in one browser session. ```mermaid theme={null} graph LR A[Student starts] --> B[Engages] --> C[Ends activity] style A fill:#e0f2fe,stroke:#0284c7 style C fill:#dcfce7,stroke:#16a34a ``` The browser SDK measures time locally and submits time heartbeats and completion separately. Your app owns the completion decision and supplied metrics; authenticate the user and validate important outcomes on your server. **Use single-session when:** * Students complete the activity in one sitting (quizzes, short lessons, drills) * The frontend has all the data it needs to report completion metrics * You do not need to persist activity state across page reloads ## Stateful/Resumable Many apps support activities that span multiple sessions: ```mermaid theme={null} graph TD subgraph Monday A[Student starts] --> B[Answers 10 questions] --> C[Leaves] end C -.-> |Tuesday — no activity| D subgraph Wednesday D[Student resumes] --> E[Answers 10 more] --> F[Completes] end style A fill:#e0f2fe,stroke:#0284c7 style C fill:#fef9c3,stroke:#ca8a04 style D fill:#e0f2fe,stroke:#0284c7 style F fill:#dcfce7,stroke:#16a34a ``` Here, state lives in the **app's database**: progress, accumulated time, and status. The frontend cannot be the sole source of truth because it was not present for all sessions. **Use stateful when:** * Activities span multiple days or sessions * The backend owns progress (server-validated answers, adaptive learning) * Students need to resume where they left off ## The Key Insight Timeback emits two types of learning events: *"Student engaged for N seconds"* **Per session**: Multiple events per activity run. *"Student finished with these results"* **Per activity**: Your application should report completion once. This is a reporting rule, not an exactly-once delivery guarantee. For single-session activities, the student starts and finishes in one sitting, but time and completion still use separate requests and may succeed or fail independently. Stateful activities do not. Time-spent should be reported per learning session (e.g., "12 minutes on Monday", "8 minutes on Wednesday"), while activity completion happens once, when the activity is truly done. The SDK handles this by decoupling time tracking from completion. Time is reported continuously via periodic heartbeats. Completion is reported separately, either from the client or the server. ## How the models differ | Aspect | Single-session | Stateful | | ------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Sessions** | One | Multiple | | **Time tracking** | Automatic heartbeats | Automatic heartbeats | | **Completion** | [`activity.end(...)`](/beta/build-on-timeback/sdk/activity-tracking/single-session#starting-an-activity) | [`timeback.activity.record(...)`](/beta/build-on-timeback/sdk/activity-tracking/stateful#backend) | | **State ownership** | App (with browser session state) | App database | | **Resume support** | Not needed | UUID `runId` persisted and reused | Both models use the same client SDK for time tracking. The difference is in who reports completion and whether state persists across sessions. Implementation guide for one-sitting activities. Implementation guide for multi-session activities. # Evaluating apps Source: https://docs.timeback.com/beta/about-timeback/concepts/evaluating-apps How Timeback measures app quality This page describes product principles and review policy. These thresholds are not universal enforcement in every SDK or receiver. Check the relevant integration contract and confirm current approval requirements with the Timeback team. Timeback operates on a simple principle: **if students are not learning, it is the system's fault.** Apps are evaluated the same way. | Dimension | What matters | | ------------------------------ | -------------------------------------------------- | | **Granularity** | One teachable unit at a time | | **Instruction quality** | Clear explanations, worked examples, minimal noise | | **Mastery truthfulness** | "Completed" means mastered | | **Coverage and rigor** | Aligned to real external tests | | **Efficiency** | Fewer hours to reach the same verified outcome | | **Hole-filling compatibility** | Targeted remediation is possible when gaps show up | If an app performs well on engagement but poorly on externally validated outcomes, the closed loop forces the conversation back to instruction, mastery, and signal integrity. The rules every app must follow. Level 1 vs Level 2 requirements. # Learning science Source: https://docs.timeback.com/beta/about-timeback/concepts/learning-science The hierarchy of learning mechanisms that guide Timeback's design The tiers below express Timeback's instructional design priorities. They are a product framework, not a universal ranking established by the SDK or a claim that every deployed learning flow enforces these thresholds. ## Tier 0: Non-negotiables These must be in place before anything else matters. | Mechanism | What it means | | --------------------------- | ---------------------------------------------------------------------------------------- | | **Faultless communication** | Instruction is unambiguous. Examples clearly distinguish what counts from what does not. | | **Retrieval practice** | Active recall is the primary learning event, not passive consumption. | | **Mastery gating** | Students do not progress without demonstrating ≥90% accuracy on rigorous assessments. | ## Tier 1: Force multipliers These amplify Tier 0 once the foundation is solid. | Mechanism | What it means | | ------------------- | ---------------------------------------------------------------------- | | **Spacing** | Distribute practice over time. Cramming creates temporary performance. | | **Interleaving** | Mix problem types to prevent context-dependency. | | **Worked examples** | Study complete solutions before attempting problems. | | **Feedback** | Immediate for basic facts; elaborated (explaining why) for concepts. | ## Tier 2: Context-dependent These work under specific conditions. | Mechanism | What it means | | ---------------- | --------------------------------------------------------------------------------- | | **Novelty** | Activates attention. Useful for marking practice intervals. | | **Multimedia** | Combine verbal and visual when both add value. Avoid redundancy. | | **Gamification** | Can increase engagement if it reinforces learning behaviors, not just completion. | Tier 0 is binary. You either have faultless communication, retrieval practice, and mastery gating, or you do not. No amount of Tier 1 or 2 optimizations can compensate for a broken foundation. # Non-negotiables Source: https://docs.timeback.com/beta/about-timeback/concepts/non-negotiables The rules every Timeback app must follow This page describes product principles and review policy. These thresholds are not universal enforcement in every SDK or receiver. Check the relevant integration contract and confirm current approval requirements with the Timeback team. These are the rules every integrated learning app must follow. They protect outcome integrity across the ecosystem. 1. **Teach toward verifiable outcomes.** In-app success must predict performance on credible external assessments. 2. **Enforce mastery gates at ≥90% accuracy.** Do not advance students based on time, completion, or self-report. 3. **Award XP only for verified learning.** No XP for passive activity until learning is verified through retrieval. No XP below 80% accuracy. 4. **Design for cognitive load limits.** Keep granularity tight, reduce noise, avoid bundling multiple new skills in one lesson. 5. **Make misconceptions hard to form.** Use clear examples, non-examples, and fast error correction. 6. **Build in retrieval practice and spaced review.** Practice must require recall, not just recognition. 7. **Prevent gaming.** Treat incentives as adversarial. Make the target cognitive process unavoidable. 8. **Emit learning events and keep outcomes transparent.** Results are surfaced to students, families, and operators. Apps cannot hide poor performance. Apps that award credit without verified learning, allow progression without mastery, or fail to emit the required learning signals will not be eligible for integration. # 1EdTech standards Source: https://docs.timeback.com/beta/about-timeback/concepts/standards Standards used by Timeback interfaces and their integration boundaries 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). # XP system Source: https://docs.timeback.com/beta/about-timeback/concepts/xp-system How Timeback measures learning effort and progress The XP rules below describe the intended reward policy. Custom Activity SDK calls accept app-supplied XP; they do not calculate a universal time-to-XP conversion, enforce an 80% accuracy gate, or detect cheating. TypeScript accepts negative XP; the reviewed Python activity schema requires nonnegative XP. Agree the formula for your integration and validate the emitted metrics. ## Why XP exists Education software usually forces a false choice: track **time** (which measures presence, not learning) or track **accuracy** (which ignores how much work was done). A student who spends 30 focused minutes mastering fractions and a student who clicks through the same lesson in 5 minutes can both show "100% complete", yet the learning that happened is vastly different. XP solves this by combining **effort** with **proof**. It's a single metric that captures both how long a student worked and whether that work produced verified learning. This makes it possible to compare outcomes across apps, content, and students. ## The design **1 XP = 1 minute of focused learning.** Anchoring XP to real time creates a universal unit that every app in the ecosystem shares. Interpreting XP as calibrated learning effort depends on each contributing app following the agreed policy; a profile total alone does not verify elapsed minutes or mastery. Two concepts make this work: | Concept | Definition | | --------------- | ------------------------------------------------------------ | | **Expected XP** | How long a focused student should take | | **Awarded XP** | What the student actually earns, based on verifiable metrics | **Expected XP** is calibrated at the content level by the app developer. It represents the time a focused student should need to master the material. **Awarded XP** is what the student earns after completing the activity. It depends on whether mastery was demonstrated and how efficiently the student worked. ## How XP is awarded Not all effort is equal. XP reflects the quality of learning, not just the fact that something was done. | Outcome | Effort quality | XP result | | ----------------------- | --------------- | ------------------ | | Mastered | Focused | Full XP | | Perfect (first attempt) | Focused | Full XP + Bonus XP | | Not mastered | Focused | 0 XP | | Mastered | Wasteful | Partial XP | | Any | Gaming/cheating | Negative XP | A student who masters the material efficiently earns full XP. A student who gets it right on the first try earns a bonus. A student who works hard but doesn't reach mastery earns nothing, because XP represents *verified* learning, not just participation. No XP is awarded below 80% accuracy. This discourages students from speed-running content or guessing until correct. ### Why negative XP? If XP can be earned without real cognitive effort, the metric loses its meaning. Negative XP exists to discourage behaviors like exploiting answer patterns or using external tools to bypass assessments. Rather than simply awarding zero, an application may report a deduction under its agreed policy. The custom activity SDK does not detect gaming or issue that deduction itself. ## How XP flows through the system When an activity completes, the app reports the XP earned. Timeback processes activity data through the gradebook pipeline and aggregates it in the student's [profile](/beta/build-on-timeback/sdk/user-profile), where it's surfaced in dashboards alongside XP from other apps. Because every app reports XP using the same unit, the platform can answer questions that no single app can: * Did 30 minutes in App A produce more learning than 30 minutes in App B? * Which content sequences produce faster mastery for which students? * Is a student's total daily effort on track? How apps report XP through the SDK The rules that protect XP integrity # How It Works Source: https://docs.timeback.com/beta/about-timeback/how-it-works The platform architecture that enables measurable learning outcomes This is a conceptual map. Available launchers, dashboards, analytics, and remediation flows depend on the deployed product and configuration. The SDK and API guides describe the verified integration contracts; the diagrams do not establish a live deployment or universal automation.
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
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](/beta/about-timeback/principles). For integration guides, see [Build on Timeback](/beta/build-on-timeback/introduction). ## 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**. Timeback platform stack showing the Timeback 1EdTech APIs at top, Learning Apps in the middle receiving Content + Learning Engine and emitting Learning Events + Mastery, Student Dashboard launching apps, all within the Timeback Desktop App container, with Progress and Waste Meter signals flowing back to the APIs Timeback platform stack showing the Timeback 1EdTech APIs at top, Learning Apps in the middle receiving Content + Learning Engine and emitting Learning Events + Mastery, Student Dashboard launching apps, all within the Timeback Desktop App container, with Progress and Waste Meter signals flowing back to the APIs ### 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. Timeback API architecture showing how your application connects through OAuth to OneRoster, Caliper, QTI, CASE, CLR, and Open Badges Timeback API architecture showing how your application connects through OAuth to OneRoster, Caliper, QTI, CASE, CLR, and Open Badges ### 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. Closed loop diagram showing Content flowing to Mastery Engine, to Learning Apps, to Event Stream and Standardized Tests, to Analytics, to Validated Outcomes, which improves Content Closed loop diagram showing Content flowing to Mastery Engine, to Learning Apps, to Event Stream and Standardized Tests, to Analytics, to Validated Outcomes, which improves Content ### 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. The depth of integration is your choice. Some apps only need launch and events. Others use the full stack. Start with what you need and add more as your product matures. ## 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 subject to onboarding, curriculum fit, approval, and deployment availability. **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. *** This page covers how the platform works. For the learning science principles that guide what apps should do, see [The Principles](/beta/about-timeback/principles). For integration guides and API reference, see [Build on Timeback](/beta/build-on-timeback/introduction). Why current edtech cannot prove outcomes. What Timeback is building toward. Learning science constraints that protect outcomes. What developers get from the platform. # The Principles Source: https://docs.timeback.com/beta/about-timeback/principles The learning constraints, motivation model, and measurement rules that make outcomes provable and improvable This page presents Timeback's product rationale and goals. Educational efficacy, market-wide comparisons, distribution commitments, and current program availability require evidence beyond repository code. Use the integration guides for implemented API behavior.
Principle What it means for app builders
Tier 0 first Communication, retrieval, mastery gating first
Content is the lever Example selection is product design
Cognitive load Instruction must fit working memory limits
Transfer via testing Evaluated on external tests, not in-app metrics
Retrieval and spacing Retrieval is learning; spacing keeps it
Motivation + rigor Push through high standards, never lower them
Trustworthy metrics XP/time-to-mastery are hard to game
Interoperability Shared events compound rather than fragment progress
Timeback is not a marketplace of "any learning experience goes." It is a platform built around constraints that make learning outcomes **measurable, comparable, and improvable** across apps. These principles are the reason Timeback can run a real closed loop: apps generate learning signals, the platform aggregates them consistently, and external assessments verify what actually transferred. Builders who align with these constraints get leverage from the ecosystem. Builders who do not align get exposed by the measurement system. *** ## Learning Science Foundations Timeback uses a strict definition of learning: **a durable change in long-term memory** that shows up later, in new contexts, and on credible assessments. For developers, this changes product incentives. "High in-app accuracy" is not automatically success. "Kids love it" is not automatically success. "They finished the course" is not automatically success. Success is when students can still do the skill later, under variation, at the rigor demanded by real tests. ### The hierarchy of learning mechanisms The tiers below express Timeback's instructional design priorities, not a universal research ranking or proof that every deployed app enforces these thresholds. #### Tier 0: Non-negotiables These must be in place before anything else matters. | Mechanism | What it means | | --------------------------- | ---------------------------------------------------------------------------------------- | | **Faultless communication** | Instruction is unambiguous. Examples clearly distinguish what counts from what does not. | | **Retrieval practice** | Active recall is the primary learning event, not passive consumption. | | **Mastery gating** | Students do not progress without demonstrating ≥90% accuracy on rigorous assessments. | #### Tier 1: Force multipliers These amplify Tier 0 once the foundation is solid. | Mechanism | What it means | | ------------------- | ---------------------------------------------------------------------- | | **Spacing** | Distribute practice over time. Cramming creates temporary performance. | | **Interleaving** | Mix problem types to prevent context-dependency. | | **Worked examples** | Study complete solutions before attempting problems. | | **Feedback** | Immediate for basic facts; elaborated (explaining why) for concepts. | #### Tier 2: Context-dependent These work under specific conditions. | Mechanism | What it means | | ---------------- | --------------------------------------------------------------------------------- | | **Novelty** | Activates attention. Useful for marking practice intervals. | | **Multimedia** | Combine verbal and visual when both add value. Avoid redundancy. | | **Gamification** | Can increase engagement if it reinforces learning behaviors, not just completion. | Tier 0 is binary. You either have faultless communication, retrieval practice, and mastery gating, or you do not. No amount of Tier 1 or 2 optimizations can compensate for a broken foundation. Features are liabilities; mechanisms are assets. ### Content is the lever Students infer rules from the patterns you present. If your examples allow multiple interpretations, students will form misconceptions that are *rational given the evidence*. This is why faultless communication sits at Tier 0. Misconceptions are often rational inferences from ambiguous evidence, not failures of attention or effort. If the learner can logically infer the wrong rule from the examples provided, the fault lies with the instruction, not the learner. Timeback borrows heavily from Direct Instruction style design: * **Contrastive examples** that show what counts and what does not * **Near-misses** that differ only in the critical feature * **Minimally different examples** that isolate what matters * **Immediate error correction** that prevents wrong rules from becoming stable memory This principle has a direct developer implication: **example selection is product design**, not content polish. **Make the target cognitive process unavoidable.** If students can succeed via pattern matching, shallow guessing strategies, or memorizing repeated items, the app is gameable and its signals are untrustworthy. ### Cognitive load is the constraint Working memory is severely limited. When instruction overloads it, students do not "try harder and get there." They stall, guess, or memorize surface patterns. This is why the Tier 0 mechanisms exist: they respect cognitive limits while ensuring learning actually happens. The highest-leverage move is **granularity**. Timeback strongly prefers learning flows that teach one thing at a time, keep steps small enough that errors are diagnosable, and build integration only after components are secure. **Practical implications:** * Lessons should target a single concept, skill, or procedure * Ensure each component is secure before asking students to integrate them * Use worked examples before independent practice * Remove extraneous content that consumes cognitive resources without serving learning ### The closed loop validates transfer Students can appear successful while acquiring knowledge that does not transfer, persist, or show up on meaningful assessments. High in-app accuracy can be driven by pattern matching, memorization of specific items, or shallow strategies that collapse under variation. | Success pattern | What it indicates | | -------------------------------------- | -------------------------------------- | | High in-app accuracy, high test scores | Learning is occurring and transferring | | High in-app accuracy, low test scores | In-app tasks are not testing transfer | | Low in-app accuracy, low test scores | Instruction is not working | **Invisible failure is worse than visible error.** A system that fails visibly can be debugged and fixed. A system that fails invisibly gets mistaken for one that works. Learning systems face a fundamental asymmetry: success and failure are not equally visible. A learner who fails may produce signals that mimic success: completion without comprehension, correct answers via shortcuts, engagement metrics that track time without cognitive work. The Timeback closed loop exists specifically to make failure visible. External standardized tests validate what students actually learned. When in-app success diverges from test performance, the gap is exposed, and the conversation returns to instruction, content, and mastery. Timeback's standard for "did it work?" is transfer on external assessments, not in-app metrics. *** ## The Motivation System Timeback treats motivation as a core product problem, not UI polish. Consistent effort is a prerequisite for consistent outcomes. **Time back** is the primary motivator: finish academics with mastery, reclaim the day. Students who complete academics in about two hours reclaim four or more hours for sports, life skills, and creativity. Students who rush through content without mastery do not get their time back. They get remediation. When time-back is not available, incentives must still push toward mastery, not toward completion theater. The XP rules below describe the intended reward policy. Custom Activity SDK calls accept app-supplied XP; they do not calculate a universal time-to-XP conversion, enforce an 80% accuracy gate, or detect cheating. TypeScript accepts negative XP; the reviewed Python activity schema requires nonnegative XP. Agree the formula for your integration and validate the emitted metrics. ### XP as a universal progress currency Timeback uses XP as a shared unit across apps. XP exists because education software usually forces a false choice: track time (which measures presence, not learning) or track accuracy (which ignores how much work was done). XP combines effort with proof. **The core specification: 1 XP = 1 minute of focused learning.** | Concept | Definition | | --------------- | -------------------------------------------------------------------- | | **Expected XP** | How long a focused student should take (content-level constant) | | **Awarded XP** | What the student earns based on verified learning and effort quality | This is one of the core ways Timeback makes apps comparable: time-to-mastery is a legitimate metric only when the unit is consistent. | Outcome | Effort quality | XP result | | ----------------------- | --------------- | ----------- | | Mastered | Focused | Full XP | | Perfect (first attempt) | Focused | Bonus XP | | Not mastered | Focused | 0 XP | | Mastered | Wasteful | Partial XP | | Any | Gaming/cheating | Negative XP | ### From extrinsic to intrinsic Timeback uses extrinsic rewards to create enough early success that competence can form. Competence builds confidence. Confidence enables identity change. Identity is what lasts. **The motivation arc:** 1. **Extrinsic rewards** get students to engage consistently 2. **Consistent engagement** produces **competence** 3. **Competence** builds **confidence** 4. **Confidence** enables **identity change** 5. **Identity** sustains **intrinsic motivation** This only works if mastery is real. Rewards for fake progress train students to optimize the reward system, not their knowledge. Motivation follows mastery, not the reverse. ### Why gaming must be prevented Any reward system attracts gaming. Students are not "bad" for doing this; they are optimizing incentives. Timeback assumes adversarial optimization and hardens signals accordingly. **Common gaming patterns:** * Tanking placement tests to receive easier content * Clicking through explanations without reading * Guessing until correct * Pattern matching on test items rather than learning concepts Timeback builds anti-gaming protections into the platform. The Timeback Desktop App collects engagement signals (waste detection, time-on-task) that distinguish active learning from passive screen time. For developers, this means designing apps where the target cognitive process is *unavoidable*. *** This page describes product principles and review policy. These thresholds are not universal enforcement in every SDK or receiver. Check the relevant integration contract and confirm current approval requirements with the Timeback team. ## How Timeback Evaluates Apps Timeback operates on a simple principle: **if students are not learning, it is the system's fault.** Apps are evaluated the same way. | Dimension | What matters | | ------------------------------ | -------------------------------------------------- | | **Granularity** | One teachable unit at a time | | **Instruction quality** | Clear explanations, worked examples, minimal noise | | **Mastery truthfulness** | "Completed" means mastered | | **Coverage and rigor** | Aligned to real external tests | | **Efficiency** | Fewer hours to reach the same verified outcome | | **Hole-filling compatibility** | Targeted remediation is possible when gaps show up | If an app performs well on engagement but poorly on externally validated outcomes, the closed loop forces the conversation back to instruction, mastery, and signal integrity. *** This page describes product principles and review policy. These thresholds are not universal enforcement in every SDK or receiver. Check the relevant integration contract and confirm current approval requirements with the Timeback team. ## The Non-Negotiables These are the rules every integrated learning app must follow. They protect outcome integrity across the ecosystem. 1. **Teach toward verifiable outcomes.** In-app success must predict performance on credible external assessments. 2. **Enforce mastery gates at ≥90% accuracy.** Do not advance students based on time, completion, or self-report. Timeback treats 90% on rigorous checks as the mastery bar. 3. **Award XP only for verified learning.** No XP for passive activity (reading, watching) until learning is verified through retrieval. No XP below 80% accuracy. 4. **Design for cognitive load limits.** Keep granularity tight, reduce noise, and avoid bundling multiple new skills in one lesson. 5. **Make misconceptions hard to form.** Use clear examples, non-examples, and fast error correction. 6. **Build in retrieval practice and spaced review.** Practice must require recall, not just recognition. Plan for retention across time, not just short-term performance. 7. **Prevent gaming.** Treat incentives as adversarial. Make the target cognitive process unavoidable. 8. **Emit learning events and keep outcomes transparent.** The platform must be able to attribute work to student, content, and attempt. Results are surfaced to students, families, and operators. Apps cannot hide poor performance. Timeback's closed loop only works if apps play by the same measurement and mastery rules. Apps that award credit without verified learning, allow progression without mastery, or fail to emit the required learning signals may be ineligible for integration. *** Apps that follow these principles compound each other's effectiveness. A tutoring app can pick up where a lesson app left off because both share the same mastery model. A practice app can reinforce what an instruction app taught because both emit compatible events. Apps that violate these principles will show poor outcomes, and that will be visible. See how these principles show up in the platform stack and the closed loop. The developer benefits that come from these constraints. Choose how deeply your app plugs into events, assessments, and progress. Why current edtech cannot reliably produce outcomes. # The Problem Source: https://docs.timeback.com/beta/about-timeback/problem Education software can't reliably produce or prove learning outcomes This page presents Timeback's product rationale and goals. Educational efficacy, market-wide comparisons, distribution commitments, and current program availability require evidence beyond repository code. Use the integration guides for implemented API behavior.
Problem Summary
Time-based, not mastery Students advance by age, not mastery
No closed loop Edtech can't prove outcomes or improve them
Fragmented ecosystem Every app is a silo with its own data model
No shared metrics No shared language for effort/progress/efficiency
Wrong incentives Engagement is rewarded over learning
Invisible failure Learning problems surface too late
Motivation ignored The biggest bottleneck is an afterthought
Developer tax Every team rebuilds the same plumbing
Education is one of the largest software markets on earth, yet most products cannot reliably answer a simple question: **did learning happen, and did it happen efficiently?** Schools, families, and developers are stuck optimizing proxies like usage, completion, and seat time because the ecosystem lacks shared data and shared measurement. Timeback exists because the core failures are structural. Education is organized around *time*. Edtech is organized around *isolated apps*. And learning is governed by constraints most products don't instrument or respect. ## Measuring time, not mastery Traditional schooling measures progress by calendars, attendance, and age rather than **demonstrated competence**. Students advance through grades with gaps, and those gaps compound silently until "grade level" becomes a label rather than a description of what a student can actually do. This "social promotion" model makes it nearly impossible to diagnose *why* a student struggles. Is it the content? The instruction? Missing prerequisites? The system can't tell. Instruction quality varies widely, outcomes remain opaque, and students advance based on **time served** rather than knowledge gained. ## Can't improve what you can't prove Most education products can show activity (minutes spent, clicks, lessons completed) but cannot prove **causal impact on durable learning**. Even when test scores are available, they're often disconnected from what happened inside the product. Iteration is slow. Arguments about efficacy are endless. The industry standard is the opposite: **open loops everywhere**. Everyone hopes learning happened but few systems can verify it. Edtech companies end up optimizing for engagement, retention, and session length because those are the metrics they *can* actually measure. | What gets tracked | What actually matters | | ------------------ | ---------------------- | | Minutes spent | Knowledge retained | | Lessons completed | Skills transferred | | Daily streaks | Mastery demonstrated | | Click-through rate | Test score improvement | ## Every app is a silo Schools run dozens of tools across rostering, content, assessment, tutoring, analytics, and motivation. But apps rarely share a coherent underlying data model. Each new product must **reinvent the same infrastructure** from scratch: * Rostering and identity management to sync student and class data * Authentication and access control for logins and permissions * Content storage and delivery for lessons and assessments * Progress and mastery tracking to define what "done" and "learned" mean * Analytics and event logging to capture what happens in the app * Standardized test integration to connect to meaningful outcomes Each app becomes its own "mini platform." Schools become the integration layer, manually reconciling data across dashboards that disagree with each other. Diagram showing a Student connecting to App A, App B, and App C, each with their own Dashboard, with no shared record between them Diagram showing a Student connecting to App A, App B, and App C, each with their own Dashboard, with no shared record between them Students use multiple tools that cannot share information. There is **no shared record of learning**. ## No language for effort, progress, or efficiency Even when edtech apps work, schools can't compare them. One product reports points, another reports levels, another reports completion percent, another reports time spent. None of these are interoperable, and most aren't tied to **externally verifiable outcomes**. Developers should be able to answer basic questions in a mature platform ecosystem. Did 30 minutes in Tool A produce more learning than 30 minutes in Tool B? Which content sequences produce faster mastery for which students? Where are students stuck because of missing prerequisites versus confusion versus disengagement? Today, these questions *can't be answered*. Parents see a jumble of incompatible dashboards. Teachers can't build a coherent picture of student performance. Administrators can't make informed decisions about which products deserve investment. ## Incentives reward engagement, even when it conflicts with learning Many products are built to maximize retention metrics: time in app, daily streaks, content consumption. But **time spent is not the same as learning**. Systems that reward "doing school" can accidentally reward low-effort behaviors that look productive. Gamification often rewards *completion* rather than *mastery*. Students learn to optimize for points with minimal cognitive effort: clicking through explanations, guessing until correct, avoiding challenging content. Systems report high engagement while actual learning doesn't happen. Products that feel good and look busy win procurement cycles. Products that are efficient and rigorous are harder to explain using today's dashboards. ## Learning failure is often invisible Students can appear successful in a product while learning very little that transfers or persists. High in-app accuracy can be driven by pattern matching, memorization of specific items, or shallow strategies that **collapse under variation**. Common failure patterns: * Students advance based on completion, not understanding * New content is layered on top of gaps, causing compounding failure * Correct answers in-app don't transfer to real assessment results * Learners infer wrong rules from poorly designed instruction * Systems report success while actual learning doesn't happen When systems don't instrument for transfer, prerequisites, and cognitive load, failure surfaces late: on real assessments, in later units, or in the next grade. **Invisible failure is the most damaging failure mode** in scalable learning systems. Learning science calls this the "transfer problem": success in the training environment doesn't guarantee success elsewhere. Apps that don't test for transfer can't detect this failure. ## Motivation is the bottleneck Even the best instructional design fails if students won't engage consistently. The industry often treats motivation as UI polish (badges, confetti, streaks) rather than as a **core product problem** with measurable consequences. Traditional systems don't give students a compelling reason to try. There is no meaningful reward for mastery, no "time back" for finishing early, no visible proof that effort leads to results. The standard motivational model is "work hard for 12 years, then 4 more, then a job." No adult would accept that. Yet we expect children to. Effective motivation requires designing systems where effort leads to *visible outcomes*. Time reclaimed. Skills demonstrated. Goals achieved. Surface gamification doesn't cut it. ## Developers pay the infrastructure tax For builders, fragmentation and lack of standards creates a **compounding tax**: * Rebuilding primitives: rostering, identity, permissions, observability * Guessing at data models for courses, content, and results * No way to validate impact, so iteration is slow and proof is expensive * No reliable feedback loop to tell you what's actually improving learning In other software categories, platforms reduce this tax. In education, the lack of shared standards and outcome-linked measurement means every serious team ends up trying to become a platform, whether they want to or not. Edtech apps are expensive to build, hard to measure, and don't work together. Most fail to move the needle on actual learning. Not because the teams lack talent, but because **the infrastructure to build effective, measurable, interoperable learning products does not exist**. *** This page describes the problems Timeback is built around. Next, see how the platform approaches standards, measurement, and interoperability. See what Timeback is building toward. The platform architecture designed to close the loop. What developers get by building on Timeback. # The Vision Source: https://docs.timeback.com/beta/about-timeback/vision A learning platform where outcomes are measurable and improvable This page presents Timeback's product rationale and goals. Educational efficacy, market-wide comparisons, distribution commitments, and current program availability require evidence beyond repository code. Use the integration guides for implemented API behavior.
Vision pillar What it enables
Academics are efficient Master academics faster, reclaim hours daily
A billion kids Global scale through AI and falling costs
Proven in production Evaluate outcomes for your own app
Build once, reach many Reach schools, families, and global markets
Outcomes as product Measured, verifiable, continuously improved
Standards backbone Stop rebuilding the same infra from scratch
Learning science Effective practices become platform defaults
Motivation + rigor High standards that are engaging and hard to game
Timeback is building an education platform where **learning outcomes are measured**, comparable across tools, and improved through a closed loop. What students do in software connects directly to what they can demonstrate on credible assessments. ## Give kids their time back The core promise: **academics get radically more efficient**. Students who learn faster reclaim meaningful time every day. That reclaimed time is the point. Space for sports, life skills, projects, creativity, and the rest of childhood. Time back is earned through **real mastery**. Students finish academics by demonstrating competence, then own their afternoon. The goal is a world where time-based schooling feels as outdated as time-based billing for compute. ## Scale to a billion kids The long-term ambition is **global scale**. That requires a cost curve falling with software and AI progress. Once the closed loop exists, the system can improve instruction efficiently, localize content, and expand access without reinventing everything for each geography. AI is the lever. The platform uses AI to generate and personalize content, adapt pacing, close feedback loops, and reduce the marginal cost of instruction. As costs drop, access expands. The target: **more learning per hour** for more students, and more life reclaimed because academics stop consuming the whole day. ## Alpha School: the model in production **[Alpha School](https://alpha.school)** is the working implementation. Students complete academics in two hours, then spend the rest of the day on sports, life skills workshops, passion projects, and character development. Results are measured continuously against external standardized tests.