TimeBack Platform / QTI / Alpha Surface / Architecture

Alpha QTI is a school-language facade over approved 1EdTech truth.

This architecture defines the Alpha surface for teachers, students, parents, and their LLMs. Alpha keeps the shared qti.* database and QTI 3.0 fidelity intact, then changes only what the Alpha audience genuinely needs changed: cuts, restrictions, renames, and extensions with stable ITD anchors.

Alpha Architecture Contract

Alpha exists so a student or parent can understand tests and test results from the bottom up, a teacher can import, deliver, inspect, and explain assessments, and an app-builder LLM can build against the API without becoming a QTI standards expert.

The contract is narrow: Alpha does not create a second QTI model. It is a customer-facing surface over the approved 1EdTech architecture, data dictionary, customer website, implementation, and surface QC.

Restrict: one shared qti.* persistence truth Rename: school vocabulary outside the database Cut: raw internals from public Alpha Extend: derived customer read models
Rule Alpha Consequence Upstream Anchor
Shared database Alpha reads and writes the same Supabase platform3 qti.* tables as 1EdTech. Alpha ITD-001; 1EdTech ITD-003
QTI stays QTI Alpha labels can say question, test, answer, result, and activity, but XML, object graph, validation, and export semantics remain the approved 1EdTech semantics. Alpha ITD-002; 1EdTech ITD-004
Every divergence is typed Any Alpha difference from 1EdTech must be one of cut, restrict, rename, or extend, with the audience constraint and alternatives documented. Alpha ITD-014
Students first Result and grading explanation views exist because students and parents need trustworthy score explanations, not raw QTI processing traces. Alpha ITD-009; 1EdTech ITD-024

Architecture Map

The Alpha surface is intentionally thin where QTI fidelity matters and thicker where customers need plain-language workflows.

Approved Upstream Truth

Alpha starts only after the 1EdTech QTI surface QC approved the upstream surface for Alpha. The upstream surface defines QTI persistence truth; this document defines only the Alpha changes on top.

Approved Artifact Canonical Input How Alpha Uses It
1EdTech Architecture platform3-avjryotuw... Source for shared persistence, XML authority, projections, sessions, attempts, validation, security, privacy, and hosted-doc identity.
1EdTech Data Dictionary platform3-198nmblg3... Source for every QTI table, field, type, range, allowed value, nullability, provenance label, and invalid-value rule.
1EdTech Customer Website platform3-fscem3woq... Source for the eight approved 1EdTech operations, authentication behavior, error behavior, and endpoint schemas.
1EdTech Implementation /loop/qti/artifacts/1edtech/implementation Executable contract Alpha implementation must call, wrap, or preserve over the same tables and behavior.
1EdTech Surface QC platform3-a3ocfthbe... Release-gate evidence that the upstream QTI surface is mutually consistent enough to become Alpha's upstream truth.

Alpha Change Ledger

Every Alpha divergence is one of the four allowed change types. Later Alpha data dictionary, customer website, and implementation work must link back to these ITDs instead of inventing new divergences.

ITD Type Change Audience Constraint Primary Upstream Trace
Alpha ITD-001RestrictAlpha must use shared qti.* persistence.One answer to disputes about content and results.1EdTech ITD-003, ITD-004, ITD-007
Alpha ITD-002RenameQTI terms get school-facing names.Customers think in school concepts.1EdTech ITD-006, ITD-011, ITD-015, ITD-016
Alpha ITD-003CutRaw internals are not public Alpha resources.Normal users cannot safely act on raw QTI internals.1EdTech ITD-005, ITD-013, ITD-014, ITD-017
Alpha ITD-004RestrictImport is validated assessment-package upload.Teachers need reliable import, not an XML workbench.1EdTech ITD-001, ITD-009, ITD-010, ITD-020
Alpha ITD-005ExtendContent catalog over artifacts and versions.Users must find content before using it.1EdTech ITD-005, ITD-011, ITD-012
Alpha ITD-006RestrictAuthoring saves are lossless versioned drafts.Friendly editing must not drop QTI fields.1EdTech ITD-006, ITD-011, ITD-020
Alpha ITD-007RenameDelivery sessions become activities.Students experience activities, not delivery JSON.1EdTech ITD-006, ITD-015, ITD-024
Alpha ITD-008RestrictAnswers must match QTI declarations.Students should not know QTI variable shapes.1EdTech ITD-013, ITD-016, ITD-020, ITD-021
Alpha ITD-009ExtendResult and grading explanation read models.Families need score explanations.1EdTech ITD-016, ITD-021, ITD-024
Alpha ITD-010Renamecandidate_ref is studentRef externally.Customers understand student data, not candidate data.1EdTech ITD-008, ITD-019, ITD-024
Alpha ITD-011CutPublic Alpha cannot run conformance jobs.Teachers should not trigger release-gate jobs.1EdTech ITD-017, ITD-018, ITD-019
Alpha ITD-012ExtendRead-only QTI trust status.Schools need confidence without raw assertions.1EdTech ITD-017, ITD-023
Alpha ITD-013RenameErrors become plain-language Problems.Users need fixable messages.1EdTech ITD-018, ITD-020, ITD-024
Alpha ITD-014ExtendAlpha provenance labels and links.Humans and LLMs need trustworthy friendly docs.1EdTech ITD-007, ITD-018, ITD-023

ITD Index

  1. Alpha ITD-001: Shared QTI Persistence, Alpha Facade
  2. Alpha ITD-002: School Vocabulary Layer
  3. Alpha ITD-003: Cut Raw QTI Internals From Public Alpha
  4. Alpha ITD-004: Restricted Assessment Package Import
  5. Alpha ITD-005: Content Catalog Read Model
  6. Alpha ITD-006: Lossless Authoring Commands
  7. Alpha ITD-007: Activity Delivery Language
  8. Alpha ITD-008: Declaration-Checked Answers
  9. Alpha ITD-009: Results And Grading Explanations
  10. Alpha ITD-010: StudentRef Privacy Language
  11. Alpha ITD-011: Cut Public Conformance Runner
  12. Alpha ITD-012: Read-Only QTI Trust Status
  13. Alpha ITD-013: Plain-Language Problems
  14. Alpha ITD-014: Alpha Provenance Requirements

Important Technical Decisions

Each ITD is written as a downstream contract. If a later data dictionary, customer website, or implementation needs behavior not covered here, the loop should roll back to Alpha architecture instead of inventing it later.

RestrictUpstream: 1EdTech ITD-003, ITD-004, ITD-007, ITD-023

Alpha ITD-001: Shared QTI Persistence, Alpha Facade

Audience constraint. Students, parents, teachers, and app-builder LLMs need plain objects, but administrators and support staff still need one durable source of truth when results or content are disputed.

Decision. Alpha is a facade over the approved 1EdTech qti.* persistence model. It may expose friendlier resource names and derived views, but it must not create a second QTI database model.

Trace. All 13 approved qti.* tables; approved 1EdTech architecture, data dictionary, implementation, and surface QC.

Alternatives and tradeoffs

  • Fork Alpha into separate tables: friendlier schema at first, but two sources of truth for scores, content versions, and support disputes.
  • Expose 1EdTech unchanged: maximally faithful, but fails the Alpha audience that needs school concepts first.
  • Use only document views with no relational trace: convenient for API reads, but weakens the deep data dictionary requirement.

Why this is simplest. A facade gives Alpha language without duplicating persistence or weakening QTI fidelity.

Downstream rules

  • The Alpha data dictionary maps every object and field to an approved qti.* source or to a declared derived field with this ITD as provenance.
  • No alpha.qti_* persistence tables are introduced by this QTI Alpha architecture attempt.
  • Implementation must wrap or preserve the approved 1EdTech repository contract over the same database.
RenameUpstream: 1EdTech ITD-006, ITD-011, ITD-013, ITD-014, ITD-015, ITD-016

Alpha ITD-002: School Vocabulary Layer

Audience constraint. The Alpha audience thinks in questions, tests, passages, answers, scores, feedback, activities, and results, not artifacts, candidates, response declarations, outcome variables, or processing traces.

Decision. Rename external Alpha resources and documentation labels into familiar school terms while keeping canonical 1EdTech names visible in provenance, advanced details, and implementation mappings.

Alternatives and tradeoffs

  • Keep QTI names everywhere: accurate, but makes Alpha unusable for students and families.
  • Hide QTI names completely: friendly, but app-builder LLMs and support engineers lose traceability.
  • Invent broad education-platform names such as assignments and gradebook: familiar, but belongs to later OneRoster or product modules, not QTI.

Why this is simplest. A visible rename map lets Alpha lead with school terms while preserving exact upstream truth.

1EdTech/QTI TermAlpha TermStorage Does Not Change
content_packageAssessment packageqti.content_package, qti.package_resource, qti.package_file
artifactContent itemqti.artifact
artifact_kind = item/test/section/stimulusQuestion/test/test section/passageqti.artifact.artifact_kind
artifact_versionContent versionqti.artifact_version
delivery_jsonStudent viewqti.artifact_version.delivery_json
delivery_sessionActivityqti.delivery_session
candidate_refstudentRefqti.delivery_session.candidate_ref
attempt, response_state, outcome_stateAnswer submission, answers, resultsqti.attempt
processing_traceGrading explanationqti.attempt.processing_trace
CutUpstream: 1EdTech ITD-005, ITD-009, ITD-013, ITD-014, ITD-017, ITD-018

Alpha ITD-003: Cut Raw QTI Internals From Public Alpha

Audience constraint. Learners, families, and teachers cannot safely work from package bytes, component rows, processing-rule trees, object graphs, or raw conformance assertions as their normal entry point.

Decision. Cut raw package-file, component-tree, variable-declaration, processing-rule, object-graph, and assertion-row endpoints from the public Alpha surface.

Trace. Cut public resources include qti.package_file.content_bytes, generic qti.component rows, generic qti.processing_rule rows, qti.artifact_version.object_graph, and generic qti.conformance_assertion browsing.

Alternatives and tradeoffs

  • Expose every row with friendly labels: complete, but pushes standards internals into ordinary workflows.
  • Delete these internals from the system: simpler API, but breaks round-trip preservation, scoring, validation, and compliance.
  • Expose only static docs for internals: safe, but app-builder LLMs still need provenance links from friendly fields.

Why this is simplest. Alpha can hide internals from public workflows while linking advanced users to the 1EdTech data dictionary.

Downstream rules

  • Alpha data dictionary labels these objects as backstage upstream internals, not missing data.
  • Implementation must not ship a generic Alpha row browser over raw QTI internals.
  • The customer website links advanced readers to the 1EdTech data dictionary for raw internal details.
RestrictMaps to: ingestContentPackage

Alpha ITD-004: Restricted Assessment Package Import

Audience constraint. Teachers and app-builder LLMs need a dependable import command, not a standards workbench with every possible XML entry path and profile switch exposed first.

Decision. Alpha import is assessment-package upload with tenant authorization, idempotency, QTI 3.0 validation, package closure checks, and friendly import status. It maps to ingestContentPackage.

Alternatives and tradeoffs

  • Allow arbitrary raw XML writes: flexible for experts, but too easy to bypass package closure, idempotency, and validation.
  • Only let internal staff import content: safe, but blocks teacher and app-builder workflows.
  • Expose every profile knob: powerful, but turns Alpha back into a 1EdTech expert surface.

Why this is simplest. One validated import command preserves QTI rigor and gives teachers a clear workflow.

Downstream rules

  • Responses summarize package status, content created, and validation problems without requiring IMS manifest knowledge.
  • Package bytes, hashes, resource identifiers, and validation diagnostics remain stored in approved package tables.
  • Invalid content fails with a plain-language Problem that still links to the underlying validation source.
ExtendNew Alpha operations: listContent, getContent

Alpha ITD-005: Content Catalog Read Model

Audience constraint. Teachers, families, and app-builder LLMs need to find a question, test, passage, or version before they can deliver, inspect, edit, or explain it. The 1EdTech surface starts from exact artifact-version IDs.

Decision. Extend Alpha with a content catalog over qti.artifact, qti.artifact_version, selected qti.component values, and package source metadata.

Alternatives and tradeoffs

  • Require exact artifact IDs: simple implementation, but poor customer findability.
  • Create a separate search index as persistence truth: faster search later, but premature for this QTI architecture and risks drift.
  • Expose package manifests as the catalog: faithful to IMS, but teachers search for tests and questions, not manifest resources.

Why this is simplest. A deterministic read model from approved tables gives findability without adding a second store.

Downstream rules

  • Catalog fields include school-friendly kind, title, language, latest version, package source, and safe summary metadata.
  • Search and filters must be deterministic from approved stored fields; ranking extensions require a later ITD.
  • Catalog summaries do not expose learner data, package bytes, auth metadata, or processing trace.
RestrictMaps to: saveAuthoringJson, exportXml

Alpha ITD-006: Lossless Authoring Commands

Audience constraint. Teachers and LLMs can author with friendly draft language, but the platform cannot let friendly editing silently drop QTI fields needed for export, scoring, accessibility, or compliance.

Decision. Alpha authoring saves are lossless editing-draft commands that create immutable content versions. Alpha keeps authoring_json lossiness none and If-Match concurrency.

Alternatives and tradeoffs

  • Let Alpha edit only selected friendly fields: easy UI, but loses QTI round-trip guarantees unless every omitted field is carried forward.
  • Make Alpha authoring raw QTI JSON: faithful, but too technical for the audience.
  • Overwrite latest content in place: simple writes, but corrupts historical sessions and results.

Why this is simplest. Friendly draft commands can still use the approved lossless authoring projection and immutable versioning.

Downstream rules

  • Alpha editing payloads must be marked lossless before creating qti.artifact_version rows.
  • Missing or stale preconditions fail; no Alpha save overwrites content in place.
  • QTI XML export remains available as an advanced portability command, not the ordinary authoring path.
RenameMaps to: getDeliveryJson, startDeliverySession

Alpha ITD-007: Activity Delivery Language

Audience constraint. Students and parents experience a learning activity or test session, not a delivery-session row with a delivery-json snapshot.

Decision. Rename delivery-session workflows to activities and student views. Activity creation still pins immutable content versions and snapshots generated delivery projection exactly as 1EdTech requires.

Alternatives and tradeoffs

  • Expose delivery JSON and sessions unchanged: precise, but not student or parent readable.
  • Generate a student view directly from latest content on every read: simple display, but historical attempts could change after edits.
  • Store a second Alpha activity document as truth: flexible, but duplicates the approved session snapshot model.

Why this is simplest. Activity language changes the front door while preserving the approved snapshot behavior.

Downstream rules

  • Activity responses include the content version so families can understand why later edits do not change past sessions.
  • The student view derives from qti.artifact_version.delivery_json and keeps declared lossiness visible to app-builder LLMs.
  • Displayed lifecycle words map back to qti.delivery_session.status.
RestrictMaps to: submitAttempt

Alpha ITD-008: Declaration-Checked Answers

Audience constraint. A student or teacher can provide answers, but cannot be expected to know QTI cardinality, base-type, response declaration identifiers, or variable shape errors.

Decision. Alpha answer submission is restricted to declared answer slots generated from qti.variable_declaration. Friendly payloads translate into QTI response variables only after cardinality and base-type validation.

Alternatives and tradeoffs

  • Accept arbitrary response JSON: flexible, but pushes QTI shape errors into scoring and creates confusing failures.
  • Hard-code answer schemas by interaction type: easier documentation, but drifts from the imported QTI declarations.
  • Only expose raw variable identifiers: faithful, but unfriendly for students and teachers.

Why this is simplest. Generate the answer contract from the same declarations the QTI runtime already uses.

Downstream rules

  • Alpha answer schemas are generated from stored QTI declarations for the delivered content version.
  • Invalid answer shape fails before processing and returns a plain-language problem with canonical variable identifier metadata.
  • Alpha must not silently coerce answers into a different QTI base type or cardinality.
ExtendNew Alpha operation: getActivityResult

Alpha ITD-009: Results And Grading Explanations

Audience constraint. Students and parents need to understand the score, feedback, and what happened in grading; raw outcome_state and processing_trace are too technical and can expose unnecessary implementation detail.

Decision. Extend Alpha with result and grading-explanation read models derived from qti.attempt response state, outcome state, status, timestamps, and privacy-redacted processing trace.

Alternatives and tradeoffs

  • Return raw attempt state only: complete for engineers, but not useful to families.
  • Store a separate score table as truth: easy reporting, but premature and risks divergence from QTI outcomes.
  • Hide processing trace completely: safer, but weakens explainability when a score is challenged.

Why this is simplest. A derived read model explains outcomes while keeping the attempt row and trace as the audit source.

Downstream rules

  • Result summaries state content version, submitted time, outcome variables used for scores, and whether scoring completed, failed, or was voided.
  • Grading explanations are derived views, not replacements for processing_trace.
  • Explanations redact learner PII, tokens, headers, IP addresses, raw PNP records, and direct identity fields.
RenameMaps to: candidate_ref and deleteCandidateRuntimeData

Alpha ITD-010: StudentRef Privacy Language

Audience constraint. Parents and teachers understand student data, not candidate runtime data. At the same time, the platform must avoid direct student PII in QTI runtime records.

Decision. Rename candidate_ref to studentRef in Alpha while preserving the 1EdTech privacy rule: the value is an opaque tenant-scoped pseudonymous UUID, not a name, email, SIS ID, JWT subject, or contact detail.

Alternatives and tradeoffs

  • Call it candidateRef in Alpha: technically aligned, but confusing for parents and teachers.
  • Use real student identifiers directly: convenient joins, but violates the learner-data privacy decision and increases breach impact.
  • Invent a full identity model in QTI Alpha: tempting, but belongs to OneRoster or identity modules, not QTI.

Why this is simplest. Rename the handle while keeping the pseudonymous storage rule unchanged.

Downstream rules

  • Alpha docs must say studentRef is not the student's legal identity.
  • Alpha validation rejects direct PII in studentRef and sanitizes Problem details.
  • Deleting student test data removes learner-runtime rows for the scoped pseudonymous reference and leaves reusable content intact.
CutCuts public operation: runConformance

Alpha ITD-011: Cut Public Conformance Runner

Audience constraint. Teachers, students, parents, and normal app-builder LLMs should not trigger standards conformance jobs while trying to teach, learn, or inspect results.

Decision. Cut POST /qti/conformance-runs from the public Alpha API. The runner remains part of the approved 1EdTech implementation and release process.

Alternatives and tradeoffs

  • Expose the runner publicly with role checks: possible, but makes a release-gate job look like a customer workflow.
  • Remove conformance from platform3 entirely: simpler API, but breaks the approved 1EdTech evidence chain.
  • Let Alpha run conformance asynchronously without showing details: hidden operational complexity for no student or teacher benefit.

Why this is simplest. Keep conformance execution where it belongs: 1EdTech/internal release tooling.

Downstream rules

  • Alpha customer website must not present conformance execution as a normal user action.
  • Operational or compliance agents that need to run conformance use the 1EdTech surface or internal release tooling.
  • Alpha implementation must not route public Alpha tokens to the conformance runner.
ExtendNew Alpha operation: getQtiTrustStatus

Alpha ITD-012: Read-Only QTI Trust Status

Audience constraint. Schools and app-builder LLMs still need to know whether the QTI engine is backed by current evidence, but they need an answer, not raw assertion tables.

Decision. Extend Alpha with read-only trust status derived from qti.conformance_run, qti.conformance_assertion, approved upstream URLs, and surface QC.

Alternatives and tradeoffs

  • Expose raw assertion rows: transparent, but too technical and noisy for Alpha.
  • Only say "compliant" in docs: easy, but not tied to evidence or freshness.
  • Move conformance evidence out of the database: simpler user API, but contradicts approved 1EdTech persistence.

Why this is simplest. A read-only summary gives confidence while preserving the approved evidence chain.

Downstream rules

  • Trust status includes last run status, bundle hash, runner version, and links to approved upstream documentation.
  • Failed or stale conformance evidence must remain visible.
  • Raw assertion drilldown requires a later Alpha ITD or the 1EdTech/internal surface.
RenameUpstream: 1EdTech ITD-018, ITD-019, ITD-020, ITD-024

Alpha ITD-013: Plain-Language Problems

Audience constraint. A teacher or parent can act on "this answer has the wrong shape" or "this package is missing a file" faster than on QTI schema, processing, or package-closure jargon.

Decision. Rename externally visible Alpha validation and error messages into plain-language Problem responses while preserving HTTP status, stable problem type, invalid parameter paths, and upstream QTI/source trace links.

Alternatives and tradeoffs

  • Return raw validator errors only: precise, but not fixable for normal customers.
  • Hide technical details completely: friendlier, but support and LLM repair lose traceability.
  • Downgrade many validation failures to warnings: smooth UX, but weakens QTI fidelity.

Why this is simplest. One Problem envelope can hold plain text, safe details, and upstream trace metadata.

Downstream rules

  • Problem.detail must be safe for users and must not contain package bytes, tokens, headers, IP addresses, raw PNP records, or direct learner identity fields.
  • Advanced metadata may include QTI identifiers, variable names, schema file names, and architecture/data-dictionary links.
  • Alpha must not translate hard rejection behavior into warnings.
ExtendSource for downstream Alpha dictionary and website

Alpha ITD-014: Alpha Provenance Requirements

Audience constraint. LLMs and humans need the friendly Alpha layer to be trustworthy enough to build from without guessing where the underlying 1EdTech truth lives.

Decision. Extend the data-dictionary and customer-website contract so every Alpha object, field, endpoint, status, enum, and behavior links to its Alpha ITD and to the approved 1EdTech table, field, operation, or ITD it depends on.

Alternatives and tradeoffs

  • Trust prose without source links: faster to write, but unusable for an AI-maintained platform.
  • Only link endpoint pages, not fields: better than nothing, but field-level invalid values become ambiguous.
  • Duplicate the whole 1EdTech dictionary in Alpha docs: complete, but bury the Alpha changes under standards detail.

Why this is simplest. Field-level provenance lets Alpha be friendly without becoming untraceable.

Downstream rules

  • Alpha data dictionary entries carry one of: 1EdTech pass-through, Alpha rename, Alpha restriction, Alpha cut, or Alpha extension.
  • Alpha customer website examples link back to the architecture ITD and data dictionary entry for every field or behavior they promise.
  • If an Alpha value cannot be traced to approved 1EdTech truth or one of these Alpha ITDs, implementation must stop and recommend rollback to architecture.

Alpha API Map

The operation names below are architecture-level contracts for the later Alpha customer website and implementation. They are not allowed to create new storage truth.

Alpha Operation Change Maps To Primary ITDs
importAssessmentPackageRestricted renameingestContentPackageITD-004, ITD-013
listContentExtensionqti.artifact, qti.artifact_version, selected qti.componentITD-005
getContentExtensionqti.artifact, qti.artifact_versionITD-005
getStudentViewRenamegetDeliveryJsonITD-007
saveContentDraftRestricted renamesaveAuthoringJsonITD-006
downloadQtiXmlRestricted renameexportXmlITD-006
startActivityRenamestartDeliverySessionITD-007, ITD-010
submitAnswersRestrictionsubmitAttemptITD-008
getActivityResultExtensionqti.attempt, qti.delivery_session, qti.artifact_versionITD-009
deleteStudentTestDataRenamedeleteCandidateRuntimeDataITD-010
getQtiTrustStatusExtensionqti.conformance_run, qti.conformance_assertion, 1EdTech surface QCITD-011, ITD-012

Public Alpha intentionally has no runConformance mutation, no raw package byte endpoint, no generic object-graph endpoint, and no generic processing-rule endpoint.

Data Dictionary Generation Rules

The Alpha data dictionary comes next. It must be generated from this architecture and the approved 1EdTech data dictionary, not from implementation taste.

Label When To Use Required Links
1EdTech pass-through The Alpha field is the same QTI/platform value with no Alpha change, even if the docs explain it in plain language. Approved 1EdTech table.field or operation.
Alpha rename Alpha changes the external name only, such as candidate_ref to studentRef. Alpha ITD and upstream table.field or operation.
Alpha restriction Alpha narrows allowed payloads, roles, or workflow paths while keeping upstream truth intact. Alpha ITD, upstream validation/security ITD, and affected fields.
Alpha cut Alpha deliberately omits an upstream internal object or operation from public Alpha. Alpha ITD and upstream object or operation that remains available elsewhere.
Alpha extension Alpha adds a derived read model or customer-facing summary from approved upstream data. Alpha ITD plus every source table.field and operation used to derive it.

Invalid dictionary behavior

  • A friendly Alpha field with no upstream source and no Alpha ITD is invalid.
  • A renamed field that hides its canonical QTI or qti.* source is invalid.
  • A result or grading explanation that cannot identify the source attempt, content version, and outcome variables is invalid.
  • An Alpha cut described as "unsupported" without saying where the upstream capability remains is invalid.

Non-Goals And Residual Risks

Non-goals

  • No OneRoster identity, class roster, assignment, or gradebook model is invented in QTI Alpha.
  • No Caliper event stream is invented in QTI Alpha.
  • No new QTI XML semantics, root elements, response-processing behavior, or conformance profile is introduced.
  • No direct learner PII is stored in qti.delivery_session.candidate_ref.
  • No second database or Alpha-specific persistence fork is introduced.

Residual risks for later deliverables

  • The Alpha data dictionary must decide the exact field list for content catalog and result views without adding untraced fields.
  • The Alpha customer website must make advanced QTI provenance reachable without making the first screen standards-heavy.
  • The Alpha implementation must avoid convenient shortcuts that bypass the approved 1EdTech repository, validation, or privacy checks.
  • Identity joins to real students should wait for the proper identity or OneRoster module instead of leaking into QTI runtime rows.

Source Use

This deliverable read the approved platform3 1EdTech artifacts first. It also inspected the prior external/qti workspace for reusable source material, especially the plain-English guide, conversion contract, runtime semantics, OpenAPI boundary, and ADRs.

Source Used For
Approved 1EdTech architecture traceabilityUpstream ITD references, table map, operation map, privacy rules, and hosted-docs contract.
Approved 1EdTech data dictionary JSONTable and field set Alpha must map to: 13 tables and 127 fields.
Approved 1EdTech customer website sourceEndpoint operation IDs, request/response contract themes, auth, errors, and workflow promises.
Approved implementation README and OpenAPIExecutable operation behavior and quickstart evidence for wrapping the 1EdTech surface.
Approved 1EdTech surface QC evidenceAuthority that the 1EdTech surface is approved to become Alpha upstream truth.
external/qti docs and ADRsHistorical rationale and plain-English vocabulary, adapted only where it agrees with platform3 truth.

Machine-readable traceability is available at alpha-architecture-traceability.json.