What It Actually Takes to Build a Workforce Management Dashboard for an AI Company

The initial brief from GenMorphics AI Solutions sounded straightforward: build a dashboard to help their team coordinate work across a global network of domain experts. As we got into the details, it became clear that "dashboard" was underselling the complexity significantly.

GenMorphics works with specialists in software engineering, mathematics, legal reasoning, and scientific disciplines. The work requires matching highly specific tasks to people with verifiable domain depth — not just anyone who checked a box saying they know Python. Building a web platform that could reliably route the right task to the right person, track project status across dozens of concurrent assignments, and maintain strict data access boundaries between different client projects turned out to be a genuine systems architecture challenge.

The Skill Routing Problem

The first thing we designed was the skill profiling system. The naive version of this is a checkbox list of technologies and subjects. The problem with that approach is that it makes no distinction between someone who learned Python basics in a weekend course and someone who has been writing production Python services for three years.

We structured skill profiles across three dimensions: domain category, competency depth, and verification status.

Domain categories span the disciplines GenMorphics works across — software engineering broken into language-specific tracks, mathematics covering areas like calculus, linear algebra, and discrete math separately, and professional fields including legal analysis, financial modeling, and scientific writing.

Competency depth marks whether a skill is self-reported or has been verified through a qualification review. Task routing logic only assigns work that requires verified skills to people who hold verified badges in that category.

interface ExpertProfile {
  id: string;
  skills: {
    category: "Software Engineering" | "Mathematics" | "Legal" | "Scientific";
    subcategory: string;
    depth: "Introductory" | "Proficient" | "Expert";
    verified: boolean;
    verifiedAt: Date | null;
  }[];
  activeTaskCount: number;
  maxConcurrentTasks: number;
}

function isEligibleForTask(expert: ExpertProfile, task: TaskRequirement): boolean {
  return task.requiredSkills.every(req =>
    expert.skills.some(s =>
      s.subcategory === req.subcategory &&
      s.depth >= req.minimumDepth &&
      (req.requiresVerification ? s.verified : true)
    )
  );
}

Authentication Architecture

The platform serves multiple stakeholders with fundamentally different access requirements. Domain experts can see only their assigned tasks and their own performance metrics. Project managers can see all tasks within their assigned project portfolio but not tasks belonging to other clients. Administrators have full access to user management, skill verification, and cross-project reporting.

We implemented this through role-based access control (RBAC) with row-level security at the database layer. Supabase's Row Level Security policies enforce access boundaries at the data layer itself, which means even if a bug in application code produced an unauthorized query, the database would refuse to return the data.

-- Experts can only view their own task assignments
CREATE POLICY "expert_own_tasks" ON task_assignments
  FOR SELECT USING (
    expert_id = auth.uid()
  );

-- Project managers see tasks within their managed projects
CREATE POLICY "pm_project_tasks" ON task_assignments
  FOR SELECT USING (
    EXISTS (
      SELECT 1 FROM project_managers
      WHERE user_id = auth.uid()
        AND project_id = task_assignments.project_id
    )
  );

For authentication itself, we integrated OAuth 2.0 with Google Workspace, which was the identity provider GenMorphics already used internally. This eliminated password management entirely for the core team while still allowing external domain experts to authenticate through a separate flow.

The Dataset Access Problem

Some tasks involve reviewing code repositories, audio samples, or domain-specific documents that belong to specific clients. These assets cannot be freely downloadable — they should expire and become inaccessible once a task is completed or reassigned.

We addressed this with short-lived signed URLs. All work materials are stored in private cloud storage buckets with no public access. When a user opens a task, the server generates a signed URL that is valid for 300 seconds — long enough to view and work with the material, short enough that the URL is useless by the time a task session ends.

async function getTaskAssetUrl(
  taskId: string,
  assetPath: string,
  requestingUserId: string
): Promise<string> {
  const assignment = await db.taskAssignment.findFirst({
    where: { taskId, expertId: requestingUserId, status: "ACTIVE" },
  });

  if (!assignment) throw new Error("Unauthorized: task not assigned to user");

  const { data } = await supabase.storage
    .from("task-assets")
    .createSignedUrl(assetPath, 300);

  return data.signedUrl;
}

What We Learned

The most valuable insight from this project was how much the technical complexity was driven by human organizational structure rather than technical requirements. The skill routing logic, the access control layers, the asset expiry design — all of it was a direct translation of how GenMorphics actually manages their team and their client commitments.

The web platform wasn't replacing that structure; it was encoding it in a way that could scale. That distinction shaped every architectural decision we made.