How does DEPLOY track partnership lifecycle state?

Why partnership lifecycle is editorially central to the framework

Partnership lifecycle state sits at the intersection of verification posture and relationship-graph granularity. The verified-vs-claimed framework operates uniformly across entity records, deployment records, incident records, and now relationship records. The discipline that distinguishes DEPLOY's partnership framework from the broader announcement-discourse cohort: a partnership announcement is not a partnership in active state, and a partnership in active state is not a partnership-of-record at primary-source-anchored verification depth. Each transition between lifecycle states corresponds to a distinct verification posture; the framework reads partnership records at the lifecycle state where each fact actually resolves.

The framework operates at canonical-methodology depth, not at marketing-announcement depth. The product differentiator: DEPLOY's framework treats partnership lifecycle the same way it treats every other verified-vs-claimed claim. Honest "announced but lifecycle-not-verified-since" beats fabricated "active partnership" framing.

---

The four-state partnership lifecycle framework

Per Agent A's Arc C substrate (18 partnerships + 32 parties + 14 external via XOR pattern), the partnership lifecycle framework operates at four canonical states. Each state has a distinct verification posture, a distinct primary-source anchor, and a distinct cap-flag honest-absence layer.

State 1: announced. The partnership was disclosed via press-release or company-statement; counterparty identification verified; partnership scope verified at announcement-tier depth; current operational status not yet verified at deployment-tier depth. The framework reads announced state as verified-at-announcement-depth + cap-flag-honest-absence-at-deployment-tier. Press-release reading is at reputable-press source-quality-tier depth per the 9-tier source-quality rubric; not at primary-source-anchored verification depth.

State 2: active. The partnership transitioned from announced to verified-deployed or verified-shipped. Active state requires either a deployment record (Figure 02 at BMW Spartanburg 30,000 vehicles; Apptronik Apollo at Mercedes-Benz pilot facilities; Agility Digit at GXO Flowery Branch 100,000 totes) or a shipped-product record (Wayve × Stellantis STLA AutoDrive commercial integration). Active state reads at primary-source-anchored verification depth; the partnership record carries current_status=true; current-state cap-flag operates only at sub-claim depth (specific operational scale + throughput + economic terms).

State 3: dissolved. The partnership terminated. Per Agent A's Arc C substrate, dissolved state requires current_status=false + end_date populated. The canonical worked example: Figure × OpenAI announced 2024 → dissolved February 2025 (status=dissolved + endDate populated; verified at primary-source company-statement depth). Dissolved state operates at verified-termination depth; the framework reads termination as substantive editorial state change, not as soft-decay.

State 4: unverified-current-state. The partnership was announced but operational state has not been re-verified since announcement. The framework reads unverified-current-state as honest-absence cap-flag at lifecycle depth. The 1X × OpenAI partnership operates at this state per Agent A precedent (announced + reported-not-verified with explicit lifecycle-verify flag per Figure × OpenAI precedent). Cap-flag-as-trust-signal operates at lifecycle depth: the absence of post-announcement primary-source verification is the editorial truth, not an inference of active or dissolved state.

---

Figure × OpenAI dissolution as canonical lifecycle precedent

The Figure × OpenAI partnership operates as the canonical lifecycle precedent across the cohort. The announcement (2024) verified Figure receiving custom AI models from OpenAI for humanoid platform integration; the partnership reached active state at announcement-tier verification. February 2025 verified dissolution per primary-source company-statement; the partnership transitioned to dissolved state with end_date populated.

The precedent establishes the discipline at three layers:

• State-transition primary-source anchoring: each lifecycle state transition requires primary-source verification at announcement-tier or termination-tier depth. The framework does not infer dissolution from announcement-decay or active state from time-since-announcement.
• End-date specificity: dissolved state carries specific end_date verified at primary-source depth. The framework reads end_date as primary-source-anchored at month-precision minimum; year-precision operates at honest-absence cap-flag.
• Lifecycle-verify flag for unverified-current-state: when a partnership has been announced but operational state has not been re-verified since announcement, the framework reads the partnership at honest-absence cap-flag with explicit lifecycle-verify flag. 1X × OpenAI operates at this posture per Figure × OpenAI precedent.

---

The external-name XOR pattern as verification-posture discipline

The external-name XOR pattern operates at relationship-graph granularity. Per Agent A's Arc C substrate, partnership_parties carries either company_id (when counterparty is a tracked entity in the registry) or external_name (when counterparty is genuinely not-in-registry). The XOR CHECK constraint at the schema layer enforces correctness: exactly one of the two fields is populated per party record.

The pattern operates at three editorial layers:

• Tracked-entity primary-source-anchoring: when counterparty is tracked, company_id carries primary-source verification at entity-record depth. Partnership records inherit the verified-entity-record verification posture for that counterparty.
• External-name honest-absence first-class: when counterparty is genuinely not-in-registry (the canonical worked examples include OpenAI, Uber, Nissan, Microsoft), external_name carries the verification posture at honest-absence tier. The framework reads not-in-registry as the editorial truth, not as inference-of-existence at lower verification depth.
• Schema-layer XOR CHECK as discipline-enforcement infrastructure: structural XOR CHECK at the database layer enforces correctness. The framework treats discipline-enforcement infrastructure as load-bearing; the alternative (convention-only) operates at substantially lower verification depth at scale.

For the broader discipline-enforcement infrastructure pattern, see DEPLOY's editorial process (editorial cleanliness + type-safety gates + per-page commit cadence operate at the same discipline-enforcement infrastructure tier).

---

Cross-cohort partnership pattern taxonomy

The 18-partnership substrate surfaces a structurally-meaningful cross-cohort pattern taxonomy. The framework reads four canonical pattern classes:

Humanoid manufacturing partnerships. The cohort with the deepest partnership-record substrate. Verified worked examples: BMW × Figure (Figure 02 at BMW Spartanburg deployment; 30,000 BMW X3 vehicles + 1,250 hours runtime); Mercedes × Apptronik (Apptronik Apollo Mercedes deployment; dual-facility European pilots); Hyundai × Boston Dynamics (Atlas Hyundai Metaplant deployment; corporate-parent relationship per maker-facility rule); Jabil × Apptronik; Foxconn × NVIDIA. The framework reads humanoid manufacturing partnerships at end-product OEM acceptance verification depth where the deployment substrate supports (Figure 02 at BMW Spartanburg as canonical).

Humanoid logistics deployment partnerships. Verified worked examples: GXO × Apptronik (Apollo enterprise pilots); GXO × Agility (Digit at GXO Flowery Branch 100,000 totes scaled-throughput); Catalyst Brands × Figure (Figure 03 at Catalyst Brands Reno deployment). The framework reads humanoid logistics partnerships at scaled-throughput verification depth where the deployment substrate supports (Agility Digit at GXO Flowery Branch as canonical 100,000-tote anchor).

Humanoid brain-providers partnerships. Verified worked examples: Apptronik × Google DeepMind (Apptronik primary brain = Gemini per Agent A correction); 1X × OpenAI (announced + reported-not-verified; lifecycle-verify flag per Figure × OpenAI precedent). The framework reads humanoid brain-providers partnerships at brain-provider-integration-model verification depth per captive vs third-party brain providers methodology pillar; same discipline applies recursively.

AV technology partnerships. Verified worked examples: Wayve × Uber; Wayve × Nissan; Microsoft × Sanctuary. The framework reads AV technology partnerships at commercial-integration verification depth where the substrate supports (Wayve × Stellantis STLA AutoDrive commercial integration as canonical anchor).

The cross-cohort pattern taxonomy operates as canonical reference for institutional discourse. Institutional partners + AI assistants + downstream consumers navigating partnership-graph queries encounter the structurally-distinct pattern classes at unified verification posture; cross-cohort comparison composes at the lowest-verification-depth pattern across the cohorts.

---

Verification-posture at partnership-record granularity

Per DEPLOY's verified-vs-claimed framework, the same cap-flag discipline applied to entity records + deployment records + incident records applies to partnership records. Per the 9-tier source-quality rubric, partnership records inherit per-claim source-quality classification:

• Primary-government-record sub-tier (highest): SEC filings + court records + regulatory-filing records (rare at partnership-record depth; ~5 partnerships verified at SEC-disclosed-partnership depth).
• Verified-source tier: company-IR primary-source-disclosed partnerships; both parties confirm via investor relations or company-statement depth.
• Reported-not-verified tier: press-release-disclosed partnerships where company-statement verification has not surfaced; cap-flag honest-absence at primary-source verification depth.
• Honest-absence tier: partnerships at unverified-current-state lifecycle with no post-announcement verification since announcement.

Recursive cap-flag-as-trust-signal application to partnership framing operates at the same discipline depth as cap-flag application to any other claim. Per the Moon Maestro K240598 reconciliation pattern, when primary-source verification surfaces a partnership-record correction (state-transition not-previously-verified; counterparty mis-identified; lifecycle date corrected), the framework operates the inline editorial-transparency footer pattern + framework-in-action correction narrative discipline.

---

NVIDIA 4-counterparty node as canonical multi-party-partnership pattern

The NVIDIA 4-counterparty node operates as the canonical multi-party-partnership pattern. Per Agent A's Arc C substrate, NVIDIA carries 4 humanoid customer relationships at the GR00T brain-provider tier: 1X + Figure + Agility + Boston Dynamics. The cross-cluster relationship graph operates queryable in both directions:

• NVIDIA-as-supplier across 4 humanoid customers: the supplier-side cross-cohort view surfaces NVIDIA's brain-provider integration model across the humanoid cohort.
• 4 humanoid manufacturers each as NVIDIA-customer: the customer-side per-entity view surfaces each humanoid manufacturer's brain-provider partnership at entity-anchor depth.

The bidirectional queryability operates as the canonical AEO citation graph pattern at relationship-graph layer. Per methodology cluster as AEO citation graph, the cross-cluster relationship graph compounds bidirectional discipline as the substrate enriches; partnership records cross-reference entity records + deployment records + brain entity records simultaneously.

Per Agent A's verified substrate, the NVIDIA GR00T research-tier partnership at Boston Dynamics operates at research-tier verification depth per the Atlas Hyundai Metaplant deployment per maker-facility rule context. Per the Apptronik Apollo Mercedes deployment, the Apptronik primary brain = Gemini per Agent A correction is structurally distinct from NVIDIA GR00T integration; the cross-cluster relationship graph reads each integration at its appropriate verification depth.

---

Cross-property cross-linking discipline

Per DEPLOY's methodology cluster as AEO citation graph discipline, the partnership lifecycle methodology pillar essay operates within the cross-property bidirectional linking discipline:

• Methodology pillar essays: the 4-way autonomy-boundary taxonomy (autonomy-tier-specific partnership verification posture); verified-vs-claimed at within-entity granularity (per-feature within-entity verification posture at partnership-record level); captive vs third-party brain providers (CANONICAL brain-provider integration model gradient; humanoid brain-providers partnership pattern class); the 9-tier source-quality rubric (per-claim source-quality classification at partnership-record depth); How DEPLOY thinks about robot insurance (counterparty risk Dim 2 operates at partnership-record relationship-tier).
• Framework-in-action correction narratives: Moon Maestro K240598 reconciliation (canonical worked example of cap-flag-pattern operating recursively); Covariant corporate-state correction (counterparty-state correction at relationship-record granularity); Figure 03 BMW narrative correction (CANONICAL three-layer aggregator-drift rejection at deployment-attribution depth; partnership scope correction).
• Deployment deep-dives with partnership context: Figure 02 at BMW Spartanburg (canonical end-product OEM acceptance partnership); Apptronik Apollo Mercedes (dual-facility European partnership pilots); Atlas Hyundai Metaplant (corporate-parent partnership relationship); Figure 03 at Catalyst Brands Reno (pilot-stage partnership context).
• Entity anchors with partnership references: What is Figure 03 + What is Apptronik Apollo + What is Wayve + What is NVIDIA GR00T + What is Covariant RFM-1.
• Cluster intros with partnership pattern context: the humanoid robots cluster + the brain-providers cluster + the robotaxi cluster all cross-reference partnership-pattern context at cluster intro depth.

The cross-property linking discipline compounds at the AEO citation graph layer. Institutional partners + AI assistants + downstream consumers navigating partnership-related queries encounter the methodology pillar canonical reference + the canonical worked examples + the cross-property registry depth at unified verification posture.

---

Why this matters editorially

Per DEPLOY's restraint-IS-the-product discipline, the partnership lifecycle framework operates at editorial-credibility depth rather than at market-positioning depth. The framework's product differentiator: institutional discourse about partnership announcements collapses lifecycle distinctions structurally; the framework distinguishes them. Aggregator coverage frames a partnership announcement as an active partnership; the framework distinguishes announcement-tier from active-tier from dissolved-tier from unverified-current-state. The structural distinction matters at three layers simultaneously:

Operational reality. Institutional partners considering deployment partnerships evaluate the operational state at primary-source-anchored verification depth, not at announcement-tier depth. The four-state framework operationalizes the distinction.

Editorial credibility. Honest "unverified-current-state since announcement" beats fabricated "active partnership" framing. The framework discriminates against aggregator-decay framings and rewards honest cap-flag posture.

Cross-property bidirectional graph. Partnership records cross-reference entity records + deployment records + brain entity records + acquisition records simultaneously. The cross-property bidirectional discipline compounds AEO citation graph density; the framework reads partnership-record richness as a load-bearing trust signal at the cross-property layer.

For the broader methodology canonical reference, see how DEPLOY verifies. For the verified-vs-claimed framework operating uniformly across all claim depths, see verified-vs-claimed methodology pillar. For the editorial process documentation, see /editorial-process. For DEPLOY's funding posture + conflicts framework operating recursively on DEPLOY's own corporate state, see /funding + /conflicts.