Platform Requirements

01 — Context

Background & Context

RISE is an AI-powered interview-coaching platform that lets students practise job interviews in a realistic, structured setting and receive immediate, rubric-based feedback in their own language. Educators use the same platform to follow each student's progress and tailor their guidance. This PRD is created based on the ERASMUS+ project specification “KA210-VET — Small-scale partnerships in vocational training (KA210-VET)”.

Following the accepted proposal, Tehnička škola has engaged Zoran Krnetić, operating through the legal entity PR BRIGHTNESS, to design, build, and deliver the platform within a three-month implementation window. This document is the agreed scope of work and the basis for acceptance.

Engagement structure

Three delivery months, with a real-world testing window between the first two.

02 — Objectives

Goals & Success Criteria

03 — Users

Personas

04 — Plan

Delivery Plan

Month 1 Core Platform Weeks 1–4

Delivers the complete interview-practice loop end to end (scope in §6). Exit checklist:

• Student can log in, choose a scenario, complete an interview, and read a final summary.
• Teacher can log in and review completed sessions.
• Interview content is authored in a spreadsheet and imported into the database (no code change to add a scenario).
• AI feedback is rubric-based, structured, and multilingual (Serbian, English, French, Portuguese).
• Platform deployed for the pilot on a server owned and paid for by Zoran Krnetić.

Pilot Testing window

• Project participants provide real test subjects (students and at least one teacher).
• Test subjects run live sessions against the Month-1 platform on staging.
• The vendor collects: completion rates, feedback-quality observations, usability issues, language-quality issues, device/browser issues, and an in-session satisfaction signal.
• Findings are triaged and feed the Month-2 backlog.

Month 2 Launch Preparation Weeks 5–8

Brings the platform to launch readiness and delivers the items in §7, prioritised by pilot findings:

Exit: §2 acceptance criteria fully met on the vendor's staging server, pilot findings incorporated, platform launch-ready.

Month 3 Launch & Post-Launch Support Weeks 9–12

Takes the launch-ready platform live and stabilises it in real-world use.

• Production go-live.
• Migration of content and accounts to production.
• Monitoring during the initial weeks of real use.
• Post-launch bug fixes and minor adjustments arising from live operation.
• Final handover: admin guide, content-editing guide, account guide.

Exit: platform live on production infrastructure, post-launch issues resolved, handover complete.

05 — Technology

Architecture & Technology

React / Vite Frontend
        ↓
Node.js / Express Backend  ──→  Together.ai (Qwen)   (AI feedback)
        ↓
   PostgreSQL   ◀── offline import ──  Google Sheets   (content authoring)

06 — Scope

Month 1 Scope — Core Platform

6.5 Content (initial bank)

Initial scenarios delivered for two professions, multilingual (Serbian, English, French, Portuguese):

The content schema supports adding further professions, sectors, and difficulty levels without code changes; expanding the bank is a content task for school staff — edit the sheet and re-import.

6.6 Data model (core)

users, interview_sessions, interview_messages, answer_feedback — persisted in PostgreSQL with full interview history, scores, and AI output retained per session and attempt.

07 — Scope

Month 2 Scope — Launch Preparation

The work that brings the platform to launch readiness: compliance, accessibility, analytics, and the tooling needed to operate it with real students at scale.

08 — Quality

Testing & Pilot Approach

1. Internal verification (Month 1). Tests of the student and teacher flows on staging.
2. Pilot (between months). Real test subjects supplied by the project participants run live sessions. Instrumentation from §7.8 collects quantitative measures; the vendor collects qualitative usability, language-quality, and device findings.
3. Triage. Findings categorised (blocker / important / minor) and scheduled into Month 2.
4. Acceptance verification (Month 2). Re-run pilot scenarios against the launch-ready build; confirm every §2 acceptance criterion and that pilot findings are resolved.
5. Production verification & stabilisation (Month 3). Smoke-test the production deployment on Marabunta's infrastructure after go-live; monitor real use and resolve post-launch issues.

09 — Outputs

Deliverables

10 — Boundaries

Out of Scope

The following are explicitly not part of this three-month engagement (candidates for a possible future phase):

11 — Dependencies

Assumptions & Dependencies

• Test subjects for the pilot are provided by the project participants on the agreed schedule; delays here might move the project's completion.
• The school confirms the minors' age threshold and parental-consent process to adopt.
• Hosting (VPS, domain, TLS) and LLM expense are provided / funded by the client after project finalization.
• The school nominates an administrator for content editing and account provisioning, and attends handover.
• Final KPI list (5–8 metrics) is agreed before the pilot begins.

12 — After acceptance

Beyond the Engagement

Everything below was built after the scope above was accepted, between August and September 2026. It is recorded here so the difference between what was contracted and what exists is visible, rather than blurred by editing the sections above.

The platform serves three schools, not one

This document was written for a single school. The platform now serves Tehnička škola Zrenjanin, Lycée Professionnel Jacques Le Caron and AEVA in one system, separated from each other.

• A teacher sees only students of their own school, and only their own class groups where a school chooses to use them. Before this, every teacher could read every student’s answers across all three partners.
• Each school has its own interview content — 12 Serbian, 19 Portuguese and 224 French scenarios — so a student no longer scrolls past another country’s trades to find their own.
• A platform administrator role provisions schools and invites their first administrator. It sits outside every school and cannot read student data; no endpoint exists that would return any.
• A school can be suspended, which blocks sign-in for its members immediately and touches no data.

Content moved into the platform’s own database

Spreadsheets remain the authoring surface; the platform no longer reads them while a student is interviewing.

• Editing a spreadsheet changes nothing until it is imported. An accidental edit can no longer reach a class mid-lesson.
• Content is versioned, and every interview records the version it was taken against. Deleting a question can no longer make a completed interview unreadable — which it previously did, silently.
• A bad import is undone by putting the previous version back, rather than by reconstructing a spreadsheet from memory.
• An outage at the spreadsheet provider can no longer stop an interview.

Data protection, built rather than promised

• Privacy notices in the platform, versioned in source control, with separate texts for students and staff — a teacher writes no interview answers, so almost none of the student notice applies to them.
• A person downloads their own data themselves, immediately. It is not a request and no member of staff handles it.
• No administrator, at either level, can read or export a student’s transcript. The only people who can are that student and teachers at their own school. This is enforced by the absence of any endpoint that would produce it.
• Every staff read of a student’s record is recorded — who, what, when — and the record survives the deletion of the account it describes.
• Erasure requests are a queue with a due date rather than an email, because Article 12(3) starts a one-month clock and an inbox has neither a due date nor evidence.
• A data protection impact assessment and a pack of transfer documents were drafted for the three schools’ own lawyers.

Measurement and content quality

• Per-criterion scores are stored as data, so the project’s reporting is a query rather than a program that reads prose.
• Every interview opens on the candidate — a self-presentation question — rather than on whichever trade question happened to be drawn first.
• A shortened interview keeps its breadth: five questions means one of each type, not the opener plus four technical.
• Content is retired, never deleted: a replaced question leaves circulation while every interview already taken on it stays readable.
• The French partner’s second content kit was imported — the French set went from 81 to 224 scenarios.

Operations

• A staging environment with its own database, so no change reaches students untested.
• Every call to the AI model is time-bounded, and a slow closing summary can no longer strand a finished interview.
• The administrator console is available in all four project languages.

Getting in, and getting locked out

• A forgotten password can be recovered without a member of staff. A single-use link, valid for an hour. The reply is identical whether or not the address has an account — a form that confirmed it would be a way of asking the platform which children are registered here.
  This is also why an account on an address that receives no mail — the @rise.local pattern used for pre-provisioned cohorts — has no self-service recovery. Worth settling before a large cohort is created that way.
• A teacher can invite their own students, and only students. The invitation carries no role at all: the field is absent from the schema, so a request that supplies one is stripped of it before any code sees it. Validating the value instead would have let a teacher create an administrator of their own school with nothing on screen looking different.
• An administrator can suspend an account, and bring it back. The middle option between leaving a departed student able to sign in and deleting everything they did. It destroys nothing — transcripts, scores and cohort membership all stay — and it takes effect immediately rather than whenever the person's cookie happens to expire. Both directions are audited; an account suspended and quietly restored is the shape of a mistake.

How much a student may take on

Three limits, set per school over a platform default. They are a cost ceiling as much as a pedagogical one: every answer is two calls to the language model, and a measured cohort of roughly 300 students is the first time this platform meets a bill that scales with enthusiasm.

• Attempts at one interview (default 3), interviews in total (default 15), and a waiting period between attempts at the same interview (default 7 days).
• The waiting period is counted per interview, from that interview's own last attempt. Starting the electrician interview on Monday says nothing about when the welder interview may be started.
• An interview counts from the moment it is started, finished or not — otherwise a student could open interviews without limit by never finishing one, which is both the expensive case and the useless one.
• Nothing can stop a student finishing what they opened. The limits are checked when an interview is created and nowhere else. A cap that could strand a half-finished interview would punish exactly the student who came back to it.

The school completes its own privacy notice

• Controller identity, the data protection officer, lawful basis, retention periods and supervisory authority are now filled in by each school, and the notice assembles its sentences from them in all four languages. Until this, every student who opened the notice read <placeholder> where their school's details should have been.
• Retention periods are a number and a unit, not a sentence. Typing "two years" into a box would have put those English words into the Serbian, French and Portuguese notices, invisibly to whoever typed it.
• A sentence keeps its visible "to be completed by your school" treatment only while it still has a blank in it. A filled one is ordinary prose — a notice visibly assembled from parts, with one part disowned by the school that sent it, is not what a fifteen-year-old should be reading.
• Whether the platform is compulsory is no longer a school setting. It is not coursework at any partner school, so the notice states that outright rather than promising an answer nobody had configured. Recorded here as a consortium decision so it is not re-opened as a setting: if a fourth school ever says otherwise, that is a change to the notice, not a form.
• A telephone number is optional everywhere. Article 13 asks for a way to reach the controller and the officer; it does not ask for a phone line, and a school without a switchboard should not be shown an error for saying so.

Somewhere to write when something breaks

• There was no support contact anywhere in the platform. Every dead end said "ask your teacher" — a person rather than a channel, which fails when the teacher is the one stuck, when it is Saturday, or when the fault is the platform's.
• Three destinations, kept apart deliberately: the school for who you are, the platform for what is broken, and the data protection officer for your data. One combined "contact us" address would route erasure requests into an IT inbox with a one-month statutory clock running and nobody there with the authority to answer.
• The platform's own address is read-only inside a school, for the same reason its default limits are: one address, answered by one team.

What the platform can count about itself

• The grant commits the final report to “quantitative data (e.g. user numbers, performance metrics)” and to key indicators showing measurable improvement. Nothing in the platform could produce any of it: there was no aggregate view at any level, and the only way to answer “how many interviews has Le Caron done” was to open a database console.
• Three sections, for both kinds of administrator. Activity — interviews started and completed, accounts, who actually practised. Utilisation — model calls, tokens, cost and the environmental figures, each recorded at the moment of the call rather than reconstructed afterwards. Progress — a student’s first completed interview against their most recent.
• A platform administrator sees every school; a school administrator sees only theirs. The scope is taken from the account, never from the request, so there is no parameter a school administrator could add to widen it.
• Still no transcripts, at any level. Everything these pages return is a count, a sum or a mean over a group. This is the same claim §7.1 rests on, and it holds only while the endpoints stay aggregate — a “drill down to the student” feature would quietly revoke it.
• Groups of fewer than five students are withheld rather than averaged. The pages carry no names, but an average over two students read by their own teacher is not anonymous. Withheld rows stay visible with their reason: a row that disappears becomes a zero in somebody’s chart. At current pilot sizes this is the ordinary case, not the exception — every per-school progress row is withheld today.
• Progress is reported as an indicator, not a finding. The comparison is first interview against most recent, same rubric and same model, and the page says on its face that students who improved may simply be those who kept practising, and that the model is scoring its own conversation. A report that quotes the number without the caveat is overstating it.
• The period selects which students are counted, not which of their interviews are compared. A student’s first interview is a historical fact that a date filter has no business moving, and scoring a week’s work against itself measures nothing.
• Export as five tables and a README, because activity, utilisation and progress have genuinely different shapes and one sheet holding all three cannot be pivoted. Semicolon-delimited with comma decimals, which is how all three partner countries write numbers. The caveats travel inside the file: a spreadsheet opened in six months has no warning box beside it.
• What it deliberately cannot show. The platform holds nothing about who a student is. The inclusion and disadvantage figures the application commits to, and any measure of confidence or satisfaction, come from the schools’ own records and the project surveys. This page is the quantitative half only, and the report needs both.

Still outstanding

Named here so this document is not read as a completion certificate. The current list lives in the work plan.

• Scheduled backups on the pilot host. The provisioning script now installs them — a daily dump kept for a fortnight, and an encrypted off-site copy once a bucket is configured — so a new installation has both from its first run. The pilot host predates that script and is still dumped by hand.
• Transfer clauses and the impact assessment between the schools, which need three sets of lawyers.
• Retention: the deletion job. The numbers are no longer outstanding — each school now sets its own and the notice publishes them. What is missing is the job that honours them: nothing expires today, so a period on that page is a promise the platform does not yet keep by itself.
• A school’s own support address. The platform’s address now has a real mailbox behind it, and mail goes through the school’s own server rather than a send-only service. What is missing is the schools: none has filled in its own contact, so students are shown the platform’s address for the questions — a password, a class, who they are — that only their school can answer.
• Migration to the project’s own infrastructure, and the sustainability plan the grant requires.
• Database-level tenant isolation as a backstop behind the application-level scoping that ships today.