hassanismailtech

Posted on Oct 31 Edited on Oct 31 AI-assisted

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth!

#mlhacks #devchallenge #hackathon #opensource

CampusSync turns a user-supplied campus notice into a reviewable calendar action while keeping evidence, uncertainty, and verification honest.

I built a campus notice-to-calendar workflow that refuses to pretend AI is the source of truth

At LASUCOM, an important academic update can arrive as a paragraph in a busy group chat, an image flyer, or a paper notice that someone photographs and forwards. That is normal. The problem is that a date buried in that flow is easy to miss—and turning it into a reliable calendar action is still manual work.

I built CampusSync at Hacktoberfest Hack Day Ikeja × Build54 & LASUCOM to make that one step easier:

A student supplies a campus notice. CampusSync turns it into a reviewable, calendar-ready action—without pretending that an AI model is the institution.

The project is open source under the MIT License: github.com/hassanismailtech/campusync.

It is also deployed with a real inference path. The primary route uses Gemma 4 inference hosted on DigitalOcean, funded with MLH credits, and it falls back to OpenRouter when the primary provider is unavailable. Both provider tokens live only in Vercel environment variables; the browser never receives them.

The problem was not “we need another feed”

The obvious first idea is a better announcement feed. I think that misses the actual pain.

Students are often already surrounded by notices. The failure happens between seeing a message and acting on it. An exam time, a dues deadline, a posting, or an association event may exist, but it lives in a format that is hard to search, filter, or put in a calendar.

The other failure is trust. A plain AI summary can sound more certain than the original notice. For a deadline or an assessment, that is the wrong trade-off. A useful system has to make it easy to check what it relied on—and clear that it has not magically verified the notice.

The design rule: the Mirror Principle

CampusSync follows one constraint that shaped every implementation choice:

CampusSync does not create news. It mirrors a user-supplied notice and preserves the evidence needed to review it.

Each action is designed to retain a source excerpt, an explicit unverified state, and enough context for a student to decide whether to add it to a calendar. “Locally verified” means the user checked it; it does not mean LASUCOM, a department, or an association officially verified it.

That sounds like copywriting, but it changes the architecture:

No WhatsApp scraping or automated group ingestion.
No claims that the product is an official LASUCOM channel or partner.
No server-side storage of raw notice content in this hackathon build.
No fallback that quietly invents an extraction when the model is unavailable.
Fictional/sample data is visibly labelled rather than presented as real notices.

What I built

The working local experience includes:

a Vite/JavaScript dashboard for notice capture, a feed, an exam tracker, and a searchable LASUCOM-focused directory;
text capture with input validation and client-side flyer preview;
browser-local drafts and local filtering;
Google Calendar links and RFC 5545 .ics export for Africa/Lagos; and
a serverless extraction route that is wired for Gemma-capable providers through server-only credentials.

The directory intentionally does not manufacture contact details: entries use “Contact information to be confirmed.” That is a small choice, but it reflects the larger one: a credible information tool should be comfortable saying “I do not know.”

flowchart LR
  A[User-supplied text or flyer] --> B[Validate and preview in browser]
  B --> C{Secure provider configured?}
  C -->|Yes| D[Server-side extraction request]
  C -->|No| E[Fail closed with a clear message]
  D --> F[Unverified local draft]
  F --> G[Evidence-aware review]
  G --> H[Google Calendar or .ics export]

A real AI path, with a failure mode I can explain

Messy flyers and informal campus language are not a rules-engine problem. CampusSync sends a user-supplied notice to a serverless Vercel route. The route calls DigitalOcean’s hosted Gemma 4 inference first; if that request fails, it tries an OpenRouter Gemma fallback. The response is constrained to a structured draft, not treated as a verified notice.

Browser
  → Vercel /api/extract
      → DigitalOcean Gemma 4 (primary)
      → OpenRouter Gemma (fallback)
  → unverified draft for human review

The keys are Vercel server-side environment variables. They are not VITE_ variables, not bundled into the client, and not committed to Git. The route also has a deliberate failure mode: if neither provider succeeds, it returns an error stating that the notice has not been analysed. It does not fabricate a result just to make a demo feel smooth.

That matters to me more than a flashy “AI worked” screen. Gemma is not a decorative chatbot in this project: it is the component that converts messy language into a usable draft. Its open-weight model family also keeps the architecture replaceable and creates a credible future path for an institution to host inference under its own controls. But the model is only one part of the product. The practical value comes from the workflow around it: capture, evidence, review, local filtering, and calendar output.

The access-control foundation is already there

CampusSync is currently useful without making every student create an account. When a person needs to contribute or manage content, Supabase provides the live authentication path: Google OAuth and email magic links are wired into the client.

The Supabase schema defines the building blocks for a responsible publishing workflow:

profiles for the user’s campus context;
organizations for departments, associations, and other publishers;
user_roles for admin, moderator, and org_rep roles;
announcements and exam_schedules as separate data models; and
Row Level Security policies that constrain who can read, create, update, or delete sensitive content.

An organization representative, for example, is not meant to have universal publishing power. The authorization helpers check the authenticated user’s role and organization before allowing changes. This is the foundation for a future where publishing is accountable instead of simply “anyone with a login can post.”

The important distinction is still the Mirror Principle: authentication controls who may publish, but it does not turn an unverified AI draft into an official institutional fact.

A technical detail I did not want to get wrong: time zones

Calendar bugs are quiet. A correctly extracted 9:00 AM exam can become a 10:00 AM appointment if an .ics file is incorrectly treated as UTC.

CampusSync emits local floating date-times and writes X-WR-TIMEZONE:Africa/Lagos into its calendar output. Deadline-only records become all-day events. The test suite also checks that the generated DTSTART is not silently suffixed with Z, which would shift the time.

const lines = [
  'BEGIN:VCALENDAR',
  'VERSION:2.0',
  'X-WR-TIMEZONE:Africa/Lagos',
];

This is not the most glamorous part of the build, but it is the kind of correctness users notice exactly when it fails.

How I tested the smallest claims I could make

I kept the checks aligned with what the repository actually promises:

text-length validation;
calendar generation for timed and deadline-only items;
Africa/Lagos calendar links;
the fail-closed behavior when provider configuration is absent;
six directory categories and 60+ directory entries; and
a guard against invented contact details.

That is not a clinical accuracy study. It is a testable baseline for a live, review-first workflow and a guard against silently degrading to invented output.

What I learned

I started with “can we extract dates from campus notices?” and ended with a more useful question: what should a system do when it might be wrong?

For a high-stakes notice, a confident answer is not enough. The user needs to see the source words, understand what is uncertain, and stay in control of the final calendar action. In other words, the trust layer is not decoration around an AI feature, it is the product decision.

From a campus tool to a customisable campus operating layer

The grand ambition is larger than a notice reader. CampusSync could become a customisable campus operating layer: an open-source core that each institution configures for its own faculties, organizations, academic calendar, verification practices, and channels.

Moodle is a useful inspiration here not because CampusSync wants to replace an LMS, but because an extensible open-source core can be adapted to radically different local institutions. CampusSync’s equivalent would be much narrower and more action-oriented: transform fragmented information into accountable, personalised next steps.

That future platform could support modules for:

verified notice publishing and source-memo evidence;
organization- and cohort-specific feeds;
revision history when a date, venue, or deadline changes;
calendar and reminder integrations;
opportunity tracking for scholarships, grants, and hackathons; and
approved connections to LMS or student-information systems.

The point is not to build all of that now. The point is to make today’s smallest useful workflow extensible without pretending it is already a campus-wide operating system.

What comes next

The next step is not to claim that CampusSync is an official campus system. It is to test a small, consent-based pilot with students and class representatives.

Before an institutional rollout, the project still needs a named owner, an approved publishing workflow, a privacy review, and clear operating responsibility. The technical foundation, live inference, authentication, roles, and RLS reduces the distance to that pilot; it does not replace institutional approval.

The metric I want to earn is simple: how many campus notices become real calendar actions each week?

Every campus runs on messages. CampusSync is an attempt to turn those messages into actions students can review and trust.

Try it

Source code: github.com/hassanismailtech/campusync
Local setup and project boundaries: README
License: MIT

DEV Community