Pre-Flight Protocol

Run this protocol before implementing any HubSpot-related work. Purpose: surface assumptions, catch bias errors, validate approach against VF Platform architecture.

When to Run

• Before writing any HubSpot API calls
• Before creating/modifying HubSpot schemas
• Before generating specifications involving HubSpot
• Before any operation that touches VF Platform data

Protocol Steps

Step 1: Object Verification

List every HubSpot object you plan to use:

Object	Type ID	Native/Custom	Verified?

Verification check:

• If any object is marked "Custom" and isn't Deliverable (2-18484424), Interest (2-54301725), or Investment (2-53994804) → STOP
• You have a bias error. The object you're assuming exists doesn't exist.
• Reconsider your approach using only native objects + Deliverable + Interest + Investment.

Step 2: Association Verification

List every association type you plan to create or query:

From Object	To Object	Type ID	Direction	Verified?

Verification check:

• Cross-reference against known association types
• If you don't know the type ID, look it up with hubspot-get-association-definitions
• Do not assume associations exist

Known association types:

Association	Type ID
Task → Project	1247
Project → Task	1246
Project → Company	1237
Deliverable → Project	572
Deliverable → Company	77
Task → Deliverable	42
Appointment → Project	490
Appointment → Company	909

Step 3: Property Verification

For each object, list properties you'll read or write:

Object	Property	Read/Write	Verified Exists?

Verification check:

• Sample a record to confirm properties exist
• Never use hubspot-list-properties on complex objects (times out)
• Use hubspot-list-objects with limit=1 to sample

Sample query pattern:

hubspot-list-objects
objectType: [object-type]
limit: 1
properties: [properties-you-expect]

If property returns null or doesn't appear, it may not exist or may have different internal name.

Step 4: Pattern Verification

Check your planned approach against forbidden patterns:

Check	Status
No hardcoded client configuration (IDs, slugs in code)	☐
No calendar-based phases ("Week 1-2", "Phase 1")	☐
No fallback/quick-win framing	☐
No custom objects beyond Deliverable/Interest/Investment	☐
No hubspot-list-properties on complex objects	☐
No assumptions about object existence without verification	☐
HubSpot is source of truth (not config files)	☐

If any check fails → revise approach before proceeding.

Step 5: Approach Statement

Before proceeding, state your approach in one paragraph:

I will [action] using [objects] with [associations]. Configuration will be stored in [location]. The target state is [complete description]. This requires [genuine dependencies] to exist first.

Review this statement for:

• Scope hedging ("start with", "initially", "phase 1")
• Calendar language ("by week 2", "over 4 weeks")
• Fallback framing ("if time permits", "quick win")

If any detected → rewrite before proceeding.

Pre-Flight Complete

When all steps pass, proceed with implementation.

If any step fails:

1. Do not proceed
2. Identify the bias or assumption error
3. Revise approach
4. Re-run pre-flight protocol

Quick Reference

Only 3 custom objects:

• Deliverable (2-18484424)
• Interest (2-54301725)
• Investment (2-53994804)

Everything else is native. Including: Project, Task, Appointment, Course, Listing, Service, Quote, Invoice, Order, Cart.

If you're uncertain whether an object is native or custom: It's native. The only custom objects are the three listed above.