eSource Study Builder

The problem

Clinical study builders differ in vocabulary, markup, navigation, and save behavior. A brittle automation tied to labels, element IDs, or one platform’s screen order fails as soon as the same study is entered somewhere else.

What I built

I built a Chrome extension that discovers controls by semantic role and meaning, maps field types with confidence and a runner-up, plans dependencies, escalates ambiguous decisions to a human, reads changes back, verifies persistence by leaving and reopening the builder, and reconciles reruns instead of duplicating work.

No platform-specific selectors

The same extension ran on two mock platforms whose labels, layouts, markup, and navigation were intentionally different. Controls are found by semantic role and nearby meaning, while the model is used sparingly to map each platform’s field-type vocabulary. That mapping happens once and is cached instead of spending a model call on every field.

The build order is a correctness constraint

Fields must exist before another field can reference them, values can be discarded when a type changes, and visibility rules arrive in sponsor order rather than dependency order. The planner topologically orders the work, applies visibility rules in a second pass, and escalates cycles or dangling references instead of guessing.

Verifying the editor is not verifying persistence

An early run built a complete form in the working editor while the saved study still contained zero fields. The final verifier leaves the builder, reopens it, and checks the rendered study again. That round trip catches a false success that screenshots or in-dialog read-back cannot.