Automated Data Ingestion sits at the center of iLEVEL's automation strategy. It powers how firms collect, standardize, and trust data across their portfolios — and touches nearly every part of the platform. Raw data defined here feeds calculations, reporting, benchmarking, and downstream decision-making.

Over time, the system accumulated complexity from multiple directions. Firms collect large volumes of data across many portfolio companies, with standards that evolve over time. Users require different levels of access. Data moves through multiple states — submitted, reviewed, finalized — and even finalized data can change, requiring a clear audit trail.

Extraction technologies and AI capabilities were evolving rapidly, shifting assumptions midstream. Introducing automation into a highly permissioned, audit-sensitive system created a new tension: automation could increase speed, but any erosion of trust would undermine the platform's core value.

Before changing workflows, I needed to understand what kind of system Data Collection actually was. On the surface, it appeared to be an intake utility. Mapping the end-to-end flow revealed something different: it governed how data entered, moved through review states, triggered communications, and ultimately became trusted system data.

The issue wasn't that it touched many features — that was expected. The issue was that its structure reflected historical growth rather than intentional architecture. Responsibilities were distributed across loosely connected surfaces without a coherent governing mental model.

Rather than defaulting to a reskin, I reframed the question: what mental model should govern this system? That shift clarified the restructuring.

Data Requests became a configuration layer. Dashboard and Manage Collection were unified into a single operational surface. Email Settings moved into context, and Data Upload became an embedded action rather than a destination — aligning navigation with workflow logic rather than legacy boundaries.

Early in discovery, clients consistently told us they wanted all their data extracted. If automation could handle it, why not capture everything? That assumption unraveled once users experienced the workflow.

Extracting everything came with a cost: review, cleanup, and reconciliation quickly outweighed the value. What users actually wanted was a small set of trusted data points — often 10–15 — that reflected the health of their portfolio without creating downstream work.

Centring on that distinction prevented us from over-optimising for extraction breadth and forced the system toward validation and confidence instead.

ADI's volatility made one thing clear: a tightly coupled workflow would not hold up. ADI 1.0 followed a largely linear flow built around a single extraction path. As model limitations surfaced, that structure showed strain.

For ADI 2.0, the workflow was restructured into modular, decoupled steps. Extraction, review, mapping, and submission could evolve independently. This allowed new approaches — such as LLM-based methods — to be introduced without destabilizing the rest of the system.

An early design separated reviewing extracted data from mapping it to iLEVEL's data model into two steps. Conceptually clean — but Engineering surfaced a constraint: the data and interactions were tightly coupled. Separating them increased state-management complexity and technical risk.

We consolidated both steps into a single screen, organized as left and right panes. The density was intentional. When automated extraction is involved, side-by-side validation becomes more important than visual simplicity.

Given ADI's scope and volatility, sequencing mattered as much as solution quality. We deferred deeper document viewer integration due to cross-platform dependencies and architectural risk. We avoided overbuilding around early model capabilities, recognizing that extraction accuracy would continue to improve.

These were not gaps — they were deliberate sequencing decisions. The priority was to establish a stable foundation before layering additional complexity.

ADI remains a multi-phase initiative, but this work established a more durable foundation for automation within iLEVEL.

Co-design partners cited ADI as a differentiator, and at-risk clients engaged with ADI demos as part of stay-or-leave evaluations.

Foundational systems require sustained ownership. When complexity is high and direction is fluid, continuity becomes a strategic asset.