Bringing instructors in through LTI

These are scope, not velocity. The pod that would take this on would be working in LMS/LTI for the first time, so a real learning-curve ramp-up should be added to any calendar estimate (see the sizing caveat in Part 3).

Three sources: the 1EdTech LTI 1.3 spec, the current code (freshly reviewed at today's HEAD), and the knowledge base. Here they are side by side on the questions that matter.

So the platform already recognizes whoever launches, and the standard already hands over the role for free. The one missing link for instructors is that the role is thrown away. That is the core of the change, and it is small. Everything else in the estimate is the safety net around it — because an LMS role becomes a SolidProfessor permission boundary the moment it is trusted.

Confirmed in the code review

• Confirmed New LTI users default to Student and the roles claim is unread — FindOrCreateUserForLtiContext.php:170–177. (ASE-1221 later added a flag-gated path that preserves a migrated member's existing status and role on first launch, but a genuinely new user still defaults to Student.)
• Confirmed Existing privileged roles (Instructor / District Admin / Super Admin) are preserved, not downgraded, on launch — …:104.
• Confirmed ProvisionUserToSchool already accepts Role::INSTRUCTOR end-to-end and even creates an instructor's default class — ProvisionUserToSchool.php:138–140. The plumbing exists; only the two LTI callers pass Student for new users.
• Confirmed NRPS is a dormant flag: accepts_names_roles_services is stored, but no app code fetches or processes a roster (only the vendor library references it).

Three outcomes are easy to conflate, and they are wildly different sizes, so naming the target is the single biggest driver of the estimate. The recommendation below is for the first one.

These are the things the code review surfaced that shape the work. Some are prerequisites, and each maps to a change in Report 03 (the proposed backend changes). A fifth, anonymous-specific finding lives in Part 3.

A natural assumption is that this needs UI changes because instructors input client_id, deployment_id, and the school-mapping ID in the 2.0 instructor tool. That half holds; the conclusion makes the UI smaller, not bigger.

What UI actually does need attention

The real frontend surface is the launch-time pages that currently assume "student":

• The payment / inactive-user redirect — the resource-launch path pushes inactive, non-anonymous users toward /academic-enrollment/payment, keyed on status only, not role (DoLtiResourceLinkLaunch.php:64). Largely handled by provisioning new instructors active so they never reach it; a deactivated instructor hitting the existing inactive dead-end (and contacting CS) is acceptable. Worth a quick check that a valid instructor can't be sent down the payment path.
• The anonymous-LMS landing page — anon-lms.vue ("You're almost there!") is student-worded ("ask your instructor for help").
• The account-link / connect screen (lms-connect.vue) — today's fallback for an unrecognized instructor. With auto-provisioning, a decision is needed on when (if ever) this still appears.

Net: the UI work is real but modest, and it isn't in the config forms. No new config fields — instead, making the existing launch/landing pages role-aware. Worth flagging to a developer up front so no one goes looking to bolt an "instructor" field onto the setup form.

The activation rule has a known-instructor twist — a launch must activate net-new accounts only, never reactivate a deactivated existing one. That is covered in Part 2 (it only arises via email matching, which is a known-instructor mechanism).

These apply to both known and anonymous instructors. The role-mapping itself is tiny — a role resolver + an enum and a change to one caller. What earns the "Medium" is the safety net that turns an LMS claim into a trustworthy permission boundary: provisioning net-new instructors active, deployment-scoped tenant safety (F4), shared sub normalization (F3), a real signed-role check on deep linking (F1), removing the dd() debug calls, role fixtures and regression tests across Canvas and Schoology behind a feature flag, and role-aware launch pages on the frontend.

The file-by-file plan for all of this is Report 03's inventory (touch points #01–17). This section is the decision-level summary; Report 03 is the build spec.

How a known instructor builds and integrates a class today — and the dependency worth naming: creation and integration happen in two different sessions.

What JIT provisioning changes (the access half): it removes the bootstrap/link detour at steps 2–4 — the first launch recognizes the Instructor role and creates/links the account just-in-time, instead of bouncing to /lms-connect. It does not, by itself, move the creation step (1) into the LMS.

Two halves of one feature — both core to the value:

• Access (JIT provisioning) — get the instructor in from the LMS, recognized as Instructor. The backend half.
• Authoring-in-the-LMS — let them build and integrate classes without leaving the LMS. The frontend half — and not optional. The point of provisioning instructors through the LMS is a fully LMS-native lifecycle; if authoring stays behind a direct SP login, the exact friction the feature set out to remove is left sitting in the middle of the workflow. A known instructor can already log into SP directly, so access-alone gives them little — the native workflow is what makes it worth doing.

Email matching is a known-instructor mechanism (anonymous instructors have no email and always create a new record). It intersects the standing business rule directly.

The known-instructor v1 is the shared work in Part 1 plus two known-specific additions: (1) an optional instructor-specific "contact CS" message on a blocked launch — not required, since inactive users already dead-end today; and (2) authoring-in-the-LMS — the frontend half (expose the create controls in LMS mode and thread launch_cache_key through creation), which is not optional. Overall Medium — a backend access half plus a frontend authoring half, ~6–8 small PRs.

The backend file changes are enumerated in Report 03's inventory; the frontend authoring work is the trio-facing half described here.

In masked mode Schoology suppresses name/email. If it also suppressed the role, we couldn't tell teacher from student and the whole idea would collapse. It doesn't — confirmed three ways:

• The standard/library require it. The LTI library treats roles as mandatory — it rejects any launch missing it (AbstractMessageValidator.php:31–33, "Missing Roles Claim"). PII masking is decided independently, purely on the presence of an email claim (Lti13Service.php:212). Role and PII are orthogonal.
• A vendor certification fixture ("Launch Instructor No PII") carries roles: [...#Instructor] with no email/name — role-without-PII is a valid launch.
• Production data Real Schoology launches confirm it directly. Every launch write persists the full payload, so masked launches are inspectable in prod. Across real Schoology deployments, 100% of launches carry the roles claim — including ones with no email and no name. Concretely: the real Fairfax County Schoology deployment alone holds 1,588 launches that carry an Instructor role with no email and no name, and a separate fully-anonymous Schoology deployment (an internal test rig) shows the same pattern. A sampled masked instructor launch contains only iss / sub / roles / custom / context / deployment_id-type claims and the role value […#Administrator, …#Instructor] — with no email or name claim present at all.

So the pivotal question is answered from production, not a hypothetical test — the masked-Schoology launch has effectively already happened, many times, and the data is in prod. This also settles a related item: the Schoology sub is opaque — across ~214k production launches, zero are email-shaped (it's a ~43-char building::guid), so it isn't a hidden PII vector. Note separately: even though the role arrives today, the app ignores it (role defaults to Student) — consuming it is the core known-instructor change, and the anonymous case rides on it.

The account identity is already clean: the anonymous branch builds a synthetic email from internal ids only — CreateAnonymousEmailAddress.php:14, format lti-{school_id}-{lms_user_id}@solidprofessor.com (our own domain, no external email).

But the identity isn't the main risk. The surfaces to close:

• Highest priority The launch record persists the entire payload. Every validated launch writes the whole launch blob to the DB — UpdateOrCreateLtiLaunch.php:47 ('request' => $launchData). In any launch that does carry PII, name/email land here verbatim. For a "nothing in our database" bar, this table is the thing to fix — whitelist non-PII keys.
• Guard The accepts_pii auto-flip. A deployment is flagged PII-accepting simply if a launch contains an email claim (Lti13Service.php:212). A stray email from Schoology would silently un-mask the deployment — guard against it.
• Cleanup The three dd() calls (Lti13Service.php:154/176/191) dump the exception (and nearby payload) into the HTTP response — a PII exposure in a non-masked launch, and a violation of the repo's own no-debug rule regardless.
• Confirmed The LTI sub is opaque. The code doesn't sanitize it, but across ~214k production Schoology launches zero are email-shaped — it's a ~43-char building::guid, not an SIS email/username.

Clean already: deep-link content items carry no user identity, and grade sync sends only the opaque sub and explicitly excludes instructors from the synced set — no instructor identity ever leaves for the LMS.

Confirmed against the permission pipeline. An anonymous + active + Role::INSTRUCTOR account keeps what it needs:

• The anonymous-school filter (FilterAcademicPermissions.php:12–19) strips only three permissions — create_users, add_users_to_class, add_existing_user_to_class — keyed on the school's onboarding strategy, not role.
• create_classes, create_assignments, view_instructor_tools, view_reporting, and trigger_lms_grade_sync are all preserved. So class/assignment creation, deep linking, reporting, and grade sync all work.
• The student-only launch middleware (anon-lms redirect, LMS warning) gate on hasRole('student'), so an instructor is never trapped by them.
• Deep linking has no PII/anonymity gate — it finds the JIT-provisioned account by lti_id and proceeds (subject to the Schoology fixes below).

Confirms your read (C): feature-gating resolves from the DB role, not identity — so an anonymous account with Role::INSTRUCTOR gets the instructor experience; indistinguishability from a student was only ever an admin-visibility question.

Narrow limitations to accept: an anonymous-school instructor can't manually add/create users (expected — students arrive via LMS launch), and can't edit member/roster details through one form (MemberDetailsForm.vue:278). Neither blocks the core teach-and-integrate job; both are worth confirming as acceptable.

Because LAUSD's teachers will deep-link, two items we'd otherwise call "prerequisites" become hard requirements for this specific flow:

• Custom-param drop. Our deep-linked resources carry only title/url/lineitem (CreateDeepLinks.php:46–55) — never lms_school_id. Schoology does not auto-carry app/district custom params onto the resource-link launches created from a deep link, and the later launch hard-requires lms_school_id (FindSchoolByLmsId.php:23–25) or it throws. The vendor resource supports attaching custom params; our code just never calls it. Fixable, but required.
• The :: identifier mismatch. Resource launches store lti_id truncated at ::; deep-link and connect use the full sub. A Schoology instructor provisioned on a resource launch won't match on a deep-link launch → treated as unknown → bounced to login. And an anonymous user can't log in to self-repair. So deep-link recognition simply breaks for them without the shared identifier-normalization fix (F3).

Both are already in the shared prerequisites (Part 1 → "What would be built regardless of role"), but for the LAUSD/Schoology anonymous flow they are non-negotiable, not nice-to-haves.

• We can't email or directly support an anonymous teacher. With no email on file, SP can't send them anything or identify them outside the LMS. The district has already indicated this is acceptable — worth stating plainly in the conversation so it's a known, agreed trade-off.
• An anonymous account can't later convert to a known one. This is simply how anonymous works for any anonymous school today — not a new limitation introduced here. Acceptable from our side.
• Deactivation is how access is revoked. Same free-while-active rule as known instructors; CS deactivates the "Anonymous Instructor" record to remove access.

Anonymous is not a separate build — it rides on the known-instructor work (consuming the role claim) plus a bounded delta:

For the "3 sprints vs 12 sprints" question: firmly toward the low end on scope — a handful of small, well-scoped PRs on top of the known-instructor work, not a multi-quarter build. The pivotal masked-roles question is settled from production data. The one residual is the Schoology deep-link custom-param carry-forward — and its fix is cheap and already in scope. Nothing found suggests a hidden "hardest 10%."

The masked-roles question and the sub-opacity question are both now answered from production data, so the live test is no longer needed. What remains:

• Customer confirmation: the exact privacy bar — "no district-domain email" vs "no email at all." (Schoology's sub being an opaque non-email id is already confirmed from prod.)
• Product calls: that the narrow "can't add users / can't edit member details" limitations for anonymous-school instructors are acceptable, and that auto-creating an instructor default class on first launch is desired.
• One engineering validation (during the build, not before): that lms_school_id carries forward on Schoology resource-links created via deep linking — mooted by the fix to attach it.

1. Confirm the exact privacy bar with the customer — "no district-domain email" vs "no email at all." The technical unknowns (masked launch carries the role; sub is opaque) are already settled from production data (Part 3); this is the remaining requirements question.
2. Land the security prerequisites (F3, F4) as their own small PRs — scope the school lookup by (deployment, lms_school_id), shared sub normalization, and the dd() cleanup. These stand on their own merit and shrink the feature's blast radius.
3. Build known-instructor JIT provisioning + authoring behind a flag — role resolver, provision/promote active, role-aware payment skip, deep-link role gate, the contact-CS outcome, and LMS-native authoring; tested against both Canvas and Schoology.
4. Build the anonymous delta — the small provisioning branch ("Anonymous Instructor" role + name), launch-record PII hygiene (whitelist the payload, guard the accepts_pii flip, remove the dd() calls), and the two Schoology deep-link fixes (attach lms_school_id, shared sub normalization). Detailed in Part 3.