Pre-compliance preview. Not affiliated with or endorsed by the University of Toronto or Instructure, Inc. No product access or student-data processing until approvals land. Waitlist open.

Compliance

Our approach to student data.

Cadenza is a study planning tool for university students. It works by reading a student's Canvas course data with their explicit consent, and turning it into a weekly plan. This page is the memo we would hand to legal counsel.

Last reviewed April 22, 2026. legal@studycadenza.com. Technical detail and open advisory questions.

What we areA pre-launch study planning tool. No accounts, no live users.
What we processCourse structure: readings, due dates, module titles, the plan our AI generates. Never grades, submissions, or private messages.
What we are asking forA non-expiring Canvas developer key from UofT, a named IITS contact, and acknowledgment of our Phase 1 model.
StatusPre-compliance. Waitlist only. No student data flows today.
Current status
Canvas developer key from UofT
The Phase 1 ask described below
Pending
Conversation with UofT
This page supports it
In progress
Move to a Canadian data centre
Scheduled before any UofT launch
In progress
Internal privacy review
This document plus a data flow diagram
In progress
I

The product, and the data it touches

Cadenza sits between the student and Canvas. A student authorizes the tool by generating a personal, read only Canvas API token inside their own Quercus settings, and pasting that token into Cadenza. From that moment, Cadenza can read the course material Canvas already exposes to the student, and nothing more.

The tool then parses the syllabus, extracts the structural scaffolding of a student's semester, and produces a week by week study plan. The output is a set of readings, due dates, module titles, and AI generated study tasks, grounded in the student's own course content.

Why this matters:A study planner needs the shape of the semester, not the substance of assessments. Cadenza's design minimizes what it touches so the surface exposed to any future privacy incident stays as small as possible.
II

What we persist, and what we do not

Cadenza persists the structural scaffolding of each student's week. That includes week numbers, reading titles, due dates, module and lecture names, and the study plan our AI generates from the above. The content students study is not something Cadenza keeps in its own database.

Categories we explicitly never persist: grades, submission contents, test or quiz questions not already posted publicly, instructor only materials, private messages, discussion posts not explicitly public, and any information about other students. Canvas's read only permission model enforces part of this. The rest is enforced inside our import pipeline, which filters before any write.

Why split it this way:Grades and submissions are the categories a legal reviewer would worry about most. Keeping them out of Cadenza's persistence boundary entirely means there is no theoretical breach that exposes them, because they are not there to begin with.
III

Where data lives, and where it is going

Cadenza's database today runs in a data centre in Oregon, United States, operated by Supabase on AWS infrastructure. The web application is hosted on Vercel. DNS and the content delivery network go through Cloudflare. No data is replicated to European regions.

Before Cadenza opens to any UofT student, the database migrates to Supabase's Canadian region in Montréal. This is a planned, hard prerequisite, not a nice to have.

Why the move is non-negotiable:Ontario's public sector privacy expectations and UofT's likely contractual expectations under any future data access agreement favour Canadian residency for student data. The current US hosting is an artifact of how the project was initially set up. Moving before institutional engagement is the right order of operations.
IV

How consent works

Inside the student consent model Cadenza uses in Phase 1, consent is the legal basis for processing. The model is designed to be meaningful, not ceremonial. A student authorizes Cadenza by taking an affirmative action: generating a Canvas token inside Quercus and pasting it into the tool. There are no pre ticked boxes, no deemed consent, no shared session handoffs.

Revocation is immediate and unilateral. A student can revoke their Canvas token from inside Quercus at any time, or use the one click revocation inside Cadenza's own settings. Either action permanently terminates Cadenza's access. There is no background refresh that keeps the connection alive.

Export and delete operate on the same principle. Emailing legal@studycadenza.com produces a full export or a full erase of the student's account within two business days, and deletion cascades through every derived record.

Why consent is the right frame: Canvas already exposes a permissions mechanism (the personal API token) that lets a student authorize a third party tool to read their own course data. Cadenza operates within that existing mechanism rather than bypassing or reinventing it, which keeps the consent chain clean and auditable.
V

Our path to launch

Cadenza follows a three phase model common to student founded edtech companies. The point of phasing is to lower institutional risk. UofT engages as an institution only after demand and a clean privacy track record are demonstrable, not before.

Phase 1: student consent operation. Students authorize Cadenza individually. Cadenza operates until it reaches internal targets of about 500 consenting students and a full year of operation without a privacy incident. Phase 1 does not require a full institutional data access agreement. It requires student consent, a Canvas developer key, and adherence to the practices on this page.

Phase 2: institutional agreement.With proven demand, Cadenza approaches UofT for a formal data access agreement. This covers integrations that go beyond a single student's consent, such as institutional sign on, class level analytics, and faculty facing features.

Phase 3: institutional scale. Full UofT endorsement, expanded feature set, and (if the model holds) the same playbook applied to other Canvas using Canadian universities.

Why phased: Phasing lets both parties take on risk proportional to evidence. Cadenza earns trust through Phase 1, UofT commits only as that trust is demonstrated, and institutional capital (time, legal review, vendor onboarding) is spent after the product has shown it is worth onboarding.
VI

What we are asking UofT for in Phase 1

The Phase 1 ask is deliberately smaller than a full institutional agreement. It is the minimum infrastructure Cadenza needs to operate cleanly under student consent, and it is structured so UofT can extend it without committing to outcomes that have not yet been earned.

One. A non-expiring Canvas developer key.This registers Cadenza as a documented application with UofT's Canvas instance. It does not grant institutional data access. Students continue to authorize individually. It gives Cadenza an officially registered presence and lets Canvas attribute API calls correctly for audit purposes.

Two. A named technical contact. Somewhere inside IITS or Academic Technology Cadenza can direct infrastructure questions during Phase 1. Not a policy owner, just a working contact.

Three. Acknowledgment of the Phase 1 operating model. Ideally a short note from UofT confirming awareness of Cadenza, no objection to student consent based access in Phase 1, and an expectation of a Phase 2 conversation when demand is demonstrated.

Why this shape of ask: It is the smallest request that still produces a legitimate, documented operating posture. Asking for a full data access agreement up front would ask UofT to commit before there is anything to commit to. A developer key plus acknowledgment keeps the door open for the bigger conversation at the right time.
VII

How Canadian law applies

Two statutes are relevant, and they apply to different parties. FIPPA, the Ontario Freedom of Information and Protection of Privacy Act, applies to UofT as a public institution. PIPEDA, the federal Personal Information Protection and Electronic Documents Act, applies to Cadenza as a commercial actor processing personal information across provincial lines.

In Phase 1, Cadenza operates within Canvas's existing permission structure. The legal consequence, as we read it, is that UofT is not acting as the custodian of record for data that flows to Cadenza via a student's personal token. The student, by using the Canvas mechanism already provided to them, is the party authorizing access. Phase 2 introduces a formal agreement that expressly governs UofT custodied data once Cadenza's integration goes beyond what a single student can authorize.

This section reflects our own reading. We are not a law firm. We invite UofT Legal and external counsel to flag anything we have misunderstood. Changes based on that review are documented on this page with a date stamp.

Why we are explicit about our reading: Compliance documents that assert legal conclusions without showing the underlying logic invite suspicion. Showing the logic, and inviting correction, is the fastest way to converge on a shared reading with counsel.
VIII

What we do not have yet

A complete list, so nothing is hidden between the lines.

  • A UofT issued Canvas developer key (the Phase 1 ask above).
  • An Instructure Canvas Partner App registration.
  • A signed data access agreement with UofT (the Phase 2 artifact).
  • Completed migration to the Canadian data centre.
  • A SOC 2 report.
  • A third party penetration test.
  • A dedicated Data Protection Officer (planned for Phase 2 launch).
  • An institutional admin console with exportable audit logs.
Why we surface the gaps: A reviewer notices what a page omits. Listing the gaps openly, alongside the Phase they belong to, converts a list of risks into a roadmap conversation.
IX

Contact for institutional review

For questions from UofT Legal, Instructure, or any institutional privacy office:

legal@studycadenza.com

We respond within two business days. For an introductory call or additional documentation (architecture diagrams, data flow maps, redacted schema exports), mention the need in your first email and we will prepare materials ahead of the conversation.

Cadenza is an independent project founded by a second year Rotman Commerce student at the University of Toronto. It is not affiliated with or endorsed by the University of Toronto or Instructure, Inc.

Going deeper. For detailed technical explanations of our codebase, backend, hosting, token handling, and the specific questions we are seeking advisor input on, see Guidance.

This page is maintained as part of Cadenza's pre-launch transparency. It is versioned and dated as the compliance posture evolves.