Research Integrity platform, from zero

Morressier's existing product, Proceedings Manager, already ran a few content checks at hand-off. The new team's brief was broader: a specialised AI system that protects research owned by publishers and institutes, with preflight checks (is the paper complete and well formed?) and integrity checks (is anything about it suspicious?) in one place.

I was the founding designer for the Research Integrity product, working with two full-stack engineers, a QA engineer, a product manager, an engineering manager and a user researcher shared across the company. The product's first customers included ASCPT and the SAE.

Rather than build every check ourselves, we partnered with existing providers and became the aggregator, which let us validate the idea with customers early and build anticipation in the market while refining the experience. The workshops left us with three groups of questions. Product: how might we combine different kinds of integrity checks into one seamless experience, make investigation faster, surface patterns of misconduct across submissions, and make checks proactive rather than reactive? Experience: how might we make switching from several tools to one feel natural, present complex issues clearly and actionably, help users feel confident in their decisions, and keep the learning curve short? Business: how might we show measurable value to publishers and make integrity a selling point for their journals?

The MVP was deliberately plain. An author or editor uploads a PDF, chooses their role, and receives a report by email with a reference number; publishers could upload in bulk and get a spreadsheet of results. Behind it, the checks were a mix of our own and third-party services such as PaperPal and iThenticate, and the report listed every check with its response.

That plainness was the point: it let us learn which checks publishers trusted, how they wanted results delivered, and what they did next, before we built a workspace around it.

The MVP had taught us who the customer was. Individual researchers liked the tool but could not justify the cost for occasional use; publishers and societies had more complex needs and were willing to pay to protect their publication quality. So the beta pivoted to institutional users. Batch upload became a dashboard: users could watch a batch process, see how many papers passed or failed, and name batches themselves instead of tracking submission IDs in a spreadsheet.

The beta also introduced workspace management for our internal team. Two configuration needs came straight from customer conversations: publishers wanted to pay only for the checks they used, so checks had to be switchable per workspace; and they wanted their own thresholds, since a 20% similarity score is a flag for one publisher and acceptable for another. A management portal let customer success control both per publisher.

Organisers reviewing a volume for publication now saw an integrity overview, the number of submissions flagged, and could open the search or volume analytics without leaving the hand-off flow. Each paper in the table carried its integrity status beside its topic.

Publishers think in journals and volumes, so the product learned to. A publisher's space lists its journals; each journal its volumes; each volume its papers with issues. Analytics sit at every level: issue progression over the publication lifecycle, the ratio of preflight to integrity issues, the authors and institutions with the most issues, and issues per check.