Corrective Action: Paragon Account Data Drift — Portal Hiding 60% of Client Data

← Back to Corrective Actions 2026-03-10

Corrective Action: Paragon Account Data Drift — Portal Hiding 60% of Client Data

Date: March 10, 2026 Category: Verification Failure / Missing Operational Process Impact: Paragon ($340K implementation client) could only see ~40% of their portal data. 24 deliverables invisible. 1 document invisible. 6 orphan records. Stale properties across company, project, service, and contact records. Config.yaml 6 weeks behind actual state. Resolution Time: ~30 minutes (audit + remediation in same session)

Incident

What Happened

A comprehensive audit of the Paragon account across HubSpot, the VIP Portal, and local repository files revealed systemic data drift. The portal navigation was missing 7 sections that had data behind them — most critically, the projectProgress section that would expose 24 tracked deliverables. A document was invisible due to the exact listing_content_type bug already documented in Critical Lessons (Mar 2). The project record hadn't been updated in 24 days. The service record hadn't been updated in 54 days. Config.yaml still showed "Phase 1, Month 1" when the project is in Phase 2, Month 3. All 7 Paragon contacts had null values for vf_value_path_current_stage and vf_last_engagement_date despite weekly sessions.

Timeline

Time Event
Jan 14, 2026 Paragon portal initially configured with 8 nav sections, 10 listings created (6 never populated)
Jan 25, 2026 Last config.yaml deliverable status update
Feb 7, 2026 TM Equipment listing created with listing_content_type: "deliverable_doc" (invisible in portal)
Feb 14, 2026 Last project record update in HubSpot (24 days stale by Mar 10)
Jan 15, 2026 Last service record update in HubSpot (54 days stale by Mar 10)
Mar 10, 2026 Audit agents (audit + pavilion) run in parallel, complete reports
Mar 10, 2026 Remediation applied: 14 HubSpot updates, 3 config.yaml edits

Root Cause

There is no operational process that verifies client account health across the three systems (HubSpot, portal, local config) on a recurring basis. Each system drifts independently:

  1. HubSpot records are created during onboarding but only updated when someone explicitly works on them. No agent or process checks for staleness. The project stage sat at "Platform Build" for 24 days while actual work progressed through capabilities, permissions, workflow automation, and production migration.

  2. Portal navigation is set once during portal activation and never revisited as new data accumulates. Paragon's 24 deliverables were tracked in HubSpot but never surfaced in the portal because projectProgress wasn't added to the navigation JSON when the deliverables were created.

  3. Config.yaml is treated as a setup artifact, not a living document. It was last meaningfully updated Jan 25 — 6 weeks of session cadence changes, deliverable progress, and meeting format evolution went unrecorded.

  4. Contact properties (vf_value_path_current_stage, vf_last_engagement_date) are never updated by any automated process. They require manual population, which doesn't happen.

  5. The listing_content_type bug recurred. On Mar 2, we documented that portal Documents filter on listing_content_type === 'document' (exact match). Despite this being in Critical Lessons, the TM Equipment listing created on Feb 7 had listing_content_type: "deliverable_doc" — the exact same bug. The lesson existed but was never applied retroactively to existing records.

Category: Missing Operational Process

This is not a single mistake. It's the absence of a verification loop. Data was created correctly at the point of creation but degraded over time because nothing checked it afterward. The audit agents (audit + pavilion) proved they can detect these issues — they just weren't running on any cadence.

Fix Applied

Immediate Resolution

14 HubSpot updates and 3 config.yaml edits applied in a single session:

HubSpot Changes

Object ID Property Old Value New Value
Listing 528696393217 listing_content_type deliverable_doc document
Listing 528696393217 name null TM Equipment — HubSpot Product Property Mapping
Listing 536159445678 name null Ownership, Permissions & Views
Listing 536587312759 name null February Deliverables Summary — Foundation
Listing 536587312760 name null User Types, Interfaces & Permissions
Company 47452018795 vf_engagement_trend stable increasing
Company 47452018795 vf_renewal_likelihood null very_high
Company 47452018795 vf_risk_factors null (populated with current assessment)
Company 47452018795 portal_navigation 8 sections 14 sections (+projectProgress, schedule, support, dataModel, pipelines, hubspotPortal)
Project 516521950881 hs_pipeline_stage Platform Build (1233242485) Capability Development (1233242486)
Contact 186382217139 jobtitle null Operations Manager
Contacts 4 records vf_value_path_current_stage null value_creator
Contacts 4 records vf_last_engagement_date null 2026-03-06 / 2026-03-10

Config.yaml Changes

Section Old New
project.current_phase Phase 1 Phase 2
project.current_month 1 3
meetings.schedule Weekly Wednesday demo Tue/Thu workshops + Friday reviews
project.deliverables 6 items updated Reflects actual progress (complete/in_progress)

Verification

All HubSpot batch-update calls returned "status": "COMPLETE". Portal navigation JSON confirmed stored correctly on company record.

Prevention Measures

Rules Added

Layer File Rule
Critical Lessons memory/MEMORY.md Run audit + pavilion agents on any client before major milestones (contract signing, phase transitions, steering committees). Portal navigation, listing content types, property staleness, and config.yaml drift are invisible until someone checks. The audit on Mar 10 found Paragon's $340K portal showing 40% of available data. No single session caused this — it accumulated over 6 weeks of sessions without a verification loop.
Self-Correction skills/enforcement/vf-self-correction.md Detection trigger: "When creating a Listing with any listing_content_type value, verify it matches the portal filter. Documents section requires exact value document. Any other value is invisible."
Self-Correction skills/enforcement/vf-self-correction.md Detection trigger: "When creating Deliverable records for a client, verify projectProgress is in their portal_navigation. Deliverables without portal navigation are invisible to the client."

Detection Triggers

  1. Listing content type at creation time. Whenever a Listing is created, the system should validate listing_content_type against the intended portal section. This was a known bug (Mar 2) that recurred because the lesson was reactive (check existing records) not proactive (validate at creation time).

  2. Portal navigation at deliverable creation time. When batch-creating Deliverables for a client, the system should check whether projectProgress is in portal_navigation. If not, flag it.

  3. Config.yaml staleness. When processing a transcript or writing a session synthesis for a client, check if project.current_phase and meetings.schedule in config.yaml still match the session content. If they diverge, flag for update.

Lessons

The absence of a verification loop is itself a failure mode. Data drift is not caused by a single mistake — it's caused by the gap between "creating data" and "verifying data remains accurate over time." The audit agents proved they can detect all of these issues in under 6 minutes combined. The capability exists. What was missing was the trigger to run them.

This reinforces a broader principle: creation without verification is incomplete work. Every record created in HubSpot, every config.yaml field populated, every portal section enabled — each has a shelf life. Without periodic verification, confidence in the system's accuracy degrades silently.

Related Incidents

Date Incident Relationship
Mar 2, 2026 Portal Documents filter on listing_content_type === 'document' (exact match) Direct recurrence. The TM Equipment listing was created 5 days after the original incident was documented. The lesson existed but wasn't applied to the Feb 7 record retroactively.
Mar 8, 2026 Calendar invitees reported as attendees (15 vs actual 5) Same pattern. Data existed (calendar invites) but was never verified against ground truth (transcripts). Verification failure.
Mar 8, 2026 CRLF line endings in .env files Same pattern. Configuration set once during creation, never verified afterward. 29 files drifted silently for weeks.

Unresolved Items (Require Human Input)

Item Action Needed
John Rago duplicate contacts (189927288132 + 183139814714) Merge decision — which email/record is primary
3 Morley family members missing emails Collect from Paragon team
6 empty orphan listings (created Jan 14, never populated) Delete or populate
Service record 519884803217 unnamed name property may not be writable via API — verify in HubSpot UI