Most people who end up running Uedu did not decide alone. They saw it at a conference, thought it might fit one course, and then had to explain it to a colleague, a head of department, or an IT office that had never heard of it. This handbook is the material for those conversations — what to say, what each level of adoption actually costs someone, and what the honest answer is when the answer is not flattering.
1. What adoption means here
Adoption on this platform is not a procurement event. There is no contract to sign, no licence to buy, no seat count, and no minimum term. A teacher can create a course this afternoon and have students in it tomorrow without anybody at their institution being involved or informed.
That is genuinely how most courses start, and it is worth saying out loud early in any conversation, because it changes what the conversation is about. You are not asking your institution to buy something. At most you are asking it to recognise something that is already running.
A platform hosted and maintained by a university research group, not a company. That is the source of both its advantages (free, open to research, willing to build what you need) and its limitations (no service-level agreement, no support contract, no sales engineer). Every chapter here follows from that one fact.
The scale it currently runs at
Useful when someone asks whether this is a prototype: 21 higher-education institutions, 4,400+ learners, 420,000+ learning interactions, and 19 peer-reviewed publications describing the work. Those are the only figures we use; if you see a different number in a slide deck, it is out of date. Link to the overview page rather than screenshotting the numbers, so what you circulate stays current.
2. The three-minute explanation
The version below is meant to be said out loud, not read. It is deliberately short on features and long on what makes it different, because the feature list is what people forget.
The question you will always get: "Isn't this just ChatGPT?"
It uses the same underlying models, so half the answer is yes. The honest distinction is three things a general chatbot does not do:
- It is bound to your course. It answers from the readings you uploaded and cites the file and page, so a student can check it against your material instead of trusting the model.
- It sits inside the coursework. The same place holds the quizzes, the worksheets, the forum and the recordings, so student work and student dialogue are in one record rather than two.
- It reports back on thinking, not usage. Cognitive-level analysis of dialogue across a semester is the thing the platform exists for, and it is what the published work is about.
Three framings that misfire
| Do not say | Because | Say instead |
|---|---|---|
| "It improves learning outcomes." | We do not make effect claims, and an audience with a methodologist in it will stop listening at that sentence. | "There are 19 peer-reviewed papers on what it does and does not do — here is the list." |
| "It's National Central University's system." | Uedu is developed independently by Chia-Kai Chang and adopted across institutions. No single institution owns it, and describing it as one institution's product creates problems for every other institution using it. | "It is developed by a researcher at NCU and used by 21 institutions." |
| "It replaces your LMS." | It does not, and IT offices hear that sentence as a migration project. | "It runs alongside whatever LMS you have. Nothing has to be switched off." |
3. Four levels of adoption
These are cumulative, and most institutions never go past level 1. Deciding which level you are actually proposing is the single most useful thing you can do before a meeting, because levels 0 and 1 need nobody's approval and level 2 needs a different kind of conversation entirely.
| Level | What it is | Who decides | Lead time |
|---|---|---|---|
| 0 — One course | You create a course, write the assistant, give students a six-character code. Nothing institutional happens. | You. Course approval is a platform-side check that you are the teacher, not an institutional decision. | Same day, once your course claim is approved. |
| 1 — A group of teachers | Several colleagues each run their own courses. You start comparing notes; someone usually becomes the informal contact point. | The teachers involved. | A semester, in practice — people join after seeing a colleague's course. |
| 2 — Institutional recognition | A branded entry point at yourschool.uedu.tw with your logo and name,
optionally with your course catalogue imported so teachers claim their own courses
instead of typing them in. |
Someone who can speak for the institution — a dean, a centre director, a teaching and learning office. | Days of platform work once the decision is made. The decision is the slow part. |
| 3 — Research partnership | A study designed on top of running courses, or analysis of de-identified data already collected. Co-authorship is the normal arrangement. | You and us. Your institution may separately require its own registration. | See the research handbook — the deciding factor is whether you are collecting anything new. |
A subdomain is a configuration change and a logo file on our side. It involves no integration with your systems, no single sign-on project, no data feed, and no server of yours. What it changes for the institution is visibility and credibility, not infrastructure — teachers see their own institution's name and mark, and it becomes something the institution can point at.
4. Who has to do what
The most common reason an adoption conversation stalls is that someone assumes there is an IT project hidden in it. At levels 0 and 1 there is no IT involvement of any kind.
| Level 0 | Level 1 | Level 2 | |
|---|---|---|---|
| You | Create an account, claim your course, write the assistant, hand out the code. | Same, plus answering colleagues' questions. | Same, plus being the named contact for the institution. |
| Your students | Create an account and enter a code. No installation, browser only. | Same. | Same, but they arrive at your branded entry point. |
| Your department | Nothing. | Nothing required. Usually wants to hear how it went. | Decides, and supplies a logo and the official institution name. |
| Your IT office | Nothing. No install, no server, no directory integration. | Nothing. | Nothing technical. Usually wants to review the governance documents — chapter 5. |
| Us | Verify you are the teacher of the course you claimed. | Same. | Configure the subdomain, add the logo, import the catalogue if you send one. |
5. What your IT office will ask
Answers you can forward. The authoritative versions are in the governance centre, which publishes the data-governance framework, privacy and retention policy, the sub-processor list, an ethics-approval summary and a cross-jurisdiction compliance matrix.
Traditional Chinese is the legally authoritative version, and English translations are only partly published. If your institution needs a formal English copy of a specific document to complete a review, ask and we will produce that document — it is a normal request and we would rather do it than have you paraphrase.
Where the data lives
- The application and database run on a server in the National Central University data centre in Taoyuan, Taiwan. Storage is local; large recordings sit on a lab NAS in the same facility.
- There is one production server, with a daily database backup. There is no multi-region failover.
- For collaborations involving European data subjects, model inference can be routed through Microsoft Azure OpenAI Service in Switzerland North or West Europe under Microsoft's EU Data Boundary commitment. The region is chosen jointly with the partner institution.
Who else processes student text
This is the question that matters most and is most often answered vaguely elsewhere, so plainly: when a student sends a message to the assistant, that message is sent to a model provider outside the platform. By default that provider is OpenAI in the United States.
- Zero Data Retention is enabled on our OpenAI API access: inputs and outputs are not retained beyond the immediate processing of each request, and are not used for model training.
- A course may instead use its own API key for OpenAI, Anthropic or xAI models, in which case usage is billed to that key and governed by that account's terms.
- Other sub-processors: Google, Apple and GitHub for optional third-party sign-in; Mailgun (EU region) for transactional email; Cloudflare for DNS and DDoS protection; Garmin, Apple HealthKit and Google Health Connect only where a user has explicitly connected a device.
- Third-party front-end assets are self-hosted rather than pulled from public CDNs. The one declared exception is the Pyodide WebAssembly runtime, downloaded only when a user triggers the opt-in code-execution feature.
Account security
- Two-factor authentication is mandatory for every teacher, teaching assistant and administrator account. It is not optional and other features are restricted until it is set up.
- Sign-in options are email and password, Google, Apple, GitHub, and passkeys (WebAuthn).
- Uploaded files are validated by content, not by file extension. Rendered user content is sanitised against a strict allow-list, and standard security headers including a content security policy are applied.
- Research exports are de-identified, encrypted, logged, and released only after the responsible teacher has signed a data-protection undertaking.
What we do not have
- No SOC 2, ISO 27001 or equivalent third-party security certification.
- No service-level agreement, no guaranteed uptime, no 24-hour support rota. Issues reach a small team by email.
- No single sign-on integration with institutional identity providers.
- No penetration-test report from an external firm.
If your institution's review process requires any of those as a hard gate, the honest answer is that the platform will not pass it today, and that a teacher-level (level 0) adoption — which requires no institutional review — may be the only route that works for you.
Privacy and sub-processor questions, including objections to a sub-processor change, go to [email protected].
6. What your dean will ask
| Question | Answer |
|---|---|
| What does it cost us? | Nothing at any level. See chapter 7 for what "free" is funded by and where its edge is. |
| What are we locked into? | Nothing. There is no contract and no term. If you stop, you stop; teaching materials you uploaded are yours and exportable, and students keep no obligation. |
| Who owns the student data? | Students' work and dialogue belong to the students. The platform holds it to provide the service, and only releases it de-identified through a single logged export route covered by a research-ethics protocol. Teachers see their own course; nobody sees another teacher's course. |
| Who owns the platform? | Chia-Kai Chang, Assistant Professor at the Center for General Education, National Central University, developed it and continues to develop it. Institutions adopt it; none of them owns it. |
| What happens if it goes away? | A fair concern and there is no way to make it disappear. The mitigations are real but partial: your uploaded material is exportable, your course data is exportable, and the platform has been running in production for years across 21 institutions. There is no escrow arrangement and no second operator. |
| Will our name appear anywhere? | Only if you agree to it. Institutional names appear on the platform when an institution has an entry point or has agreed to be listed. Tell us not to and we do not. |
| Are students forced to give up data for research? | No, and this is the one line the platform enforces on teachers as well: research participation is separate from course participation and never affects a grade. A student who declines or withdraws keeps full access to the course. See chapter 10 of the teaching handbook. |
| Does this let AI grade our students? | It can draft, and a teacher decides. Nothing generated — a quiz, a worksheet, a suggested score — reaches a student without the teacher publishing it. The platform's position on grading with AI usage data is in chapter 10 of the teaching handbook, and it is deliberately conservative. |
7. Cost, funding and what free means
"Free" is a funding arrangement, not a promise about the future, and it is better to say that to a dean yourself than to have them discover it.
| Item | Cost to you | Paid by |
|---|---|---|
| Accounts, courses, coursework tools, analytics, exports | None | The platform. There is no paid tier of the software. |
| Model usage on the free default model | None | Grant and donation-funded capacity. Finite, and shared across every course on the platform. |
| Advanced or third-party models (flagship OpenAI models, Anthropic, xAI) | Whatever your provider bills you | Your own API key, entered per course. Your key, your account, your usage. |
| Background analysis (cognitive-level classification, retrieval indexing) | None | The platform, always — never your key, even when your course uses one. |
A single course with a few hundred students on the free default model is routine. If you are planning to bring many hundreds of students at once, or a course designed around very heavy daily use, tell us before the semester rather than during it. The likely outcome is a suggestion that the course use its own API key — which is a budget line for your department, not a fee to us.
8. A pilot semester, week by week
One course, one semester, one honest report at the end is a better argument than any deck. Here is the shape that has worked.
Before the semester
- Pick the course that can afford to be a pilot. Not the flagship module being reviewed this year. Something you teach well and could adjust mid-semester.
- Write down what you expect to learn. One or two sentences, before you see any data. "I want to know whether students ask the assistant questions they would not ask me" is a good pilot question; "I want to see if it improves grades" is not answerable in one semester by one course.
- Decide the AI policy for your syllabus and write it down. Whether use is required, optional or graded, and how. Students should read it in week one, not infer it in week eight.
- Set up the course — see the teaching handbook. Budget an hour for the assistant's instructions and an hour for uploading readings.
Weeks 1 to 5
- Week 1: put the course code on a slide and give students five minutes in class to join. Adoption falls sharply if joining is homework.
- Week 2: read a sample of the dialogue yourself. This is the single most informative thing you will do all semester, and it usually changes the assistant's instructions.
- Weeks 3–5: look at the cognitive-level distribution once, not weekly. Early data is thin and over-reading it produces conclusions you will have to walk back.
Mid-semester
- Run a short in-platform survey — five questions is enough. Use the platform's own survey tool rather than an external form: it stays inside the same consent and governance arrangement.
- Write half a page for your department while it is fresh: what students actually used it for, what surprised you, what broke.
End of semester
- Export what you need for your own records before you stop thinking about the course.
- Answer the question you wrote down in step 2, including if the answer is "inconclusive". A pilot that honestly reports inconclusive is more persuasive to a sceptical colleague than one that reports success.
- Decide whether there is a research question worth pursuing. If so, the research handbook is the next thing to read — and note that anything you want to collect next semester needs lead time.
9. Materials you can reuse
| Material | Where | Good for |
|---|---|---|
| Overview page, in 16 interface languages | /international/teaching | The link you send. Always current, never needs re-editing. |
| Narrated overview video with captions | On the same page, narration selectable by language | Playing four minutes at the start of a department meeting. |
| Publications (19) | /practice | The evidence question, and anyone who wants to check a claim. |
| These three handbooks | /international/handbook | Forwarding to the specific person who has to decide something. |
| Governance documents | /governance | The IT office and anyone asking about data. |
Rules for reusing them
- Link rather than copy. Platform figures change; a screenshot in a deck becomes wrong silently.
- Do not add an effect claim we do not make. If a sentence about improvement is not in a published paper, it should not be on your slide with our name under it.
- Do not present it as any institution's product. See chapter 2.
- Flag features that are not shipped. The overview page keeps unreleased work in a separate labelled section for exactly this reason; keep that separation when you summarise.
10. What we ask in return
There is no fee, but there are things that make this sustainable, in descending order of how much we mean it:
- Honest feedback, including the unflattering kind. The failure modes are more useful than the success stories, and they end up in the papers and the tutorial materials rather than being hidden.
- Advance warning before scale. Hundreds of new students arriving unannounced in one week is a capacity problem that a two-line email a month earlier prevents.
- Permission to name your institution — optional, revocable, and refused without consequence.
- Research participation — entirely optional, for you and for every student. Declining changes nothing about your access to anything.
Exclusivity, a testimonial, a referral, an integration commitment, or a promise to keep using it. Stopping after one semester and telling us why is a perfectly good outcome.
11. Objections, answered honestly
| Objection | Honest answer |
|---|---|
| "We already have an institutional AI licence." | Then you already have model access, and the question is only whether the course-bound, coursework-integrated and analytic parts add anything. Often the useful answer is to run one course and compare. |
| "Students will use it to cheat." | They can, as with any model access they already have. What is different here is that the dialogue is visible to you and classified by cognitive level, so assessment can be designed around what the record shows rather than around a prohibition you cannot enforce. |
| "Our legal office will never approve a Taiwanese server." | Possibly true, and worth testing early rather than late. Model inference can be routed through an EU region for European collaborations, but the application and database are in Taiwan. If data residency is a hard requirement for your institution, say so at the first meeting and we will tell you plainly whether it can be met. |
| "It's free — so what's the catch?" | The catch is the absence of the things money buys: no SLA, no support contract, no certification, no guarantee about the future. Whether that is acceptable depends entirely on what you are putting on it. |
| "This is one person's project." | It is one person's platform with a small team, which is exactly why the failure modes are disclosed rather than marketed around. If that is disqualifying for your institution, it is disqualifying — better established at the start. |
| "The interface won't work for our students." | The interface is available in 16 languages and students converse in whatever language they write in. But some teacher-facing documentation is still Chinese first, and that is a real friction for a non-Chinese-reading teacher. These handbooks exist to reduce it, not to pretend it is gone. |
| "We would need it integrated with our LMS." | There is no LMS integration and none is planned in the near term. A public read API and an MCP server expose low-sensitivity data (public courses, institutions, publications) to your own tools; student work is never exposed that way. |
12. How to start
You do not need permission to try level 0. If you want a conversation first — and for level 2 or 3 you do — one paragraph is genuinely enough:
Send it to [email protected]. You will get a straight answer about whether the platform fits, including when it does not — that is not a courtesy formula, it is the only way a free research platform stays useful to the people on it.
If the answer is yes and you are running the course yourself, read the teaching handbook. If you are bringing a research question, read the research handbook — particularly chapter 2, because it determines your timeline.
Something in this handbook wrong, out of date, or missing? Write to [email protected] and say which chapter.
All handbooks · AI teaching overview · Publications · Research governance · uedu.tw
Uedu is developed by Chia-Kai Chang, Assistant Professor at the Center for General Education, National Central University, Taiwan, and is adopted by institutions beyond it. This handbook is available in English · 繁體中文 · 简体中文 · 日本語 · 한국어 · Tiếng Việt · Bahasa Indonesia · Bahasa Melayu · ไทย · Türkçe · Deutsch · Français · Español · Português · Italiano · Ελληνικά. The English version is the reference text. The platform interface itself is available in 16 languages.