Define the scenario
Choose the world the data is from and the entities in it, with their relationships and a stable identity per row. BlueForge produces a clean, internally consistent dataset that joins correctly before anything is made wrong.
How it works
Clean data first, then the mess, in an order you control.
BlueForge does not generate noise and call it realism. It builds a correct dataset for your scenario, then applies a short, ordered list of transformations that make the data behave the way real data does. The list is the design, and the list is also the answer key.
Three things a faculty member does.
Faculty do not write SQL or code to define a share. They work in a scenario-first admin UI: a world to simulate, a few learning challenges to introduce, and a window to reveal the manifest.
Stream it to students
Configured transformations are applied in the order you set, and the result is served from a buffer the platform tops up on a schedule. Students read from that buffer through an authenticated API for the length of the term.
Reveal the manifest
At the end of the assignment you can reveal the share manifest, the ordered list of every transformation that was applied and what it did. It is the answer key, generated from the configuration rather than written by hand.
The transformation pipeline
The central idea is a pipeline. BlueForge starts from clean data and applies a sequence of small, declarative operations. Each one has a fixed name, a parameter schema, and a documented effect.
Order matters, and it is deliberate. A near-duplicate step placed after a missingness step produces duplicates that share the missingness pattern. A drift event scheduled for week 6 changes the data only from week 6 on. The admin UI makes the order explicit because the order is part of what students are meant to discover.
What you can introduce
- Messy formats and missingness. Missing values by mechanism, including values that are missing completely at random and values that are missing as a function of another field.
- Duplicates and referential breakage. Near-duplicate rows from simulated retries, and orphaned foreign keys that point at entities that are not there.
- Late arrivals. Records that show up after their event time, with a delay drawn from a distribution you set, so a correct pipeline has to watermark its ingestion.
- Slowly-changing dimensions. Attributes that change over time on an entity, so history has to be modeled rather than overwritten.
- Scheduled drift events. A column appears, an encoding changes, a new categorical level shows up, tied to a specific course week and led as a planned learning moment, not a hidden trap.
Why a buffer, not on-demand generation
When a student calls the API they are reading from a pre-populated buffer, not triggering generation. The platform tops up each share's buffer on a schedule. This keeps response times flat under a full roster and keeps the data a student sees stable while they work against it.
All students on a roster see the same data for the same share. That is a deliberate choice for v1. It keeps the platform simple and cacheable, and the manifest reveal still works as a shared answer key for the whole class.
The manifest is the answer key
There is no deterministic auto-grader in v1. The artifact at the end of an assignment is the share manifest: a plain, readable account of every transformation that was applied, in order, and what each one did to the data. Faculty choose when to reveal it through an instructor-gated view.
Ready to see the configured presets by course? Browse the use cases, or read the documentation for the faculty and student quick starts.