ReOrc Data Platform case study

Role: IT Business Analyst
Company: ReOrc AI
Period: 04/2024 — 03/2025
Stack: Data governance, Data lineage, Data modeling, UAT

Context

The problem

Recurve is ReOrc's microservice data platform: connect a database, build data models, chain them into scheduled pipelines, watch their health. A platform like this is only useful if the person reading a report can trust the number on it. And a number is only as trustworthy as the requirements behind the feature that produced it.

My bet: in a data product, a vague requirement is the most expensive bug. It ships as code, and the cost shows up later as rework.

Why it was hard

The tension

Governance, and modeling touch who may see what, where data comes from and what depends on it. Each of those hides questions a developer can only answer by asking. Every question asked mid-build is a delay; every one guessed wrong is rework.

Spot the gap in a user story

Illustrative example

“As a business user, I want to see where a number in my report comes from, so I can trust it.”

5 of 5 questions still land on a developer as a message.

A made-up story, written to show the craft: a vague line becomes buildable only when its hidden questions get answers. Add the requirement that answers each one.Source: Invented example written to show the technique. Questions follow the Recurve lineage and governance areas in Thao's CV (ReOrc AI, Apr 2024 to Mar 2025).

My part

What I decided

Thao owned

Benchmark enterprise data platforms first, then design the governance and access-control frameworks from what the good ones do.
Design and launch data modeling and lineage features, so business users can trace where data comes from and what depends on it.
Replace loose requirements with a clear requirement framework, and put validation checkpoints before anything is called done.
Lead user acceptance testing: write the functional and data validation scenarios myself.

The decision

Let developers ask as they build, or write the requirement first?

Chosen: A requirement framework

Replace loose requirements with a clear requirement framework, and put validation checkpoints before anything is called done.

Source: Thao's CV (ReOrc AI, Apr 2024 to Mar 2025).

Thao owned

The platform areas I worked on

Recurve

GovernanceAccess control frameworks
Modeling and lineageTrace where numbers come from
Pipeline healthHealth tracking dashboard

Recurve

GovernanceAccess control frameworks
Modeling and lineageTrace where numbers come from
Pipeline healthHealth tracking dashboard

Source: Thao's CV and the public Recurve documentation

Recurve documentation, Getting started page, listing the step-by-step workflow from connection to pipeline — Recurve's public documentation (docs.reorc.com): the workflow my features had to explain end to end. Public page, not an internal screen.

From source to report in Recurve

01Connect sourcesDatabases and connectors
02Build data modelsFrom sources and SQL models
03Chain pipelinesScheduled jobs
04Track healthMonitor runs on a dashboard

The product flow lineage has to explain, end to end.Source: Recurve public documentation (docs.reorc.com, getting started)

Process

Catching it early

Requirement review, data validation scenarios and functional scenarios each target a different kind of failure. Run them in order and defects surface while they are still cheap to fix.

Results

reworkCompany figure: −40%
faster feature deliveryCompany figure: +20%
first-pass successCompany figure: 95%

Source: Thao's CV (ReOrc AI, Apr 2024 to Mar 2025). Baselines and measurement method are not disclosed.

Data people can trust, with 40% less rework.