Owner / Client

Sphere Entertainment Co.: Data foundations

Sphere's construction-data team reconciled invoices, attendance records and timecards before referring uncertain payment lines for human review. Shared definitions also supported handover comparisons and forecasts, while systems and future predictions still required judgement.

Sphere Entertainment Co. · 14 March 2024

Why MortaConnect data and support human review

Working exampleLabour payment validation

Human roleInvestigate exceptions

Input conditionReconcile invoice and site records before checking

Single-digit percentagethe share of payment-data lines Dexter said still needed manual review after standardisation and automatic checks.

Evidence checked togetherinvoice and site records were reconciled before exceptions went to people for review.

Dexter Robinson, then Data Architect at Sphere Entertainment Co., on construction data and expert judgement.

Payment reviewers need evidence they can compare. Sphere’s construction-data team brought invoices, attendance records and timecards into a common structure, checked where they agreed and referred exceptions for human review. Dexter Robinson’s approach connected that work to a wider foundation of shared definitions, reusable reports and experienced judgement.

Dexter put the share of payment lines requiring manual checks at a single-digit percentage. The remaining exceptions still represented substantial work at project scale.

Executive summary

Sphere needed information from different systems to support payment, handover and cost decisions. Agreed definitions give the team a common structure for mapping information from different systems and comparing it in reports. Payment checks compared reconciled records before referring uncertain lines to people. Handover comparisons and cost forecasts illustrated the same relationship between automatic processing and human judgement. Morta workflows were being tried as a way for people to interact with the information and return feedback. Systems could still make mistakes, and future sensing and payment prediction remained ambitions.

Title slide reading Data Foundations, with Dexter Robinson’s name and portrait. — *Data foundations for Sphere’s construction work, presented by Dexter Robinson.*

The results

Labour payment validation started with the supplier’s information. Invoices arrived in different formats, so the team used optical character recognition and AI interpretation to read them, alongside CSV files and APIs where supplier access allowed. Repeated formats within a project gave the team recurring inputs to work with.

Reading an invoice was only the first step. Mapping and fuzzy matching reconciled the invoice, site attendance and timecard records before consistency checks tested whether the data points agreed. Payment reviewers could then investigate the lines those checks could not settle, instead of manually examining every input.

Dexter put the proportion of lines still needing manual checks in single digits. His aim was to direct people towards useful problem-solving rather than reduce headcount. A small proportion of exceptions could still create a substantial review workload on a large project.

Invoices, site-access logs and timecard data feed consistency checks, automatic validation, exception review, a dashboard and an auditable report. — *Invoice extraction and data reconciliation precede automatic payment checks and human exception review.*

The challenge

Sphere brought owner, developer, constructor and operator perspectives to its projects. Dexter’s remit was construction data, separate from the technology used to operate the venue. Across those project perspectives, he saw a shared need for greater confidence in safety, cost and programme outcomes.

BIM had improved information structure and collaboration. Some useful construction information, however, had no direct relationship to a physical building element. Other information remained in documents or required specialist skills to enter a model. Teams needing that information still had to find a way to collect and use it alongside the model.

Diagram comparing information related to physical objects, specialist data entry and document-based information. — *Some useful construction information sits outside physical building elements or remains in documents.*

Manual document chains create another dependency. One person produces a document, another processes it and the resulting spreadsheet becomes the next person’s input. Information managers compiling reports must wait for those steps to finish. Changes also pass through handovers and approvals, delaying their appearance in the information people use.

Two chained workflows connect people, documents, processing and data products. — *Each manual handover makes the next person’s work depend on the preceding document.*

The solution

A common language gives connected systems a shared meaning. A contract and a package of work are different things, and company names need to refer consistently to the same organisations. Dexter’s approach started with those agreements. Teams could connect their understanding of the work before they connected their software through an API.

Modular systems allowed for differences between projects. Delivery arrangements, commercial choices and data-residency requirements could all affect the software a team selected. Consistent maturity across functions mattered too. An advanced process still depended on neighbouring teams being able to supply and use its information, so uneven ways of working could create friction at the handover.

Network of construction disciplines beside principles including common language, consistent maturity and data-led intuition. — *Shared language and comparable maturity help construction disciplines exchange information.*

Those definitions form the basis of a standard data model. Converter builders map each incoming system’s data into the agreed structure, rather than adopt its API format as the standard. A warehouse can then supply reports, tables, dashboards and applications. Report users can compare information organised by the same meanings, while the team can map a replacement source system to that structure without redefining the reports around it.

Source systems connect through converters to a central data warehouse, which supplies reports, tables, dashboards and applications. — *Converters map source data into a shared structure for reports, tables, dashboards and applications.*

The data products included familiar reports and spreadsheets, generated from the shared data. Sphere was also experimenting with Morta workflows that let people interact with the information and provide feedback, alongside dashboards and bespoke applications. This gave people a route to return their judgement to the process as well as receive its outputs.

Connected workflows could carry changes through to dependent information automatically. Dexter reported some success with that approach. He also cautioned that systems make mistakes. His principle of data-led intuition put useful information in the hands of people with the experience to interpret it. Their judgement remained part of the decision.

A standard data model joins multiple workflows, with people receiving outputs on the right. — *Connected workflows could carry updates through to the people using their outputs.*

The implementation

The requirements needed to specify the information people would use. Alongside exchange requirements, that meant defining commercial information, the structure of an RFI and what constituted an issue. Information teams could use dictionaries and common taxonomies to organise those inputs consistently. A data lake, warehouse and standard data products then supported reports that users could receive in a repeatable structure across projects and reporting periods.

Moving taxonomies into and out of existing systems was a practical difficulty. Sphere used cloud infrastructure at its scale, but smaller implementations could use existing low-code tools. The intended standard was a report structure that could be reused each project or month and revised when necessary.

Slide listing requirements documentation, data dictionaries, common taxonomies, a data lake and warehouse, and standard data products. — *Requirements, dictionaries and taxonomies define the information used in storage and repeatable data products.*

Cross-checking handover information

Dexter used a generalised air-handling-unit example to show how a handover check could draw on several descriptions of the same asset. AI could read the manual, and the workflow could compare details such as manufacturer and model with the model data, requirements and commissioning records. Agreement across those sources gave the reviewer more confidence than a model check alone, while uncertain matches required a person to investigate.

A Morta workflow could return those uncertain comparisons to a handover reviewer. Sending a rejection back to the common data environment through an API was a possible extension, allowing the decision to reach that system without another manual action. It remained a proposed extension of the example.

Manuals, requirements, commissioning logs, specifications and a model feed automated comparison and exception validation. — *Comparing several descriptions of the same asset can increase confidence and expose uncertain matches for review.*

Giving a forecast useful context

Cost forecasting depended on another set of connections. Site activity, progress, payment data, commodity prices and the cost structure could classify the same work differently. In Dexter’s generalised example, common libraries and mappings connected those inputs so they could feed an automatic forecast for the commercial manager to assess.

The calculation still needed project context. A change in steel prices might point to a higher cost, while a design change or movement in other prices could alter that conclusion. The commercial manager considered those factors, adjusted the judgement and fed it back into the commercial tools. The forecast supplied evidence for that decision, with the manager responsible for interpreting what it meant for the project.

Site activity, payment data, commodity prices and a cost structure feed forecasting, human validation and commercial tools. — *Shared classifications connect cost inputs. The commercial manager adds project context and returns a judgement to the commercial tools.*

Before and after

Process	Manual starting point	Change in Dexter’s approach
Payment review	People examine information from separate inputs.	Reconciled records feed automatic checks, and reviewers investigate exceptions.
Reporting	Documents and spreadsheets pass through successive manual steps.	Shared data generates repeatable outputs, with connected workflows able to carry updates.
Handover and forecasting	An individual record or calculation offers only part of the picture.	Generalised examples combine evidence and refer uncertainty or project context to experienced people.

About Sphere Entertainment Co.

Sphere’s construction projects brought together the roles of owner, developer, constructor and operator. As Data Architect, Dexter worked on the construction-data foundations connecting those perspectives. The payment, handover and forecasting work concerned project information and decisions, separate from venue operating technology.

Presentation slide showing Sphere buildings and the owner, developer, constructor and operator roles. — *Sphere combined owner, developer, constructor and operator perspectives on its construction projects.*

What’s next

At the time of the presentation, Dexter was looking towards sensors and computer vision as further sources of site information. Hard-hat sensors, plant and people locations, and camera inputs could feed the standard data model to support understanding of progress, safety and payment. The ambition extended to anticipating a payment before an invoice arrived. These were future directions for site and commercial teams.

Site activity diagram connects sensing inputs to a standard data model, review steps and reporting outputs. — *Sensors and computer vision were a future direction for site visibility and payment prediction.*