How True Data works

• Predict ranges. True Data provides distributions for estimated ranges implied by what you currently know about the project, combining statistical inference from cohort distributions with “stretch-to-fit” scaling of comparable projects' design breakdowns to your known dimensions.
• Compare project values to cohort-derived ranges. When you have a value for your project, e.g. a skin-to-floor ratio or an estimated cost per square foot, we show where it falls in the distribution of comparable projects and how the cohort set compares with your project across both quantitative and qualitative criteria.

Cost is normalized to the UniFormat Level 2 elemental level and, where needed, escalated for time and location to make projects comparable. We stop there for anonymous market data we do not show detail below Level 2.

Data points come from the primary artifacts a project team generates at a GMP or other design-phase milestone, the same records the team relies on and uses to communicate with the owner as the project progresses:

• Program & requirements documents. The owner's program, basis of design, and requirements — unit and bed counts, department areas, finish quality, and certification targets like LEED — that explain why a project's numbers land where they do.
• Estimates Cost of Construction estimates which we normalize to UniFormat Level 2; owner cost models including land acquisition, financing, soft costs, and FF&E.
• Schedules Milestones and the durations between them extracted from the project schedule.
• Models & Drawings 3D models, architectural and engineering drawings, from which the design-efficiency ratios and program quantities that other sources don't capture directly are derived.
• Specifications The written specifications that accompany the drawings detailing the materials, systems, and quality standards. These qualify the finish and performance level behind a project's cost and design figures.

• Your data.Full detail Projects from your own organization. For these project you see everything and can inspect both the processed records and the primary sources. You may have additional cost codes or other data associated with your organization's own projects that you use in benchmark reports but that remains private to other members of your organization.
• Peer data.Individual points If you belong to a peer group whose members have agreed to share with each other, you see the group's projects as individual data points — but only the fields captured in the standardized contribution format, and nothing beyond that. Counts are exact, since a group you're part of isn't anonymized to you; the distributions still pass through the same privacy protections as market data.
• Market data.Aggregate only Anonymized, aggregated data from every contributing organization. It appears only as aggregate distributions across cohorts of comparable projects, never as individual, identifiable projects. It is the largest set, and the privacy protections below govern it.

The more of these a benchmark can draw on, the more comparable projects stand behind it — but only your own data is ever shown in full.

A processing pipeline conditions data from primary sources into a consistent, comparable shape, mapping costs to a common elemental taxonomy, aligning schedule milestones, and tagging the program drivers that define a project's cohort. This normalization is reviewed by people with deep domain expertise, and the conditioned project data is available through an API for use in other applications. This conditioning is offered as a service to address the (often substantial) burden of data conditioning that makes it difficult for organizations to use their own historical data confidently.

Qualification is the gate that decides whether a conditioned project datapoint is sound enough to be included in market benchmarks: we check that its milestone, estimate, and program are internally consistent and complete before it's allowed to influence any distribution. Datapoints that can't be reconciled are held back from anonymized market cohorts rather than allowed to distort a benchmark. This is applied by default to own-data cohorts as well, but you can still access the partial datapoint and choose to use these projects where appropriate

Want the specifics? See the data format every contribution is normalized to.

• Fuzzy membership. Cohorts are seeded from relevant attributes like type, sector, region, delivery method, finish level, and floor-area range that correlate with benchmarked values. A cohort is not an exact match on every parameter, and you can inspect cohort composition for each attribute.
• Interactive slicing. Drill into an attribute donut chart (e.g. sector or wage basis) or filter a shown distribution (e.g. total GSF) to refine a cohort or build a new one. Slice however you like for your own data, or use defined privacy-controlled cohorts with market data.
• Side-by-side comparison. Compare multiple cohorts at once — “union vs. open shop,” or “this metro vs. national” — to see how a single attribute moves the numbers.

A benchmark is only as useful as your ability to understand what kind of projects back it, so cohort composition including attribute distributions, and approximate size are visible.

In market data benchmarks, a contributing project is never shown to other users directly. It is surfaced only in aggregate distributions across cohorts of similar projects, never as identifiable individual values. We're building the privacy layer on the techniques of differential privacy — the approach used by the U.S. Census Bureau and Apple — which adds calibrated noise and caps how much any single project can affect what's shown. That is what prevents reconstructing an individual project's underlying information from any benchmark view or combination of views while allowing members to draw on a broad industry data set to power their analysis.