NetherOps Doctrine Spine Sovereignty Motion Agents Lexicon
OpptyCon ▶
Vendor vs Build · Sovereignty Decision Architecture

Where Does Sovereignty Apply?

This is not a procurement question. It is a control question. Vendors can supply sensory input. They cannot define judgment. Map each layer against sovereignty requirements.

Portfolio-Level Implications
At portfolio scale, sovereignty decisions compound. Centralized telemetry normalization, shared weighting logic, and a shared feedback engine become architectural requirements. The fundamental choice: build a central adjudication core and allow per-asset tooling variation, or standardize the stack across the portfolio.
Vendor = sensory input Build = judgment authority Economic weighting → build Probability modeling → build Capital allocation → build Commodity data → vendor acceptable
Never Vendor
Build Logic
Hybrid — Vendor Infra, Proprietary Logic
Vendor Acceptable
Build
Strategic
Layer 01 · Immune System
Revenue Feedback & Reweighting
The immune system cannot be outsourced. Prediction error correction and capital reallocation rules are strategic. BI tools may handle visualization, but the correction logic, error aggregation windows, and reweighting triggers must be proprietary.
Sovereignty Rules
✕Vendor cannot define correction triggers
✕Vendor cannot set reweighting thresholds
✓Vendor BI for dashboards acceptable
✓Vendor data warehouse acceptable
Hybrid
Infra: Vendor
Logic: Build
Layer 02
Orchestration & Velocity
Mostly vendor infrastructure — CRM, marketing automation, sales engagement, routing tools. But routing logic and threshold triggers must remain proprietary. Otherwise velocity becomes tool-constrained rather than economics-constrained.
Sovereignty Rules
✓Vendor CRM (Salesforce, HubSpot)
✓Vendor MAP (Marketo, Pardot)
✓Vendor engagement (Outreach, Salesloft)
✕Vendor cannot define routing logic
✕Vendor cannot set velocity thresholds
Hybrid
Raw fuel
Telemetry Ingestion · Between Layers 02–03
Telemetry Ingestion Layer
Vendors acceptable here — telemetry is raw fuel. Intent networks, technographic crawlers, enrichment APIs, behavioral tracking. But vendor data must be normalized and adjudicated internally. Vendor scoring must never bypass the Signal Engine. Vendor provides raw signal. The organization retains weighting authority.
Vendor Examples
✓Bombora, G2 (intent)
✓BuiltWith, HG Insights (techno)
✓ZoomInfo, Clearbit (enrichment)
✕Vendor scoring must NOT bypass L03
Build
Core IP
Layer 03 · Adjudication
Signal Interpretation Engine
Core logic = build. This is where competitive advantage lives. If a vendor defines probability modeling, the organization becomes dependent on black-box inference. In PE-backed systems, that is risk. Data science can leverage vendor analytics platforms, but probability weighting architecture must remain proprietary.
Sovereignty Rules
✕Vendor cannot define probability model
✕Vendor cannot set signal weights
✕Vendor cannot control decay constants
✓Vendor analytics infra (Snowflake, dbt)
✓Vendor ML platforms (infra only)
Build
Proprietary
Layer 04
ICP Economic Clustering
Build the logic. BI tooling is acceptable, but clustering criteria must be proprietary. The Revenue Density Score is the capital allocation engine. If a vendor defines segmentation heuristics, differentiation erodes. Tooling can be external. Clustering logic cannot.
Sovereignty Rules
✕Vendor cannot define cluster criteria
✕Vendor cannot set density formulas
✓Vendor BI (Looker, Tableau, Hex)
✓Vendor data infrastructure
Never
Internal truth
Layer 05 · Anchor Mass
P&L Economic Gravity
Never vendor. This is internal truth. ARR math, CAC constraints, margin targets — these must live in proprietary systems. Even if finance tooling is external, the logic remains internal. No debate.
Sovereignty Rules
✕No vendor defines ARR logic
✕No vendor defines CAC constraints
✕No vendor defines margin targets
✕No vendor defines LTV:CAC thresholds
~Finance tooling external OK (NetSuite, etc.)
Model These Decisions
Every sovereignty decision has a cost structure — headcount for build, licensing for buy, integration for both. OpptyCon models the financial impact of these decisions across the full S&M cost structure, showing how vendor vs build choices affect blended CAC, coverage ratios, and pipeline physics over 24+ months. Launch OpptyCon →
Decision Framework
When to vendor vs when to build
Vendor Acceptable Where
·Data is commodity
·Infrastructure is plumbing
·Scale is expensive to build
·No proprietary logic at stake
·Switching cost manageable
Build Required Where
·Economic weighting occurs
·Probability modeling occurs
·Capital allocation decisions occur
·Governance constraints exist
·Competitive differentiation at stake
Architecture Principle
"Vendor commodity telemetry and infrastructure, but retain control over economic weighting, probability modeling, and capital reallocation logic. That is where differentiation and governance risk live."
Portfolio Architecture Tradeoff
Standardization vs Flexibility
Standardize Stack Across Portfolio
Increases leverage
Unified data model across assets
Shared weighting logic compounds
Lower total vendor cost
Slower acquisition integration
Requires migration investment
May not fit edge-case business models
Central Core + Per-Asset Tooling
Faster acquisition velocity
Preserves acquired team workflows
Lower integration risk
Vendor sprawl increases over time
Data normalization complexity
Weaker cross-asset learning signal
Higher total cost at scale
Architectural Decision Point
The fundamental architectural decision at portfolio scale: build a central adjudication core with per-company execution tooling, or standardize the stack across the portfolio. The answer determines every sovereignty decision downstream.