Skip to main content

Data Model

The PostgreSQL schema is built around six core entities. All of them are deployed through migrations and are live in the production database.

Core entities​

User — the base identity record, specialized into three roles: Innovator, Mentor, and Admin. Role determines which dashboard a user sees and which API routes they can call.

Incubation Application — links to a User, tracks the application's status through its lifecycle (submitted, under review, approved, rejected), and is the record that, once approved, triggers automatic account creation for a new innovator.

Event — created and managed by an Admin, visible to Innovators for registration. Events are the mechanism through which innovators engage with Centre activities outside the core incubation stages.

Mentor Assignment — a junction entity between Innovator and Mentor, capturing which mentor is responsible for which innovator. This is the entity the domain-matching logic writes to when an administrator confirms an assignment.

Progress Log — records stage transitions and milestones for an innovator over time, forming the history behind the progress view on the innovator dashboard.

Notification — stores communication records so that in-app, email, and SMS notifications have a durable, queryable trail, not just a fire-and-forget side effect.

Relationships at a glance​

  • A User with role Innovator has one profile and can hold many Incubation Applications and Progress Logs over time.
  • An Incubation Application, once approved, results in exactly one active innovator account.
  • A Mentor Assignment connects exactly one Mentor to one Innovator at a time, though a Mentor may hold several assignments concurrently.
  • Events are independent of incubation stage — any registered Innovator can apply to any open Event.
  • Notifications reference the User they were sent to and, where relevant, the entity that triggered them (an application decision, a new assignment, an upcoming deadline).

Design intent​

The schema favors explicit junction tables (like Mentor Assignment) over denormalized foreign keys, so that history isn't lost when a mentor is reassigned — the prior assignment record simply becomes inactive rather than being overwritten. This is what makes the audit trail described in Ethical Considerations possible without additional logging infrastructure.