From Notebook to Production: Lessons from Deploying ScreenAI Lab

Updated 23 October 2026 to reflect the ScreenAI Lab implementation, the completed recruitment cycle, and the supplied production database preview.

From a Capstone to a Recruitment Platform

ScreenAI Lab adapts the original ScreenAI capstone into a platform for MBC Laboratory’s recruitment workflow. I independently developed and deployed the lab adaptation, covering candidate registration, document submission, competency evaluation, recruiter review, and result announcements.

The engineering work extended beyond scoring a CV. Candidates needed to submit six document types, administrators needed to manage recruitment periods, and recruiters needed to assess applicants against four division-specific rubrics.

The Scoring Path

Candidate documents → Extraction → Identity masking
                                         ↓
Division rubric → Direct rubric context + processed candidate text
                                         ↓
                               DeepSeek structured scoring
                                         ↓
                   Scores + justifications + supporting evidence
                                         ↓
                            Recruiter review and overrides

The platform uses React, FastAPI, and PostgreSQL, packaged with Docker and deployed on Google Cloud Compute Engine. PyMuPDF extracts document text, and a pretrained IndoBERT NER model supports identity masking.

The scoring service includes rubric dimensions, weights, and indicators directly in the prompt. Although the repository retains LangChain and ChromaDB dependencies from its earlier development, the current scoring path does not perform live vector retrieval.

Evidence Makes Scores Easier to Review

A score alone does not explain a candidate’s strengths or gaps. ScreenAI Lab pairs dimension-level scores with document-grounded justifications and supporting evidence. The evaluation interface presents a competency radar chart and a score breakdown so recruiters can inspect the result.

Recruiters retain control of the decision. They can review candidate documents and override a score with a documented reason.

Test Consistency Before the Recruitment Window

I refined the platform through three development-to-staging cycles. Repeated evaluations used staging applications submitted by approximately 40 laboratory assistants across four division-specific rubrics. All tested samples met a score-difference threshold below three points on a 0–100 scale.

That result measures repeatability on the samples tested. Hiring accuracy and fairness require separate evaluation; a stable score alone does not establish either.

Usage and Operations

The platform supported 312 registered users and 248 submitted applications, and I operated it throughout a two-week recruitment period.

The production database preview supplied for the October portfolio update shows 189 applications with an AI composite score. That dashboard count describes the displayed snapshot, while 248 is the submitted-application count.

The project is recorded as Indonesian registered software copyright No. 001460172 (2026), with me listed as a co-creator.

What I Took Away

• Build the surrounding workflow: submission, document review, recruitment periods, and announcements are part of the product.
• Make results inspectable: scores need supporting evidence and a clear review interface.
• Describe evaluation precisely: repeatability, hiring accuracy, and fairness answer different questions.
• Keep human judgment visible: documented overrides make recruiter intervention part of the workflow.

The project case study includes the production dashboard and competency evaluation previews. Source code and setup documentation are available in the ScreenAI Lab repository.