Skip to content
Research areas

What we are working on

Four areas, each defined by the questions it is trying to answer. The descriptions say what is being asked, not what has been found: findings live in the papers.

Open

Harness engineering

Making long-running agent systems dependable.

An agent that runs for hours inside a business cannot be judged by a single answer. This area studies the harness around the model: how work is decomposed, checked, retried and handed to a person, so that a long-horizon system fails safely and recovers without supervision.

Questions we are working on

  1. 01

    Which checks catch a drifting agent before its output reaches a record?

  2. 02

    How should a system decide when to stop and ask a person?

  3. 03

    What does a useful audit trail of an autonomous run look like?

Papers

No published paper yet. Work with us on one of these questions.

1 paper

Data architecture and operating models

When domain teams should own their data, measured rather than argued.

Whether a large organisation should adopt a data mesh is usually settled by opinion. This area measures the structure of cross-team data dependencies, models the teams that serve them, and simulates the operating models at equal headcount so the decision rests on evidence.

Questions we are working on

  1. 01

    How do data dependencies between teams actually grow over time?

  2. 02

    Under which conditions does a central data team stop scaling?

  3. 03

    When does relabelling teams as domains change nothing?

Papers

When Does Decentralization Pay Off? An Empirical and Simulation Study of Data Mesh Operating Models

Whether a large organization should adopt data mesh hinges on how data dependencies between its domains are structured and grow, yet this structure has not been measured and existing evidence on data mesh is almost entirely qualitative. We mine 566 public infrastructure manifests of Norway's labour and welfare administration (NAV) to reconstruct its declared cross-team data-dependency graph and five years of its growth. The graph is sparse (3.7% of team pairs) and hub-concentrated (degree Gini 0.53 versus 0.24 in matched random graphs); edges grew quadratically at a stable low density (a = 2.03, 95% CI [1.99, 2.31]), contradicting our hypothesis of sub-quadratic growth, while catalogued data products grew sub-quadratically (a = 1.37). We then prove that a central data team's capacity is bounded under communication overhead regardless of headcount, that mesh stability is governed by the most connected domains, and that relabeling teams as domains without transferring ownership can never beat centralization. A verified discrete-event simulation of central, mesh, "theater" and hub-and-spoke operating models at equal headcount, pre-registered before any comparative output, shows that the all-pairs dependency assumption penalizes the central model rather than the mesh, and that the mesh's delivery advantage depends chiefly on diseconomies of scale in central teams: without them, the two models deliver within 8% of each other. Cross-domain demand, dependency structure and reuse matter far less. Data, code and pre-registration are public.

ReadPDF7 min read
Open

Evaluating production AI

Test sets, thresholds, shadow mode and drift.

A system that is right in a demo is not yet right in production. This area is about how to build a locked test set from a business's own files, how to agree a threshold before launch, how to compare a system against the people it works beside, and how to notice when its quality moves.

Questions we are working on

  1. 01

    How small can a test set be and still predict production accuracy?

  2. 02

    What should a shadow-mode comparison measure?

  3. 03

    Which signals show drift early enough to act on?

Papers

No published paper yet. Work with us on one of these questions.

Open

Document AI for regulated documents

Reading forms, records and correspondence with every field traceable.

Applications, declarations, invoices and records arrive as scans, PDFs and email. This area studies extraction that keeps a link from every field back to its source, validation that catches the errors that matter, and the handling of messy inputs that real offices produce.

Questions we are working on

  1. 01

    Which validation rules catch the costly errors rather than the common ones?

  2. 02

    How should confidence be reported so a reviewer trusts the right fields?

  3. 03

    What do scanned and handwritten pages cost in accuracy, and how is that stated honestly?

Papers

No published paper yet. Work with us on one of these questions.