Platform standards positions
TimeBack implements the 1EdTech standards (OneRoster, Caliper, QTI) and CASE with a few deliberate, consistent positions on where each kind of data lives. Knowing these up front tells you which object to read or write for a given piece of data, and saves you from looking in the wrong place. This page restates four of those positions in terms of the behavior and objects you observe through the API.
Gradebook is for report cards, not per-question results
The OneRoster Gradebook exposes two distinct result objects, and they are not interchangeable:
| Object | Holds | Granularity |
|---|---|---|
| Result | Report-card grades | One per student per line item (course-level) |
| AssessmentResult | Detailed scores for an assessment | One per student per AssessmentLineItem (per-question) |
Per-question outcomes — whether a student got an individual question right, and the score they earned on it — are persisted as AssessmentResult rows, each keyed to a per-question AssessmentLineItem (a child of the parent test). A score (a decimal, typically 0–1) and a human-readable textScore (for example, Correct / Incorrect) live on that row.
When you want a student's result for a specific question, read the AssessmentResult for that question's line item. Do not expect per-question detail on a report-card Result, and do not read it from the question definition itself — the question (its content and scoring rules) is student-agnostic catalogue data.
First-class fields, with metadata as caller pass-through
Every concept the platform models has a dedicated, documented field. If TimeBack reasons about something — relates it, queries it, validates it, or changes behavior based on it — that something is a first-class field you can find in the schema, not a key buried in a free-form bag.
OneRoster objects also carry a JSONB metadata column. On this platform, metadata is strictly caller-owned pass-through:
- You write whatever your application needs into it.
- The platform stores it verbatim and returns it to you unchanged.
- The platform never inspects, queries, indexes, or branches on its contents. No platform behavior depends on what is inside
metadata.
The practical consequence: use metadata for data that is meaningful only to your own application. Do not expect the platform to enforce structure, filter on, or react to anything you place there — if you need platform behavior tied to a value, it belongs in a first-class field, and if one doesn't exist for your use case, that's a gap to raise rather than to work around through metadata.
Caliper carries events, not results
Caliper is the event/transmission layer. The Caliper endpoints accept and emit interaction events — question-answered, assessment-started, grading, and similar — describing what happened. Scored outcomes are carried by Caliper, but as GradeEvents whose generated field is a Score entity (with scoreGiven, scoreMaximum, scoreType). The bare Response entity inside an AssessmentItemEvent carries no isCorrect or score; if you need to report a scored result, emit a separate GradeEvent. Either way, the event vocabulary is about activity, not stored outcomes.
Where a per-question result is stored and queryable depends on how it reaches the platform, not on the Caliper event itself:
- Results from platform-run assessments, or results you submit through the gradebook APIs (OneRoster/mastery assessment results), are persisted as Gradebook AssessmentResults and are read back from the Gradebook.
- Caliper interaction events you send — item-answered, graded, and similar — are stored as analytical signal and surface through the analytics/reporting endpoints. They are not converted into Gradebook AssessmentResults: a Caliper item event carries interaction context but no binding to a gradebook line item, so the platform does not synthesize a result row from it.
Practical guidance: to read a stored per-question outcome, query the Gradebook AssessmentResult. To put a per-question result in the gradebook, submit it through the gradebook API (or let the platform score a platform-run assessment) — sending only Caliper events populates analytics, not the gradebook.
CASE rubrics are tree-level, distinct from question-level grading
CASE (despite the name "Competencies and Academic Standards Exchange") is, on this platform, a general curriculum-tree exchange format. TimeBack uses it for standards and competencies, but also for app-specific curriculum hierarchies — a common shape is subject → course → unit → lesson. The boundary sits below the leaf nodes of the tree: CASE models the tree above; content items (individual questions) live below the boundary and are modeled in QTI.
The word "rubric" then refers to two different objects on the platform, at two different scopes:
- A CASE rubric describes how a node in a CASE tree is assessed — and that node can be a standard, a competency, a course, a unit, or a lesson, depending on what the package models. It is scoped to a CASE package and shares that package's authoring and versioning lifecycle.
- Question-level grading criteria belong to an individual question (a content item, below the CASE boundary). They are defined with the question's content (in QTI) and, for AI-graded responses, each attempt produces its own grading record (score awarded, maximum, any human override, and the audit trail).
These are not the same object and should not be conflated. A CASE rubric tells you how a tree node is evaluated across instruments; question-level criteria tell you how one question is scored on one attempt. They differ in scope (a curriculum-tree node versus a single question) and in lifecycle (framework master data versus per-attempt grading), so you query and reason about each independently.
