Why the platform works this way
Project decisions
AIPLA is not simply a chatbot with physics content. Its present shape comes from a series of choices about classroom practice, teacher control, privacy, research, and maintainability.
This page records the decisions that materially affect the public experience. It is a readable companion to the detailed engineering records: it explains the choice, why it was made, and what follows from it. Decisions may be revised as classroom evidence and institutional requirements develop.
May 2026: students join as groups
Decision: the classroom path uses a teacher-issued group code rather than asking every student to create a personal AIPLA account.
Why: physics work is often collaborative, shared devices are realistic in classrooms, and collecting identities would add friction and privacy obligations without being necessary for the learning activity.
Consequence: the group is the working unit. Teachers and researchers review authorised group sessions, not personal student profiles. Research use still depends on the applicable study information, consent, and governance.
May 2026: tutor and workbench form one activity
Decision: conversation and an interactive workbench are designed as connected parts of a learning activity.
Why: a generic chatbot beside a silent simulation does not know what the students tested. Conversely, a simulation alone does not prompt prediction, comparison, or explanation.
Consequence: relevant workbench actions can be shared with the tutor in a structured way, and the interface shows students what was shared. The tutor can respond to actual activity state without pretending to see more than it has received.
May 2026: interactive artefacts are isolated and reviewed
Decision: simulations and other HTML workbenches run through a versioned, isolated delivery path and are reviewed before use as maintained artefacts.
Why: interactive code may come from rapid prototyping or external contributors. Rendering successfully is not evidence that it is safe, pedagogically suitable, accessible, or scientifically correct.
Consequence: an artefact can evolve independently of an activity, but publication is a deliberate step. The same open bridge also allows selected artefacts to work in compatible external AI hosts.
June 2026: teachers approve AI-proposed changes
Decision: teacher-facing co-pilots propose changes; the teacher explicitly applies them.
Why: activity design is a professional and pedagogical responsibility. AI can accelerate drafting and organisation without silently becoming the author or changing a live class configuration.
Consequence: proposed classes, activities, curriculum links, or edits remain visible and reversible until the teacher accepts them.
June 2026: activities are reusable resources
Decision: activities can be previewed, reused across classes, shared, adopted, duplicated, and branched with provenance.
Why: a good learning design should not be trapped inside one class record, and adaptation should not erase where it came from.
Consequence: teachers can build on each other's work while retaining their own editable copy and a traceable relationship to the source.
June 2026: authoring uses bounded building blocks
Decision: teachers compose activities from maintained elements such as checklists, tables, charts, calculators, notes, documents, solution fields, and reviewed simulations.
Why: bounded elements are easier to preview, test, review, make accessible, and interpret during a session than arbitrary generated interface code.
Consequence: AI-assisted authoring can arrange and configure known elements. New element types require product and technical work rather than appearing invisibly through a prompt.
June–July 2026: research review is separate and summary-first
Decision: teacher and approved researcher views are distinct, and session review begins with summaries and structured activity evidence rather than only raw transcripts.
Why: teachers need a usable view of classroom activity, while cross-class research has different authorisation and analysis needs. Long chat logs alone are difficult to interpret and can hide how the workbench was used.
Consequence: role boundaries are enforced in the application, and summaries, workbench events, build versions, and source context can support review. A technical role never replaces study approval or data-governance requirements.
July–August 2026: releases move through environments
Decision: application changes are built and tested before promotion through development, test, and production environments.
Why: research-facing software needs a reproducible account of what participants used, while classroom deployments need controlled changes and a recovery path.
Consequence: feature availability may differ between environments. Public capability descriptions identify what has shipped but do not imply that every feature has completed classroom evaluation.
September 2026: the public project site is part of the application
Decision: the project's public pages are maintained in the application repository and served from the authoritative aipla.ku.dk domain, replacing the separate website used during the earlier phase.
Why: a project website that lives apart from the product drifts from it. Keeping the public explanation next to the code means a change to the platform and the change to how it is described can be reviewed together, and the pages inherit the same review, accessibility, and deployment checks as the rest of the application.
Consequence: each public page carries an owner, a status, and a review date, and a page whose review has lapsed fails the build rather than quietly ageing. The former site remains reachable until its redirects are enabled, so older external links may still resolve to the previous address.
September 2026: a tutor's teaching approach is published data
Decision: a tutor carries its teaching approach — the individual teaching moves, what it should avoid, and the published research each comes from — as structured data that approved researchers can edit in the application, rather than as a hidden prompt.
Why: a tutor's behaviour should be reviewable by teachers and education researchers, not only by engineers. Holding the approach as data makes it possible to compare what the tutor is told to do with the research it claims to follow.
Consequence: the approaches are published on Teaching frameworks. Teachers choose the tutor for a class and can define their own approaches. An approach also sets how much a tutor may change a simulation during an activity, and any such change is shown to the students.
September 2026: programme-level administration and usage limits
Decision: administrative roles for operating the service are separated from teaching roles, and the programme sets a daily usage limit across all classes.
Why: granting access and managing the cost of AI services are operational responsibilities, not teaching ones, and they should not be bundled into a teacher account. The limit was introduced in a warning-only mode so that its level could be set from real use before it restricted any class.
Consequence: access grants and programme-level limits are held by named project staff. Since October 2026 the daily limit is the platform-wide ceiling: once reached, further tutor use pauses until the next day. Usage limits are a budgeting control and are not a research or data-governance measure, which remain separate.
October 2026: model inference stays in the EU
Decision: the tutor's model requests are sent to Vertex AI's EU multi-region endpoint rather than its global endpoint.
Why: the global endpoint may serve a request from any region, and the University of Copenhagen's data-protection review requires inference within the EU. No single EU region currently serves the models the tutor uses; the EU multi-region endpoint does.
Consequence: the change applies to all three environments. It also moved the platform's spending ceiling from a cloud-provider quota to the programme's own daily limit, described above. The current position is maintained on Data, privacy, and hosting.
October 2026: teachers can publish their own simulations
Decision: a teacher who has been given access can build a simulation in the application with an AI assistant and publish a checked version to their own classes, as its reviewer for those classes. A teacher-built simulation reaches the shared library only after a researcher has signed off its physics.
Why: a teacher can judge whether a simulation suits their own class, but a simulation offered to every teacher needs its physics checked by someone other than its author. Rendering successfully, or passing automated checks, says nothing about whether the physics is right.
Consequence: every version is checked automatically for size, security, phone width, and whether it passes the student's readings to the tutor, and a teacher-built simulation runs with no network access. The teacher records their approval of the exact version students will get. Access is switched on per teacher by the research team. The earlier route, drafting a simulation in an outside AI chat and sending it to the project team, remains open.
October 2026: the activity says what to learn, the tutor's approach says how to teach
Decision: when a class's tutor has a teaching approach, that approach decides how the tutor teaches; the activity's teaching goal says what the students should learn.
Why: nothing previously told the tutor which of the two governed how to teach, so a teaching goal that also gave teaching instructions was blended with the approach. That makes it harder to check a tutor against the approach it claims to follow, and it is a likely reason different tutors could read alike in real lessons.
Consequence: the tutor is told which instruction decides how to teach. When a teaching goal contains lines about tone, hints, a character, or whether to give answers, the activity builder points them out and offers to move them to separate tutor notes, which the tutor follows only when it has no teaching approach.
Hosting direction
Decision: use managed cloud services for the current phase while keeping replacement seams and institutional hosting requirements explicit.
Why: the project needs a reliable pilot platform now, but long-term operation, identity, storage, analytics, and model access must be reviewed with the University of Copenhagen.
Consequence: portability is a design goal rather than a promise of effortless migration. The current position is maintained on Data, privacy, and hosting.
How this record will evolve
The team will add a dated entry when a decision changes the public platform, study experience, or long-term operating model. Routine implementation detail remains in the repository. Decisions that are still exploratory will be labelled provisional rather than written as settled facts.
- Content status
- Current
- Maintained by
- AIPLA project team
- Last reviewed
- Next review