Seven horizontal layers, from the economic model down to attribution. Five agents span them vertically and enforce the thresholds. Causality flows down; correction flows up. This isn't a marketing stack diagram — it's a control architecture. OpptyCon models the spine's economics, pipeline, and stages today and runs six live governance checks against your inputs; it governs by surfacing the verdicts the agent layer is meant to enforce — not yet by autonomous enforcement.
The full framework is deliberately bigger than the product — the framework is the IP, OpptyCon is one expression of it. Every layer below carries its build status, verified against the app source (audit at commit 3ba29d5, 2026-06-02) — not the marketing copy. Full status per claim lives on the roadmap.
Read it top-down to see the constraint cascade; read the feedback arrows and it governs itself. Every node is constrained from above and informed from below. Open any layer for the mechanism, the agents that span it, and its build status.
Protected margin, burn multiple, coverage targets, unit-economics ceilings. This is the gravity of the system — the P&L is internal truth, never a vendor input. Every dollar of GTM spend traces back through here.
OpptyCon operationalizes this layer: P&L governance domain, multi-year glideslope, coverage-ratio enforcement, dual-axis cost model. The P&L Agent constrains downstream spend when margin or CAC ceilings are breached.
Tier models, segment rules, TAM/SAM/SOM boundaries, exclusion criteria. Capital flows to revenue density; positioning is parameterized by narrative receptivity.
The ICP governance check computes attainment-realism and quota-coverage verdicts off your deal-size and quota inputs — critical when required attainment runs past 120%. Segment definitions stay a human-gated decision.
SPI (Segment Profitability Index) and Revenue Density — the lexicon's named anchor metrics for this layer — are not computed anywhere in the app. There's no segment clustering; ICP inputs are static. This is the gap between the doctrine's topography and what the engine does.
This is where the motion taxonomy lives — and where the framework is mid-resolution. The product runs three motions today; the doctrine names seven lanes as the horizon. Both are shown, tagged.
CREATE / CONVERT / ACCELERATE allocation, channels nested inside each motion, per-motion ROI and CAC computed from spend. Coverage math is real and flags when conversion can't support the target — though it surfaces the breach rather than clamping the target.
The split-funnel model splits acquisition by mode first, channel second: Demand Capture, Conditioning, Exploration Capital, Interception Capital, Distribution Multiplied, Stakeholder Compression, Revenue Density Motion. Lane-level KPIs need richer segmentation before they're useful.
Finance trusts the ledger; operators consult the forecast. Keep them separate, keep them connected. The Stage check flags stage inflation and SLA slippage — a human still works the gate.
A real 6-stage funnel: per-stage conversion, benchmark grades, compression and velocity checks, show-rate. The Stage governance check fires on D/C funnel grades, stage bottlenecks, and cycles past 120 days. Phase-shifted lead/lag drives the coverage funnel shapes.
Dual-probability (P_base × P_accel) is not in the code — grep returns zero matches. The model is single-probability: close derives from one win-rate, and "acceleration" is a flat additive +5pp lift, not a structural × behavioral product. The quadrant-motion routing exists only in the spec.
This is the layer where doctrine and product diverge most, so it's worth being exact. The five "agents" are the governance mechanism — and as governance checks, four of them run today. As autonomous agents that act, none of them exist yet. The label maps to a diagram ring, not to acting code.
P&L, Stage, Coverage, Attribution, Forecast each run as a synchronous function that thresholds engine output against your inputs and returns a critical/warning/healthy verdict, once per render. Real governance — but they surface findings; they don't enforce them.
Nothing schedules, polls, acts, writes back, or routes. The Orchestration Agent — the conductor that's meant to resolve conflicts between the others — has no code analog at all. Autonomous enforcement, the read→recommend→write progression, and the full 11-agent registry live in the spec, not the app.
The data plane, not the control plane. Execution is where vendors are acceptable — commodity telemetry and infrastructure — but routing logic and thresholds stay proprietary. (The Sovereignty Map governs that build-vs-buy call layer by layer.)
The 3-motion mix models execution cost and per-channel economics, and a read-only HubSpot adapter pulls actuals into a local store to compare plan vs reality. OpptyCon models execution and reads it.
It never runs execution — no campaign launch, no CRM write, no routing. The CRM/orchestration tool nodes in the diagram are inert; their "health" is a derived color, not a control signal. Per the Sovereignty Map, those stay vendor/config tools — execution is the data plane, not the control plane.
In most orgs forecasting is a downstream output — observation, not governance. Here, forecasting is an input to budgets. The forecast corrects the budget; the budget corrects the allocation. Attribution is reclassified from credit-allocation to a calibration dataset.
A plan-vs-actual comparator computes variance, detects assumption drift (win-rate, deal-size, conversion), and emits recalibration suggestions plus variance verdicts. Real feedback signal — attribution as a governance input, upstream of channel credit.
Learning Latency and Correction Latency — the doctrine's primary KPIs for this layer — aren't computed (zero code matches). And recalibration is a suggestion the user applies; nothing auto-corrects, and there's no provenance record of what produced a verdict. The loop is drawn, not yet closed.
A thermostat has three parts: a set point (what the business demands), a sensor (what actually happens), and an actuator (what translates intent into action). Revenue works the same way — and the feedback arrow is the whole difference between governing and merely observing.
Business Plan → P&L → Protected Margin → Coverage Ratio
Budgets → GTM Model → Allocations → ICP Spend → Stage Defs
Execution → Forecasting → Attribution → Optimization
Forecasting ↑ Budgets · Attribution ↑ Stage Defs · CAC breach ↑ P&L Agent
Without upward feedback, budgets are set once and never corrected. That's an open loop — a thermostat with no thermometer. A flowchart shows sequence; a thermostat shows control.
In the doctrine, agents are vertical enforcement rails — they monitor thresholds, enforce constraints, and close loops. In the app today, four run as governance checks that surface verdicts; the fifth, the conductor, isn't built. They're shown here as designed, with each one's real status. The pills are the honest part.
Thresholds margin, burn multiple, CAC payback, Rule of 40 against your inputs and flags breaches — critical/warning/healthy. It surfaces the constraint; a human acts on it.
Flags funnel-grade drops, stage bottlenecks, slow cycles, and weak show rates. It detects stage inflation; it doesn't yet block a stage transition.
Computes ramp-adjusted capacity vs required new ARR and flags when coverage, attrition, or deal-load cross threshold. Surfaces the gap; doesn't auto-correct the plan.
Flags weak CREATE ROI, thin ACCELERATE coverage, channel over-concentration, and low marketing-sourced share. Reads attribution as a governance signal that resets the budget, not a scoreboard.
In the doctrine, this is the conductor: it coordinates the other agents, resolves conflicting constraints, and times the feedback loops — when the P&L Agent wants to cut and the Coverage Agent needs more pipeline, this is what mediates. In the source today it has no analog at all — there is no "Orchestration" anything in the app. It's the clearest single marker of the gap between the architecture as drawn and the engine as built: the four checks above can each surface a verdict, but nothing yet arbitrates between them.
The framework is deliberately bigger than the product. The framework is the IP; OpptyCon is one expression of it. These are the doctrine claims that aren't shipped — named, not hidden. Full status per claim lives on the roadmap.
P_base × P_accel as the core scoring mechanic. On the build plan for months 2–3 — but not in the code today; the engine is single-probability with a flat acceleration lift.
The largest single unbuilt claim and foundational to every agent claim. Cheap to start, unlocks everything downstream. Highest near-term priority.
NRR + churn-prob + expansion-prob as first-class inputs feeding a Retention & Expansion view. CFOs and CROs ask for this directly.
Beyond the five enforcement rails: the complete registry with read→recommend→write progression. Design intent on the Agents page.
GEO as capacity constraint, pods as specialized economic units by segment × territory × ACV band. Design intent.
Lane-level KPIs across the seven acquisition modes. Needs richer segmentation before the KPIs are useful.
Other screens hang off it. The Motion Map is the Layer 03 detail; the Sovereignty Map is the build-vs-buy call per layer; the Agents page is the build queue. None replace the spine — they attach to it.
Acquisition mode first, channel second. The 7-lane execution detail that sits on the Pipeline layer.
Build vs buy vs integrate, layer by layer. Where you need control and where you can rent.
Control-plane primitives, the agent registry, and the read→recommend→write build sequence.
Every term defined once. Precise language prevents ambiguity; ambiguity prevents governance.
Dashboards observe. Control planes govern. We build control planes.
Agents get freedom within boundaries. The boundaries are the strategy.
Forecasting is an input to budgets, not a downstream output. Attribution informs governance.
Every motion, channel, and dollar traces to a P&L constraint. If it doesn't connect to protected margin, it doesn't ship.
This doctrine is open. The competitive advantage is not the blueprint — it's the engineering to build and govern it. If you can build it yourself, you should. If you want it built for you, that's what NetherOps does.
Book a briefing →