EduAI
Architecture and technical leadership
EduAI is a shared education platform with connected applications. My role was to help the team keep the architecture coherent, turn review findings into concrete work, and make release decisions with professors and other stakeholders.
Secondary technical lead working with a six-student team. Most of my time went into helping the team make and ship sound decisions.
A role is not course access.
A settings route checked a person's platform role, but not whether they taught the course they were changing.
Check access to the target course before reading or changing its settings.
Architecture becomes everyday work
I spent more time on architectural decisions, pull-request review, daily stand-ups, and stakeholder meetings than on implementation in this role. A design decision had to become something a teammate could understand, build, and bring back for review.
In July 2026, integration review surfaced risks across authorization, security, concurrency, queue consistency, and release hardening. I helped turn those findings into scoped follow-up work and review criteria.
Two decisions show the nature of that work. One concerned where course information should live. The other concerned who could change a course's settings. Both affected behavior across application boundaries.
One source for course information
A July 17 architecture record settled on EduAI Core as the source of truth for course information. Extensions retained a minimal local anchor for their own relationships, keyed to the Core course identifier.
Implementation details
Titles, dates, and publication state came from Core through a batched live read. That avoided maintaining several mirrored copies of the same fields. The decision also removed local-only course creation from the Question Maker extension.
The unavailable state was part of the design. If Core could not be reached, the extension would show that clearly instead of treating an old local copy as current course data. This made the dependency visible to both implementers and users.
Course access before settings
A July 20 audit found that RAG settings routes checked a global role without checking whether the caller taught the target course. A valid platform role was therefore too broad a basis for reading or changing those settings.
Implementation details
The repair brought both the read and update routes through the existing course-access check and a rank gate. The review decision was to enforce the course boundary consistently with neighboring course operations.
That is the kind of detail I look for across a change: an authorization rule should follow the resource being accessed. A route can look reasonable in isolation and still disagree with the rest of the application.
A review is finished when the behavior is checked
My review work included reproducing failures against the base revision, inspecting migrations and access rules, running focused checks, and revisiting earlier requests before approval. The goal was a change whose behavior the team could explain.
I also used stand-ups and review meetings to clarify scope and keep decisions connected to the people building the system. EduAI was shared work. These examples describe my architectural and review contribution, not sole ownership of the implementation or its results.