AI-Native Shift Participant Tracking Pattern

Owner: Provost (Academy BU Leader) Status: Canonical — every ANS engagement inherits this pattern Created: 2026-05-10 First instance: Abs Company AI-Native Shift Phase 1 (inaugural deployment, kickoff Monday 2026-05-11) Companion spec: docs/plans/sanity-ainativeshift-schema-spec.md (Sanity aiNativeShift schema spec for Canon) Operational choreography: skills/ans-journey-concierge/lifecycle-orchestration.md (Spark's protocol; this file is the data substrate Spark operates against) Property substrate: skills/academy/ans-participant-tracking.md (deep substrate detail — properties, lifecycle states, associations)

---

Purpose

This pattern document specifies the canonical HubSpot data model every AI-Native Shift (ANS) engagement inherits. It defines:

• Which records represent what (Service / Project / Deliverable / Task)
• Which fields are mandatory per record type
• Which associations are required and which type IDs to use
• How Tasks are standardized with "TBD" rules
• What future ANS engagements MUST implement vs MAY customize
• What Ledger validates before writing

The Abs Company Phase 1 deployment ships Monday (2026-05-11) as the inaugural ANS engagement. Whatever pattern Ledger writes for that engagement becomes the template every subsequent ANS engagement inherits. This document exists so that template is deliberate, not improvised.

You are reading the data substrate. The full HubSpot property-level lifecycle choreography (which property changes at which cohort moment, which write goes to Ledger in what order) lives in:

• skills/academy/ans-participant-tracking.md — Provost's substrate canonical, covering Contact-level participant tracking, certification properties, Service pipeline selection, and all eight cohort moments
• skills/ans-journey-concierge/lifecycle-orchestration.md — Spark's operational choreography, covering pre-flight protocol, observation gates, and Ledger write briefs per moment

This file is the inheritance contract. Those files are the choreography. Do not duplicate; cross-reference.

---

Record types and their role

An ANS engagement produces a typed graph of native HubSpot records. The canonical role mapping:

Service (0-162) — the program engagement itself

One Service record per ANS engagement. Represents the cohort as a delivery vehicle. Pipeline reflects cohort phase progression.

• Standalone doorway (default — Abs Co Phase 1) → Service Delivery pipeline ba9cdbd6-e220-45b2-a5a2-d67ebdcbade6 [T1: skills/hubspot/property-index/service.json]
• Partnership doorway → Implementation pipeline 813553447 (per skills/academy/ans-participant-tracking.md)

The Service is the cohort identity anchor. When the Compass surface, Spark, Pulse, or Provost asks "who is in the cohort, where are they, what is happening?" — Service is the entry point. All other records associate through the Service.

Project (0-970) — organizes Deliverables within the engagement

One or more Project records per Service. A Project organizes a coherent body of work whose outputs are multiple Deliverables. The canonical example: "CRM-ERP Integration" is one Project containing smaller Deliverables (mapping document, integration spec, validation tests, go-live runbook).

Pipeline: Client Transformation pipeline t_4043571b6ea55ee4d0a461c5544239e3 for client-facing ANS Projects [T1: skills/hubspot/property-index/project.json]. Stages: Foundation Planning → Platform Build → Capability Development → Value Creation Active → Optimization & Evolution → Strategic Partnership.

Rule for when to create a Project (vs putting Deliverables directly under the Service):

• If a body of work produces 2 or more related Deliverables, create a Project.
• If a Deliverable is standalone (e.g., Target State Architecture as a single document), it may associate directly to the Service via Company↔Deliverable association without a Project wrapper.
• The inaugural Abs Co Phase 1 will likely have 1-3 Projects (CRM-ERP Integration is the named example; additional Project scope emerges from kickoff).

Deliverable (2-18484424) — per Phase 1 scope item

One Deliverable per scope artifact. A Deliverable is a discrete output: a document, an implementation, a presentation, a working POC, a training session, a strategic plan.

Pipeline selection drives the stage progression. The Deliverable custom object has 23 pipelines (per skills/hubspot/property-index/deliverable.json). For ANS Phase 1 work, the typical pipelines are:

Deliverable type	Pipeline name	Stages
Strategic plans, Target Architecture, mapping documents	Strategic Plans / Documentation	Open Stage → Requirements Gathered → Scope Accepted → First Draft Completed → First Draft Reviewed → Final Draft Completed → Training Completed → Delivered
CRM-ERP Integration, HubSpot configuration, AI agent setup	Implementations	Open Stage → Requirements Gathered → Scope Accepted → Building Started → Validation & Testing → Accepted → Launched → Delivered
Working POC artifact	Projects	Open Stage → Requirements Gathered → Scope Accepted → Project Documents Accepted → Project Started → Validation & Testing → Accepted → Delivered
Training sessions, coaching	Training / Coaching	Per pipeline definition
Transformation Presentation, capstone artifacts	Presentations	Open Stage → Closed Stage
Audits (current state, post-engagement)	Audits	Open Stage → System Reviewed → Report First Draft → First Draft Reviewed → Report Final Draft → Report Presented → Delivered

Stage ID resolution: Pipeline labels above are illustrative. Numeric stageId values must be resolved from the live portal via Ledger's pre-flight before write. The property-index has pipeline names and the 23-pipeline list but does NOT have full numeric stage IDs cached for every stage in machine-readable form [T1: skills/hubspot/property-index/deliverable.json]. This is a Wave 2 dependency Ledger handles: live-GET the Deliverable pipelines, confirm numeric IDs, never write by label.

Why Deliverable (custom 2-18484424), not Service or Listing for individual artifacts: The Deliverable object exists specifically to support pipelined work artifacts with stage tracking. Service represents the cohort engagement (one per ANS); Deliverable represents the individual outputs (many per ANS). Listing is the universal content container; the Week 3 Working POC is recorded as a Listing for content-display purposes per skills/academy/working-poc-deliverable.md, AND as a Deliverable for delivery-stage tracking. The two are complementary, not duplicative.

Task (0-27) — action items within Projects

One Task per action item. Tasks live under Projects (typed Task↔Project association). They represent discrete work units: "Schedule kickoff with ERP team," "Map Xorosoft entity to HubSpot Company custom property," "Draft AI Orchestrator role narrative for Eleni."

Task property scope: Tasks are native HubSpot objects (0-27) [T2: skills/hubspot/data-model-reference.md § Task]. Standard properties: hs_task_subject, hs_task_body, hs_task_status (NOT_STARTED / IN_PROGRESS / COMPLETED), hs_task_priority, hubspot_owner_id, hs_timestamp (due date).

Property-index gap: No task.json file exists in skills/hubspot/property-index/ [T1: directory listing confirmed 2026-05-10]. Task properties are referenced only via associations.json (typeId 922 / 923 for appointment↔task, typeId 901 for task↔listing). Flagged for Ledger Wave 2 verification: confirm Task object schema via live GET against /crm/v3/properties/tasks before first Task write, then update the property-index with task.json containing the live-confirmed property set.

---

Task TBD standardization rules

ANS engagements generate Tasks at varying readiness levels. Some have full ownership and dates; some are placeholder action items captured during planning that need a human decision before they can be assigned. The "TBD" pattern keeps both visible in the same system without pretending unresolved Tasks are operational.

When to use TBD owner (hubspot_owner_id unset)

Use when:

• The Task is genuinely captured before ownership is decided (e.g., "Identify primary integration POC at ERP side" — owner is the named POC, who doesn't yet exist as a HubSpot user)
• Ownership requires Chris or the Executive Sponsor's decision

Rule: TBD owner Tasks are NEVER created in COMPLETED status. They sit in NOT_STARTED with hs_task_subject prefixed by [TBD-OWNER] so they surface in any owner-filtered view as needing assignment.

Ledger handles TBD owner by:

• Setting hubspot_owner_id to the default Service owner (Chris) as a fallback
• Prefixing hs_task_subject with [TBD-OWNER]
• Not auto-assigning to any specific person

When to use TBD due date (hs_timestamp unset or far-future placeholder)

Use when:

• The Task is action-required but the due date depends on a prior dependency (e.g., "Draft Project Documents Accepted package — due 5 business days after kickoff" — kickoff date is concrete, but the relative date is computed downstream)
• The Task is captured during planning before the cadence is set

Rule: TBD due date Tasks are flagged with [TBD-DATE] in hs_task_subject and use a far-future placeholder (2099-12-31) for hs_timestamp to keep them sortable. Ledger NEVER writes today's date as a placeholder — that creates immediate-due Task noise.

Ledger handles TBD due date by:

• Setting hs_timestamp to 2099-12-31T00:00:00Z (placeholder)
• Prefixing hs_task_subject with [TBD-DATE]
• Recording in hs_task_body what dependency must resolve before the real date is computable

When to use TBD status (NOT_STARTED with [TBD-SCOPE])

Use when:

• The Task is a capture of "this might need to happen — confirm at kickoff" but is not yet committed scope
• The Task may be deleted post-kickoff if the conversation resolves it as not-needed

Rule: TBD status Tasks sit in NOT_STARTED with [TBD-SCOPE] prefix. They are reviewed at the Week 1 Session 1 kickoff and either:

• Committed (prefix removed, ownership and due date assigned)
• Deleted (no longer relevant)

Ledger handles TBD scope by:

• Setting hs_task_status to NOT_STARTED
• Prefixing hs_task_subject with [TBD-SCOPE]
• Including in hs_task_body the question the kickoff conversation must resolve

Combination prefixes

A Task may carry multiple TBD prefixes when multiple dimensions are unresolved: [TBD-OWNER][TBD-DATE] Map Xorosoft entity model to HubSpot custom properties — owner is unknown AND date is dependent.

Ledger's TBD validation gate

Before any Task write, Ledger checks:

1. Status NOT_STARTED for any [TBD-*] prefixed Task — never write a TBD Task as IN_PROGRESS or COMPLETED.
2. No real due date with [TBD-DATE] — if [TBD-DATE] is in the subject, hs_timestamp must be the placeholder 2099-12-31T00:00:00Z.
3. No real owner with [TBD-OWNER] — if [TBD-OWNER] is in the subject, hubspot_owner_id is the Service owner fallback (Chris), not an assigned individual.
4. hs_task_body populated for [TBD-SCOPE] — the question the kickoff must resolve must be written down.

---

Mandatory fields per record type

Every ANS engagement MUST set the following fields. Property names confirmed against property-index [T1: skills/hubspot/property-index/*.json].

Service (0-162) — mandatory

Property	Source	Notes
hs_name	property-index service_information group	Format: "{Company} AI-Native Shift {Phase}" — e.g., "The Abs Company AI-Native Shift Phase 1"
hs_pipeline	property-index service_information group	Pipeline ID, not label. Standalone: ba9cdbd6-e220-45b2-a5a2-d67ebdcbade6
hs_pipeline_stage	property-index service_information group	Stage ID (numeric or hash). Initial: 8e2b21d0-7a90-4968-8f8c-a8525cc49c70 (Scheduled / New)
hubspot_owner_id	property-index service_information group	Service owner — Chris's owner ID for VFT-led ANS
hs_start_date	property-index service_information group	Cohort kickoff date (confirmed via ./scripts/datetime.sh)
hs_target_end_date	property-index service_information group	Cohort completion target (kickoff + 4 weeks)
service_offering_name	property-index custom_service_information group	Value: "value_first_scoping" is the closest current enum option; "ai_native_shift" may need to be added — verify live enum before write
service_type	property-index custom_service_information group	Value: "capability_transfer" — the ANS program transfers capability per Empowerment Core Belief
vf_typical_duration_weeks	property-index value_configuration group	4
vf_typical_investment	property-index value_configuration group	8000 for inaugural Abs Co cap; 24995 for standard standalone
current_phase	property-index custom_service_information group	Initial value at signing: "foundation" (the enum options are foundation, foundation_advanced, automation, automation_advanced, portal_integration — ANS Week 1 maps to foundation)
total_contract_value	property-index custom_service_information group	Total commitment value (Phase 1 only for Abs Co: $8,000; Phase 1+2+3 cap: $24,000)
monthly_investment	property-index custom_service_information group	Only set if Partnership doorway — leave unset for Standalone
total_sessions_included	property-index custom_service_information group	8 per skills/methodology/ai-native-shift.md § Session Format

Property-index gap to verify (Ledger Wave 2): service_offering_name enum options listed in property-index do not currently include ai_native_shift. The closest match is value_first_scoping, which is incorrect semantically. Ledger pre-flight: GET /crm/v3/properties/services/service_offering_name and confirm whether ai_native_shift is a valid enum value. If not, brief Dean to add the enum option before write.

Property-index gap to verify (Ledger Wave 2): service_constellation_owner, service_unified_goal_contribution, service_value_path_progression_impact all show "placeholder_option" with note "Needs configuration" in the property-index — they are not yet operational enums [T1: skills/hubspot/property-index/service.json]. These should NOT be set on the inaugural write until Dean configures them.

Project (0-970) — mandatory

Property	Source	Notes
hs_name	property-index project_information.native	Format: "{Company} {Project Scope}" — e.g., "The Abs Company CRM-ERP Integration"
hs_pipeline	property-index project_information.native	Client Transformation pipeline: t_4043571b6ea55ee4d0a461c5544239e3 for client-facing ANS Projects
hs_pipeline_stage	property-index project_information.native	Initial: 1233242484 (Foundation Planning)
hubspot_owner_id	property-index project_information.native	Same as parent Service owner
hs_start_date	property-index project_information.native	Project start (often = Service start, may be later for scoped Projects)
hs_target_due_date	property-index project_information.native	Project target completion
hs_status	property-index project_information.native	Initial: on_track
project_type	property-index custom_project_information	Value: "client_transformation"
project_transformation_phase	property-index custom_project_information	Initial: "foundation"
implementation_phase	property-index custom_project_information	Initial: "recognition" (the four-phase enum: recognition → bridge → transformation → mastery — maps to the ANS Week 1 Mindset → Week 4 Scale arc)
customer_lifecycle_stage	property-index custom_project_information	Initial value at signing for Abs Co: "buyer" (per skills/academy/ans-participant-tracking.md § Lifecycle states)
project_ai_orchestration_level	property-index custom_project_information	Initial: "ai_assisted" — the AI Orchestrator role is being articulated, not yet fully active
business_impact_category	property-index custom_project_information	Per scope — Abs Co CRM-ERP Integration: "operational_efficiency"; HubSpot AI Orchestration: "innovation_pilot"
cross_pillar_connections	property-index custom_project_information	Array; for ANS Phase 1: ["ai_integration", "platform_thinking"] minimum

Property-index gap to verify (Ledger Wave 2): project_unified_goal_focus, project_value_path_target_progression both show "placeholder_option" with note "Needs configuration" [T1: skills/hubspot/property-index/project.json]. Skip these on inaugural write until Dean configures them.

Deliverable (2-18484424) — mandatory per Phase 1 scope item

The Deliverable object has 450+ properties cached [T1: skills/hubspot/property-index/deliverable.json]. The mandatory set for ANS Phase 1:

Property	Source	Notes
hs_name	property-index deliverable_information.keyProperties	The Deliverable name — descriptive: "Abs Co Target State Architecture (Week 2)", "Abs Co Working POC — CRM-ERP Integration"
hs_pipeline	property-index deliverable_information.keyProperties	The 23-pipeline list dictates choice — Strategic Plans / Documentation / Implementations / Projects / Audits / Presentations per Deliverable type
hs_pipeline_stage	property-index deliverable_information.keyProperties	Initial: Open Stage (numeric ID per pipeline — verify via live GET)
hubspot_owner_id	property-index deliverable_information.keyProperties	Owner — typically Chris for ANS unless a specific specialist owns delivery
sow_phase	property-index deliverable_information.keyProperties	For Phase 1 Deliverables: "phase_1". Phase 2/3 deferred per PRD §7 Out of Scope.

Optional but recommended for ANS:

Property	Source	Notes
content_type	property-index content_management	If the Deliverable produces visible content: "PDF Document", "Video", "Webinar", "Case study", etc.
cta, cta_link_target_type, hubspot_cta_url	property-index content_management	If the Deliverable is intended for portal/Compass display with a call-to-action
crm_record_url_slug	property-index content_management	If the Deliverable will render as a HubSpot CMS dynamic page

Task (0-27) — mandatory per action item

Properties are native to HubSpot's Task object [T2: skills/hubspot/data-model-reference.md § Task]. Property-index gap: no task.json file exists; Ledger Wave 2 must live-confirm the Task property set via GET /crm/v3/properties/tasks before first write.

Mandatory minimum:

Property	Notes
hs_task_subject	Action description. TBD prefixes ([TBD-OWNER], [TBD-DATE], [TBD-SCOPE]) per § Task TBD standardization rules above
hs_task_body	Context — what the Task is about, what dependency it resolves, what the kickoff conversation must address (for TBD-SCOPE)
hs_task_status	NOT_STARTED for any TBD Task; otherwise per actual state
hs_task_priority	LOW / MEDIUM / HIGH per scope criticality
hubspot_owner_id	Owner (or Service owner fallback if TBD-OWNER)
hs_timestamp	Due date (or 2099-12-31T00:00:00Z placeholder if TBD-DATE)

---

Association requirements

The graph that makes the ANS engagement queryable. Association type IDs confirmed against [T1: skills/hubspot/property-index/associations.json].

Required associations per Service

From	To	Association	Type ID	Category	Notes
Service	Company (the client)	Generic service-company	792	HUBSPOT_DEFINED	Only option — there is no labeled variant
Service	Contact (multiple — per stakeholder)	Client Champion	417	USER_DEFINED	For the primary champion (Abs Co: Alexia — AI-Native Shift lead)
Service	Contact (additional stakeholders)	Received By	446	USER_DEFINED	For other named participants (Abs Co: Eleni, Sean, Cindy, Kim, DJ, Sean Kirby, Michael)
Service	Deal (parent — sales process record)	n/a	n/a	n/a	Property-index gap: service_to_deal is NOT in associations.json. Ledger Wave 2 must verify via GET /crm/v4/associations/0-162/0-3/labels

Property-index gap to verify (Ledger Wave 2): The Service↔Deal association is required (parent Deal: Abs Co Phase 1 $8K, case-study rights agreed), but associations.json does not contain a service_to_deal entry [T1: skills/hubspot/property-index/associations.json]. Ledger pre-flight: live-confirm the association type ID via the HubSpot API and update the property-index before write.

Required associations per Project

From	To	Association	Type ID	Category	Notes
Project	Service	n/a	n/a	n/a	Property-index gap: project_to_service is NOT in associations.json. Ledger Wave 2 must verify via live GET
Project	Company (the client)	Client_Project	621	USER_DEFINED	Client-facing ANS Projects use Client_Project (621), NOT Internal (623) which is for Agent Operations pipeline only
Project	Contact (stakeholders)	Stakeholder For Project	458	USER_DEFINED	For client contacts on the Project (Abs Co: Eleni, Alexia, Sean as Stakeholders)
Project	Deal (parent)	n/a — use generic	per HubSpot defaults	HUBSPOT_DEFINED	Property-index gap: not in associations.json; Ledger Wave 2 verifies

Property-index gap to verify (Ledger Wave 2): Both project_to_service and project_to_deal are absent from associations.json [T1: skills/hubspot/property-index/associations.json]. Ledger live-confirms.

Required associations per Deliverable

From	To	Association	Type ID	Category	Notes
Project	Deliverable	Generic project-deliverable	571	USER_DEFINED	Standard association for Project-owned Deliverables. Use 616 (Primary Deliverable) only when one Deliverable is the named primary output of the Project.
Company	Deliverable	Generic company-deliverable	77	USER_DEFINED	Always include — the Deliverable is for the client, even when wrapped in a Project. Per wiki/conventions.md: this is the established Deliverable→Company association.
Deliverable	Contact (author / reviewer)	Deliverable Contact	102	USER_DEFINED	When a Deliverable has a named author or reviewer on the client side

Required associations per Task

From	To	Association	Type ID	Category	Notes
Task	Project	n/a	n/a	n/a	Property-index gap: no task_to_project entry in associations.json. Ledger Wave 2 verifies via live GET
Task	Listing (when Task is tied to a PRD or planning doc)	Generic task-listing	901	HUBSPOT_DEFINED	Per established pattern (see associations.json)

Property-index gap to verify (Ledger Wave 2): task_to_project is absent from associations.json [T1: skills/hubspot/property-index/associations.json]. Confirm via GET /crm/v4/associations/0-27/0-970/labels before write.

Contact-to-Company associations

Each participant Contact must associate to the client Company via Contact↔Company:

From	To	Association	Type ID	Category	Notes
Contact	Company	Leadership Team	297	USER_DEFINED	For executive participants (Abs Co: Sean Gagnon CEO, Eleni Gagnon CFO)
Contact	Company	Generic contact-company	279	HUBSPOT_DEFINED	For other participants (Cindy, Kim, DJ, Sean Kirby, Michael)

Alexia's role (AI-Native Shift lead) may warrant 297 (Leadership Team) as well — verify with Chris before write.

Contact-to-Course associations (per skills/academy/ans-participant-tracking.md)

From	To	Association	Type ID	Category	Notes
Contact	Course	Student	358	USER_DEFINED	Per-participant enrollment in the AI-Native Shift Course record

---

Inheritance contract

What every future ANS engagement MUST implement vs MAY customize.

MUST inherit (non-negotiable)

1. Service represents the cohort engagement. One Service per ANS engagement, no exceptions. Service is the identity anchor for Spark's choreography and for all cross-system queries.
2. Pipeline selection follows doorway:
   • Standalone → Service Delivery pipeline ba9cdbd6-e220-45b2-a5a2-d67ebdcbade6
   • Partnership → Implementation pipeline 813553447
3. Pipeline stages by numeric ID, never by label. Ledger live-confirms IDs before any write.
4. Project organizes coherent multi-Deliverable bodies of work. Standalone Deliverables may associate directly to Service+Company without a Project wrapper.
5. Deliverable per Phase 1 scope item. Each named scope artifact gets a Deliverable record with appropriate pipeline.
6. Service↔Company association is always type 792 (HUBSPOT_DEFINED — only available option).
7. Service↔Contact uses Client Champion (417) for primary, Received By (446) for additional stakeholders.
8. Project↔Company uses Client_Project (621) for client-facing engagements (NOT 623, which is for Agent Operations internal projects).
9. Company↔Deliverable uses type 77 (the established VFT pattern).
10. Task TBD standardization rules apply universally — [TBD-OWNER], [TBD-DATE], [TBD-SCOPE] prefixes with their corresponding placeholder conventions.
11. Empowerment-over-dependence certification gate. Per skills/academy/ans-participant-tracking.md § Certificate properties: certification requires all four assessments (Trap Assessment, Target Architecture, Working POC, Transformation Presentation). Three of four is honestly recorded, not certified.
12. No forbidden language anywhere in record fields. Per wiki/conventions.md § Language rules: no leads, prospects, conversion, funnel, MQL/SQL, nurture, targets, closed-won, quick wins, fastest path. Ledger scans the write payload.
13. Sanity aiNativeShift document per engagement. Per docs/plans/sanity-ainativeshift-schema-spec.md: one Sanity document per ANS engagement instance, slug {company-slug}-phase-{n}, holding curriculum-anchored content fields (relationship arc, AI Orchestrator articulation, Phase scope summary) that complement (do not duplicate) HubSpot's operational record.

MAY customize (per engagement)

• Number of Projects per Service. Abs Co Phase 1 may have 1-3 Projects; another engagement may have just one or none if all Deliverables are standalone.
• Specific Deliverable pipelines used. Driven by the type of artifact — Strategic Plans, Implementations, Documentation, etc.
• AI Orchestrator role assignment. Per skills/methodology/ai-native-shift.md and Abs Co PRD FR-7: default Alexia-archetype; Abs Co assignment likely Eleni; future engagements assign to the appropriate archetype.
• Participant count. ANS requires 5-8 per skills/methodology/ai-native-shift.md; the exact count per engagement varies.
• Doorway (Standalone vs Partnership). Drives Service pipeline choice. Abs Co Phase 1 is Standalone at the $8K inaugural cap.
• Compass surface URL pattern. Abs Co is at compass.valuefirstteam.com/abs-company; future engagements follow the same compass.valuefirstteam.com/{client-slug} pattern.

Phase 2 / Phase 3 scope

Phase 2 and Phase 3 are out of scope for this inaugural pattern document. Per Abs Co PRD §7 Out of Scope: Phases 2/3 are scope-separate engagements (each capped at $8K for Abs Co). When a future ANS Phase 2 begins, the pattern is:

• A new Service record is created (do not advance the Phase 1 Service to a Phase 2 stage — Phase 2 is a separate engagement, not a continuation pipeline state).
• The new Service associates to the same Company.
• The same Contact participants associate (with any team additions).
• A new parent Deal record exists for Phase 2's commercial commitment.
• The sow_phase property on new Deliverables is "phase_2".

This preserves the inaugural pattern integrity: each ANS phase is one Service, regardless of how many phases a client purchases.

---

Validation requirements (Ledger pre-flight)

Before writing any record per this pattern, Ledger validates:

1. Property-index integrity

• Every property in the write payload exists in the cached property-index [T1: skills/hubspot/property-index/{object}.json].
• If a property is not in the cached index, stop and live-GET via /crm/v3/properties/{object} to confirm. Update the property-index with the live-confirmed schema before write. Never write a property that hasn't been confirmed.
• Per wiki/conventions.md § HubSpot data conventions: "Property-index files reflect verified-live state, not intended state."

2. Pipeline and stage ID resolution

• hs_pipeline is set by ID, not label.
• hs_pipeline_stage is set by ID, not label.
• If the property-index has the pipeline name but not the numeric stage ID, stop and live-GET via /crm/v3/pipelines/{object} to resolve.

3. Association type ID and category

• Every association type ID exists in skills/hubspot/property-index/associations.json [T1].
• Association category (USER_DEFINED vs HUBSPOT_DEFINED) matches what associations.json documents.
• Per wiki/conventions.md: "The api.js associate command defaults to --category HUBSPOT_DEFINED. Custom association labels are USER_DEFINED. Pass --category USER_DEFINED for any custom label."

4. Forbidden language scan

• Scan all string fields in the write payload for: leads, prospects, conversion, funnel, MQL, SQL, nurture, targets, closed-won, quick wins, fastest path.
• Per wiki/conventions.md § Language rules. Reject the write if any hit.

5. Datetime confirmation

• Any date field (hs_start_date, hs_target_end_date, hs_target_due_date, hs_timestamp, certificate issuance dates) is set from ./scripts/datetime.sh output, never from model-inferred dates.
• Per wiki/conventions.md § Date and time conventions.

6. Single-item test gate

• When creating 5-8 Contact↔Service or Contact↔Course associations at cohort kickoff, write one first, fetch back via hubspot-batch-read-objects, confirm the side effect, then batch the rest.
• Per wiki/conventions.md § Engineering standards.

7. Post-write GET verification

• After every create or update, fetch the record back and confirm field values.
• HTTP 200 status with wrong field values has happened. Per wiki/agent-guide.md § Verification before completion: never claim a write complete based on status alone.

8. Task TBD prefix consistency

• Any Task with [TBD-*] prefix in hs_task_subject is in NOT_STARTED status.
• Any Task with [TBD-DATE] prefix has hs_timestamp = 2099-12-31T00:00:00Z.
• Any Task with [TBD-SCOPE] prefix has populated hs_task_body describing the question the kickoff must resolve.
• Any Task with [TBD-OWNER] prefix has hubspot_owner_id set to the Service owner fallback (not assigned to an arbitrary individual).

---

Property-index gaps consolidated (for Ledger Wave 2 verification)

The following gaps must be resolved via live HubSpot API verification before the inaugural Abs Co Phase 1 writes proceed:

Gap	Location	Resolution required
No task.json file	skills/hubspot/property-index/	GET /crm/v3/properties/tasks and write task.json with the live-confirmed property set
service_offering_name may not include ai_native_shift enum	skills/hubspot/property-index/service.json custom_service_information	GET /crm/v3/properties/services/service_offering_name; if missing, brief Dean to add the enum option before any Service write
service_constellation_owner, service_unified_goal_contribution, service_value_path_progression_impact are placeholder enums	skills/hubspot/property-index/service.json	Skip these on inaugural write; flag to Dean for configuration
project_unified_goal_focus, project_value_path_target_progression are placeholder enums	skills/hubspot/property-index/project.json	Skip these on inaugural write; flag to Dean for configuration
Deliverable pipeline numeric stage IDs	skills/hubspot/property-index/deliverable.json	The 23-pipeline list has names but full numeric stage IDs are not exhaustively cached. Live-GET /crm/v3/pipelines/2-18484424 and resolve all stage IDs Ledger plans to use for Phase 1 writes
service_to_deal association	skills/hubspot/property-index/associations.json	GET /crm/v4/associations/0-162/0-3/labels; record the type ID and category in associations.json
project_to_service association	skills/hubspot/property-index/associations.json	GET /crm/v4/associations/0-970/0-162/labels; record
project_to_deal association	skills/hubspot/property-index/associations.json	GET /crm/v4/associations/0-970/0-3/labels; record
task_to_project association	skills/hubspot/property-index/associations.json	GET /crm/v4/associations/0-27/0-970/labels; record
Certificate properties (certificate_ai_native_shift_*)	skills/hubspot/property-index/contact.json	Per skills/academy/ans-participant-tracking.md: certificate property set is not yet provisioned. Dean creates certificate_ai_native_shift_issued (bool), certificate_ai_native_shift_issued_date (date), certificate_ai_native_shift_cohort_id (string), certificate_ai_native_shift_url (string) before Phase 1 Moment 6 (Week 4 Session 2 certification issuance)
education_engagement_score property on Contact	skills/hubspot/property-index/contact.json	Per skills/academy/ans-participant-tracking.md: required for Moment 2 (Week 1 Session 1) attendance scoring. Dean confirms property exists and is the correct numeric type before Phase 1 Moment 2.

Total property-index gaps flagged: 11.

---

Spark coordination note

Spark's skills/ans-journey-concierge/lifecycle-orchestration.md (v1.1, shipped by Skill Backfill session) is the operational choreography that operates on top of this pattern. Spark's file defines the 8 cohort moments and the per-moment Ledger write briefs. This pattern document defines the data model Spark's choreography presumes.

Per the Skill Backfill session close, Spark v1.1 has open dependencies that map to gaps flagged above:

• certificate_* properties + education_engagement_score need Dean to provision live before Phase 1 Moment 6 (certification issuance) — see Property-index gaps consolidated table above.

These dependencies are tracked here so Ledger and Dean know what to verify before Phase 1 reaches the Moment 6 certification gate (Week 4 Session 2). They do NOT block the inaugural kickoff (Monday 2026-05-11) because the certification moment is at the end of Week 4, ~4 weeks out.

Spark was not called inline for this pattern document. Spark's v1.1 skill already covers the operational layer comprehensively; this document is the data-substrate companion. If a future ANS engagement requires journey-concierge-specific extensions to the pattern, Spark can be spawned at that time.

---

Related

• docs/plans/sanity-ainativeshift-schema-spec.md — companion Sanity aiNativeShift schema spec for Canon (Wave 2 deploy)
• skills/academy/ans-participant-tracking.md — Provost's deep substrate detail (Contact properties, certificate properties, lifecycle states per cohort moment)
• skills/ans-journey-concierge/lifecycle-orchestration.md — Spark's operational choreography (the 8 cohort moments and per-moment Ledger write briefs)
• skills/methodology/ai-native-shift.md — ANS program-shape canonical (4-week structure, doorways, session format)
• skills/hubspot/property-index/service.json — Service object schema
• skills/hubspot/property-index/project.json — Project object schema
• skills/hubspot/property-index/deliverable.json — Deliverable object schema
• skills/hubspot/property-index/associations.json — association type IDs
• skills/enforcement/ledger-gateway-override.md — Ledger write gateway protocol
• wiki/conventions.md § HubSpot data conventions — property-index verification rule
• wiki/conventions.md § Date and time conventions — datetime discipline
• wiki/conventions.md § Language rules — forbidden-language rules
• docs/plans/abs-company-ai-native-shift-launch-prd.md — Abs Company inaugural deployment PRD (FR-2, FR-9, FR-10 implement this pattern)