Shane Tan.

Work / No. 02

Corporate Onboarding — a recoverable case workflow

A six-person team's proof of concept for onboarding business customers. When evidence conflicts, the case pauses at the step that found it, a person reviews it, and the case resumes from where it stopped.

2026 · Industry-sponsored final year project, SMU · Team stack: Python · FastAPI · React · MongoDB

My role
Co-developed the team's proof of concept; contributed to the review-and-recovery workflows
Team system
Six-person team: registry lookup, OCR-assisted extraction, reconciliation, ownership analysis, review and resume
Status
Proof of concept · mock and local components · not production
  • Team-built
  • Mock component
  • A person decides
  • Area I contributed to
Fig. 1 The team's case workflow, with pause, review and resume. Illustrative, simplified from the project's documented design; not a screenshot.

01 · Problem and contextEvidence will disagree. The question is what the workflow does next.

Onboarding a business customer means collecting company data from a registry, reading the documents the customer supplies, checking that the two agree, and working out who owns the company. An automated workflow will meet evidence that doesn't agree. Guessing is unsafe, and starting again wastes the work already done.

The team's proof of concept takes a third route. It stops at the step that found the problem, asks a person to resolve it, and carries on from there.

02 · The team's system, stage by stageWalking one case through

  1. 01

    Jurisdiction

    The case resolves its jurisdiction, which decides where its registry data comes from.

    System
  2. 02

    Registry data

    Company data is fetched from a mock or sandbox registry.

    System mock
  3. 03

    Documents

    Fields are extracted with OCR assistance and scored from read confidence and label match. A field is accepted automatically only when the score clears a threshold and the value agrees with the registry; otherwise a person checks it.

    System or person
  4. 04

    Reconcile

    Registry and document evidence are compared, and every stage validates what crosses its boundary.

    System
  5. ↳

    Blocked, reviewed, resumedReview-and-recovery workflows · I contributed here

    When evidence disagrees, a typed blocker pauses the case at the named step. A reviewer resolves the ownership or data conflict, and the case resumes from its saved checkpoint.

    Person
  6. 05

    Ownership

    Ownership is computed deterministically. Companies use registry data, partnership shares are read from the agreement and confirmed by a person, and government bodies follow a separate path that the workflow doesn't put through the shareholding analysis.

    System + person
  7. 06

    Readiness

    The case is evaluated for readiness before it can be submitted.

    System
  8. 07

    Submission

    A clean synthetic case can reach this step without any exception-triggered review. Submission still waits for the user's explicit confirmation, then goes to a mock target system with replay protection.

    Person mock
  • Team-built
  • A person decides
Fig. 2 Stage 03 in detail: how an extracted field is accepted or sent for review. Illustrative.

I co-developed the team's proof of concept and contributed to its review-and-recovery workflows.

That is the path a case takes when it pauses at a typed blocker, goes to a reviewer, and resumes from its saved checkpoint: the highlighted row above.

The stages, figures and trade-offs elsewhere on this page describe the team's system.

03 · Engineering decisionsTeam-level trade-offs

01Stop at a typed blocker instead of guessing

WhyA named blocker tells the reviewer which step and which evidence disagree.

Trade-offMore cases wait for a person.

02Resume from a saved checkpoint

WhyA reviewed case continues from where it stopped instead of repeating completed steps.

Trade-offEach step's state has to be saved and restorable.

03Accept fields only when confidence and registry agree

WhyReading errors reach a person instead of the record.

Trade-offSome correct fields still go to review.

04Deterministic ownership computation

WhyThe same evidence always gives the same result, so a reviewer can check it.

Trade-offIt supports a reviewer; it is not a legal determination.

05Mock integrations behind replaceable adapters

WhyThe workflow could be built and tested without live registry or target-system access.

Trade-offBehaviour against live systems remains untested.

06Explicit confirmation before submission

WhyNothing is submitted without a person agreeing, and replay protection stops a case being submitted twice.

Trade-offOne extra step for the user.

04 · Boundaries and limitationsWhat this proof of concept shows, and what it doesn't

  • Runs as code in the POC
  • Mock or synthetic
Fig. 3 What the proof of concept runs, and what mocks or synthetic data stand in for. Illustrative.

It shows

  • A case workflow that pauses at a named step instead of guessing
  • Human review and resume from a saved checkpoint
  • Deterministic ownership analysis across three entity types
  • A confidence gate on extracted fields
  • A clean synthetic path with no exception-triggered review
  • Explicit user confirmation and replay protection before mock submission

It doesn't show

  • Live registry or target-system integrations, or a production deployment
  • A legal ownership determination
  • Sponsor or regulatory approval
  • Production security or audit retention; storage is in memory or MongoDB at proof-of-concept level

Team stack · Python and FastAPI (case workflow services) · React (web interface) · MongoDB (local durability option) · OCR (field extraction with confidence scoring) · typed models (validated boundaries)

Artwork
Artwork Abstract, not the system architecture.