COGNA
Data Foundations for AI Defined Software
Cogna generates bespoke software applications from customer discovery sessions.
Each engagement begins with messy data landscapes; fragmented sources, inconsistent structures, and unknown transformation requirements.
​
I led the design of Data Space, a modelling environment that makes the path from raw customer data to application schema explicit and inspectable

Overview
Role: Lead Product Designer
Team: Product, engineers, data infrastructure, solution strategists
Focus: Interaction design, platform workflows, research
Impact
Revealed applications running outdated schemas
Surfaced pipeline complexity earlier in projects
Introduced schema validation and type safety
Created shared view of application's data lineage
The problem
AI applications were being designed without a clear view of the data that powered them
Cogna’s platform translates customer discovery into bespoke software applications. But when projects moved into the Define phase, teams lacked a clear way to reason about the data behind those applications.
​
They needed to understand:
-
What data sources existed
-
How they would transform into the application schema
-
Whether the required data actually existed
-
How complex the pipelines would be
​
Instead, this information was spread across notebooks, platform schemas, and local files. The data system behind each app was fragmented and difficult to reason about.
Product Opportunity
Create a shared modelling layer for application data
To support scalable application delivery, the platform needed a dedicated environment where teams could define and reason about the data behind each application.
​
A modelling layer could:
• Make transformation intent explicit
• Reveal dependencies between sources, pipelines, and schemas
• Surface data complexity earlier in projects
• Establish a foundation for data lineage across applications
Interaction Concept
Using a whiteboard-like canvas to model application data
Discovery sessions at Cogna already used a digital whiteboard to map messy processes and data sources.
​
We realised the platform needed a similar environment for defining application data — flexible enough for exploration, but structured enough to model sources, pipelines, and schemas.
This led to the concept of an infinite modelling canvas, where data entities and transformations could be placed, connected, and refined.
Defining Platform Boundaries
Working out how the Data Space would integrate with other core elements of the platform
Before designing the interface, we first needed to understand how Data Space would integrate with Cogna’s existing infrastructure.
Pipelines and the generated application itself ultimately live in the code repository, running as Dagster jobs and application services. Data Space needed to connect to this environment without creating competing sources of truth.
Working with engineering leads, I mapped how definitions created in the platform would translate into code artefacts in the repository.
​
This established a clear boundary:
Platform: modelling the application’s data system
Repository: implementing and running pipelines and application code
​
With these responsibilities defined, we could focus on designing the modelling environment itself.
Defining how Data Space integrates with existing infrastructure and code workflows

Designing the Data Space
An infinite canvas for modelling data systems
To represent the relationships between these elements, we designed Data Space around an infinite canvas built using ReactFlow.
Nodes represent different data artefacts — sources, transformations, and entities — while connections show how data moves between them.
​
This allowed teams to:
-
Trace data from source datasets to application entities
-
Explore transformation pipelines visually
-
Identify missing or incomplete data early
-
Understand the complexity of proposed pipelines
​​
The canvas also served as a structured representation that the platform could use to generate SQL schemas and pipeline definitions.


From Concept to Working System
We delivered an early version of Data Space quickly so that solution strategists could begin modelling real customer data pipelines within the platform.
​
Initial capabilities included:
-
Defining domain entities and relationships
-
Connecting entities to source datasets
-
Modelling transformation steps
-
Generating draft SQL schemas from entity definitions
​​
Although the first implementation was rough, it enabled real workflows to move out of notebooks and into the platform.
​
Testing with users revealed where the interaction model needed refinement, including improvements to node editing and grouping, alongside schema creation and update workflows.
Data Space Evolution
Initial releases focused on enabling teams to model real customer pipelines inside the platform.
As usage grew, Data Space evolved from a visual exploration tool into a structured layer for defining application data systems.
​
Key refinements included:
• Simplifying pipeline modelling into Extract, Transform, Load nodes
• Generating SQL schemas directly from the application data entities
• Introducing schema validation and type safety
• Improvements to the schema update workflows
• Enabling pipeline definitions to be synchronised with Dagster in order to visualise pipeline health
​
These iterations gradually moved pipeline development from fragmented experimentation into a platform-native workflow the system could reason about.



Data Space Evolution
Over the following months, Data Space became the foundation for defining data infrastructure within the platform. These changes moved pipeline development from fragmented experimentation into a structured system the platform could understand.

Outcomes & Impact
Data Space introduced a dedicated modelling layer into Cogna’s application generation workflow, making the data behind each application explicit and inspectable.
​
This shifted data work from fragmented experimentation into a shared platform capability.
​
Impact
• Established a shared view of application data systems
• Reduced reliance on notebooks and ad-hoc pipeline exploration
• Enabled earlier reasoning about pipeline feasibility and complexity
• Provided structured context for AI-generated applications
​
Final shipped product:
