Closing the loop on data quality

Context: setting validation rules

Engineering had already created an Excel-style formula editor for creating calculated values. This was a syntax that was second-nature to power users and had proven its usefulness. We decided to allow users to set their own validation queries, as this would allow complete flexibility. Validation rules were accompanied by a description and a fail/warn action – another requirement we’d learnt from the research.

Context: designing the v1

The design of the original report, done in 2017, was driven by information design principles, putting validation failures in the context of a whole dataset to give users a sense of scale.

I worked on this with an information designer who I was mentoring in UX. We did a lot of whiteboard prototyping so we could test ideas with subject matter experts and engineers before moving to high fidelity mockups to play back to our user cohort.

User feedback also helped us decide what to leave out. We explored allowing users to pivot the report to first view results by input file rather than by validation rule. Their response was helpfully direct:

Skip the dev on that. Just give me the validations. User feedback from Senior Analyst

We dropped the alternative view and focused development on the core reporting experience.

Ship, learn, repeat

Our philosophy was to get a working version into users’ hands sooner rather than later. We needed to see how the report held up to real data and business use.

We shipped a capable V1, then observed and progressively refined the experience.

For the 2026 upgrade to add corrections, we looked at how users were already making spot edits to their data by inserting calculation steps into their pipelines. These would typically map one value to another, sometimes making the mapping conditional on another value, such as the policy ID. This was a ‘desire line’ in the product.

The opportunity was to bring that existing pattern into the report, making corrections easier to configure and trace.

How AI now helps me shorten this feedback loop →

Make the scope of changes obvious

Quantemplate applies corrections to bulk data rather than isolated cells, so we needed to make this clear. When a user selects a field, it opens a popup where they enter the correction. The UI makes it clear that corrections can apply to every matching value or use conditions, such as correcting Premium only for a specific Policy Number.

We added a formula bar, so users could derive a value from another column. For example, if a date is missing, take the date from another column and subtract one month. Based on what we’d observed in production pipelines, this would be a necessary addition.

Preserve evidence

Audit was important to our clients, who use Quantemplate as a system-of-record for financial reporting. To support this we displayed the original failed values alongside the corrected rows in the report. The full change history of each edit was displayed.

Give immediate feedback

Corrections are applied to the output on the next pipeline run, so we called this out with a notification bar. But as a user types in a correction, we check that their entered value will pass the rule, and warn if it’s still a fail.

Ordering and audit

One of the things we discovered in testing, as part of our internal QA process, was that the order in which corrections apply is important, since one correction could overwrite a prior one. We created an interface showing all corrections applied to any validation rule, allowing users to reorder or remove them.

A shared correction workflow

The next step is to allow clients to send selected validation results back to the supplier through a Feed where they can make corrections.

This will take out several manual back-and-forth steps which are currently done over email.

The workflow covers preparing corrections, explicitly submitting them back, tracking progress and notifying both parties through in-app updates and email.

Sharing raised a raft of new questions, for instance: should the validation progress bar reflect the entire dataset or only the validations shared with the supplier? I chose the shared validations, ensuring requester and supplier saw the same measure of completion, and made this clear in the UI.

Validation Corrections are live in production. Correction sharing is currently under construction, targeting release in October 2026.

Automated type validation

We’d learnt from our client implementations that validating that data within a column met a generic type definition required too many steps. It wasn’t a problem that fitted neatly into the custom validation rule model that we’d established.

The solution arose when we implemented data semantics across the platform. Now, with an understanding of the data in each column we could implement a very lightweight solution. We added a toggle to enable type validations in Map Column Headers, the point in the pipeline in which schema is defined.

This cut out at least four pipeline steps for every column whose type was validated, removing implementation complexity and slashing hours from implementation time.