TraceLab: A Laboratory Information Management System for Research Data Traceability

A sample can pass through several hands and stages before a result is reported, and when those steps live in spreadsheets and informal notes it's hard to know what happened, when, and by whom. Approval workflows need clear ownership; lab managers need visibility without manually reconciling spreadsheets; and cost recovery has to connect services back to the projects and samples that incurred them.

• Track the sample lifecycle from intake to reporting
• Keep every result linked to the work that produced it
• Support lab roles and access boundaries
• Give managers visibility into workflow status
• Preserve auditability for sensitive operations
• Support future multi-lab and institution-scoped workflows
• Enable better research data quality and reuse

TraceLab is structured around a clear separation between the interface, workflow logic, and database layer. The data model is designed around lab-scoped entities such as projects, samples, users, roles, services, invoices, and audit events, so each workflow can be traced without mixing records across contexts.

• Project setup and lab context
• Sample registration and intake
• Sample status tracking across the workflow
• QC and review workflows
• Dataset and result approval
• Inventory and equipment awareness
• Cost-centre and service costing workflow
• Reporting and dashboard views
• Audit trail and end-to-end traceability

Workflow-first data model

I modelled the real lab workflow first — projects, samples, services, results — so the schema mirrors how work actually flows rather than an idealised version of it.

Lab-scoped access boundaries

Records and permissions are scoped to a lab and role, so people see and change only what belongs to their context.

Traceability as a first-class concern

Every state change is captured, so any result can be traced back to the work, conditions, and people behind it.

PostgreSQL-backed system of record

Relational integrity and constraints fit a domain where every record must tie back to a real sample and stage.

Private source, public architecture

The source stays private; the portfolio shares architecture and decisions instead, so the thinking is visible without exposing the system.

Incremental build, not a big-bang rewrite

Building in steps keeps the first single-lab version usable while the multi-lab model takes shape.

Sanitized proof, never private data

Proof is shown as diagrams and dummy-data screenshots, never real lab records.

• Show the architecture, keep the source private

  TradeoffLess to click through publicly, in exchange for protecting an active system and its data.

• Design a flexible multi-lab model early

  TradeoffMore upfront modelling, so the first single-lab version stays useful while leaving room to scale.

• Auditability without a heavy interface

  TradeoffLogging happens behind the scenes, so the trail stays complete without cluttering the screens people use.

• Workflow-specific where it matters, generic where it doesn't

  TradeoffSome bespoke modelling for lab specifics, balanced against reusable, maintainable components elsewhere.

• Leave seams for future deployment paths

  TradeoffA little extra structure for multi-institution use now, without overengineering the first release.

• A single, trustworthy timeline for every sample
• Validation that catches data-entry errors at the point of capture
• Sensitive operations that stay auditable over time

Shows I can model a regulated, audit-heavy domain and turn it into a dependable system of record.

• Add sanitized dashboard screenshots
• Add the architecture diagram
• Add a sample-lifecycle walkthrough
• Expand the cost-centre and reporting narrative
• Prepare a private demo with dummy data if needed

• Next.js
• TypeScript
• PostgreSQL
• Prisma