mahnoor·fatima

Hyperbuilding A, Centralized Data Infrastructure

Two Sankey diagrams side by side. The left, headed Team Data Flow, runs broad ribbons of colour from each design team through to a shared data team column. The right, headed Data Team Workflow Phasing, sorts the same flows into successive project phases.
How data moved between teams, and how that flow was phased.

Enable cross-disciplinary collaboration through shared data standards, real-time feedback, and transparent performance tracking.

The project was structured around a shared conceptual framework inspired by the Zen practice of Ensō, emphasizing completeness, continuity, and cyclical evaluation. Each design team translated this framework into discipline-specific KPIs, allowing abstract principles to be operationalized as measurable targets.

Overview

For Hyperbuilding A, the Data Team designed and implemented a centralized data infrastructure to support coordination across multiple design teams. Rather than producing geometry, the team focused on organizing information flow, validating data integrity, and translating conceptual goals into measurable metrics that could guide decision-making throughout the project lifecycle.

Data Infrastructure and Automation

Workflow Structure

The data system was organized into three phases:

  1. Setup and integration. Standardized file naming, Speckle project structure, and Drive organization.
  2. Automation and collaboration. Python-based extraction, validation, and dashboarding.
  3. Monitoring and feedback. KPI tracking, version control, and real-time communication.

This ensured consistent data exchange while allowing teams to work independently within their preferred design tools.

A four-part system diagram showing version control and file management as a branching tree, the Speckle integration flow as a colour-coded node chain, the KPI monitoring system as a stack of coloured blocks, and the data validation process as a horizontal flow of decision steps.
The whole pipeline: version control, Speckle integration, KPI monitoring and validation.

Data Extraction and Processing

  • Automated Python scripts extracted data from weekly Speckle model uploads
  • Attribute flattening and targeted searches enabled reliable component-level data access
  • Data was parsed into CSVs and processed using preset algorithms
  • Metrics were calculated as absolute values and normalized scores, on a 0 to 1 scale
  • 92 models processed through the pipeline
  • 17 person studio kept in sync

KPI Design

Each team defined 14 KPIs, tailored to their discipline. For example, the Industrial Team’s Energy Self-Sufficiency Ratio was derived from total generation versus demand, rather than component-level detail.

This approach preserved analytical clarity while avoiding direct involvement in BIM or CAD modeling.

Three grey massing models of the building, each with one surface shaded in a blue to green gradient and labelled beneath: facade panel optimization, facade primary daylight factor, and facade target energy generation ratio.
One KPI, one gradient, painted straight onto the model.

Dashboards, Visualization, and Communication

Dashboard system

Two levels of dashboards were developed:

  • Project-level dashboard: overview of team concepts, KPIs, and federated model status
  • Team-level dashboards: detailed metric breakdowns, interactive calculators, and version tracking

Network diagrams visualized model dependencies and relationships between teams.

A dashboard page with a multi-line activity timeline across the top, an overall project statistics strip beneath, and a stacked bar chart of activity by month in magenta, navy and orange.
Project-level activity, month by month.
A team dashboard listing each discipline in columns with its metrics, above a row of green and red performance panels and a bar chart of scores against studio goals.
Team-level breakdown, scored against studio goals.

Visualization strategy

Performance metrics were translated into spatial feedback:

  • Team performance visualized on a red to green gradient, from the 0 to 1 normalized score
  • Individual metrics visualized on a blue to yellow gradient
  • Gradients applied to Revit materials, views, and schedules

This allowed immediate visual comparison of performance across teams and project areas.

Three grey massing models with their surfaces shaded in dark red speckle at increasing density, labelled facade massing overall performance, industrial massing overall performance, and residential massing overall performance.
Overall performance per massing, read straight off the model.

Custom panels and adaptive families

  • Adaptive panel families consolidated primary, secondary, and tertiary metrics
  • Metrics linked to Revit shared parameters via custom tags
  • Automatic updates kept Grasshopper calculations, dashboards, and Revit documentation aligned
A web dashboard headed Ensō Hyperbuilding, dark navigation bar above a large network diagram of blue and green nodes radiating from a red centre.
The project network, every model and its dependencies.
The network diagram enlarged, clusters of blue and green nodes joined by thin edges to a single red hub, with team names labelling each cluster.

Communication Layer: SlackBot

Reduce manual monitoring by delivering automated project updates directly to Slack.

Features.

  • Recent activity: model updates, versions, contributors
  • Data availability: format compliance and missing KPI detection
  • Data analysis: KPI scores normalized to studio goals

Implementation.

  • Hosted on a Streamlit server
  • Scheduled execution with Slack webhooks
  • Configurable content and reporting frequency
  • Dashboard outputs converted to markdown for Slack delivery
The Slack bot's configuration screen, an authorization panel on the left and a Slack automatic message generator beneath it setting message options, day of week and time of day, with the generated report text alongside.
The bot, and the report it posts.
Four dashboard cards, each pairing a table of metrics with a green semicircular gauge showing progress toward its target.
Live data health, one gauge per stream.

Outcomes and Evaluation

Outcomes.

  • Reduced cognitive load for design teams
  • Improved visibility of KPI performance across a 17-person studio
  • Enabled live monitoring of data health
  • Encouraged consistent data submission through automated reporting

Limitations.

  • SpecklePy extraction speed limited real-time updates
  • Separate data-only models were required when design models lagged behind

Deliverables.

  • Centralized dashboards, at project and team level
  • Automated data extraction and KPI calculation scripts
  • SlackBot for real-time communication
  • Revit model with applied performance gradients
  • Grasshopper definitions and PDF schedules