Framework reference

Data Foundation Audit Framework

A named, five-layer inspection methodology for HubSpot portals that determines whether the data can support reliable reporting and automation before anything is built on top of it.

The Capstan Works Data Foundation Audit Framework inspects five layers of a HubSpot portal - property hygiene, lifecycle integrity, association completeness, deduplication state, and workflow dependencies - to determine whether the data can support reliable reporting and automation before anything is built on top of it.

Why a named framework

A methodology earns the name "framework" when it is repeatable, numbered, and produces the same outputs in the same order on every engagement, regardless of portal size or industry. The Data Foundation Audit Framework does that: five fixed layers, inspected in sequence, each producing a defect list ranked by blast radius. The sequence is not arbitrary. Each layer feeds the next. Property hygiene must come before workflow dependencies, because the dependency map is only valid once you know which properties are authoritative.

The framework is grounded in the audit work described in the HubSpot Data Foundation Audit service and the operating method on How we operate. Everything here is derived from that real engagement model.

The five layers

Layer 1

Property Hygiene

What it inspects: Inspects every property across all CRM objects to identify dead fields, near-duplicate fields, and the active set that actually carries the reporting load.
Defects it surfaces: Dead properties with no reads or writes in active workflows or reports; near-duplicate fields that split the same concept across two names; custom properties that shadow default HubSpot fields and produce attribution conflicts.
Why it matters: Every unused property is a surface where future automation can write to the wrong field. Near-duplicates cause attribution to silently split between two storage locations, so the same metric produces different numbers depending on which field a given report queries. Rationalized properties are the prerequisite for any trustworthy dashboard.

Layer 2

Lifecycle Stage Integrity

What it inspects: Reconciles the internal lifecycle stage value stored on each record against the displayed label, the agreed definition, and the sequence of transitions recorded in the audit log.
Defects it surfaces: Renamed default stages where the internal value diverges from the label a human reads; records stuck in a stage past a defined threshold; stage regressions with no documented reason; contacts or companies whose stage contradicts the status of their associated deals.
Why it matters: Lifecycle stage is the spine of the funnel. A renamed stage lets a dashboard appear consistent while the values underneath it represent two different populations, making conversion math an artifact of label history rather than a measure of actual performance. Correct stage integrity is the prerequisite for any conversion report.

Layer 3

Association Completeness

What it inspects: Measures the coverage of relationships between CRM objects: contacts to companies, deals to contacts, deals to companies, and tickets to the records that own them.
Defects it surfaces: Orphaned deals with no associated company, preventing territory and segment attribution; contacts not linked to a company, breaking account-level rollups; deals with no associated contact, severing activity history from the pipeline record.
Why it matters: Associations are the connective tissue of account-based reporting. A deal not linked to a company cannot be forecasted by segment, attributed by region, or rolled up in an account health score. Coverage gaps here propagate into every report that counts by account rather than by individual record.

Layer 4

Deduplication State

What it inspects: Measures the duplicate rate across contacts and companies using a multi-key scan: exact email, normalized domain, and a fuzzy match on name plus phone number.
Defects it surfaces: Duplicate contacts that split activity history and assign two owners to the same buyer; duplicate companies that double headcount and halve apparent conversion rates; merge backlog that has accumulated to the point where automated rules produce more merges than human review can validate.
Why it matters: Duplicate records corrupt every metric that counts entities. Two records for one company double the pipeline, halve the conversion rate, and route two owners to the same buyer. Unlike most data defects, duplicates compound: each merge delayed is a period of wrong reporting that cannot be retroactively corrected after the fact.

Layer 5

Workflow Dependencies

What it inspects: Maps every active workflow to the properties it reads as enrollment criteria and the properties it writes as actions, producing a dependency graph that shows where automations conflict or chain silently.
Defects it surfaces: Race conditions where two workflows write to the same property on the same trigger, producing results that depend on execution order; orphaned workflows that enroll records against criteria no longer valid; circular chains where workflow A triggers workflow B, which re-triggers A; workflows whose names do not match their actual logic.
Why it matters: Workflows are the most dangerous place to have undocumented dependencies because their effects are invisible until something breaks. A property rationalization that retires a field mid-audit can silently disable the enrollment filter of a revenue-critical automation. The dependency map is the prerequisite for changing anything safely.

How the audit runs

The framework runs as a fixed-scope, fixed-fee engagement: a 60-minute scoping call followed by 10 to 12 business days of inspection across all five layers. The output is a 20 to 25 page defect register in which each finding names the layer it sits in, the downstream reports or workflows it breaks, and a remediation estimate ranked by impact and effort. The engagement closes with a 60-minute live debrief. The same five layers run on every portal. Nothing is skipped because the portal "looks clean."

Start with a Data Foundation Audit