The standardized core vs. configurable surface, plotted per product line. This is the delivery architecture, not the feature list.
Security controls are what your authorization covers. If Agency A has different authentication than Agency B, you don't have one authorized product, you have multiple. Every improvement we make has to be rebuilt four times instead of once. If I customize for you, I can't support ten agencies from the same codebase.
The diagram below maps all three NorthAI product lines across two axes: what ships identically to every buyer (the standardized 70%), and what the buyer adjusts within defined parameters at contract signing (the configurable 30%). The rendered Mermaid graph follows the cross-product comparison table.
graph LR
subgraph TECH_VECTOR["Tech Vector (SKU 1)"]
TV_CORE["70% Core
corpus / methodology / template / cadence / call structure"]
TV_CFG["30% Config
technology area / time horizon / named accounts / depth dial"]
TV_EXCL["Excluded
buyer data ingest / tool access / classified"]
TV_CORE -->|fixed| TV_CFG
TV_CFG -->|scope boundary| TV_EXCL
end
subgraph NORTHSTAR["NorthStar (SKU 2)"]
NS_CORE["70% Core
corpus / session structure / output format / indexing / analyst"]
NS_CFG["30% Config
domain / session depth / cadence / output depth"]
NS_EXCL["Excluded
live access / custom query / buyer data"]
NS_CORE -->|fixed| NS_CFG
NS_CFG -->|scope boundary| NS_EXCL
end
subgraph DEFENSE_BD["Defense BD (SKU 3)"]
BD_CORE["70% Core
tracking methodology / memo structure / data sourcing / delivery"]
BD_CFG["30% Config
named line items / prioritization weighting / component focus"]
BD_EXCL["Excluded
live dashboard / internal planning system integration"]
BD_CORE -->|fixed| BD_CFG
BD_CFG -->|scope boundary| BD_EXCL
end
TECH_VECTOR --> NORTHSTAR --> DEFENSE_BD
classDef core fill:#E6EFFE,stroke:#3B82F6,color:#1E3A8A
classDef cfg fill:#E5EBD9,stroke:#788C5D,color:#4F6638
classDef excl fill:#F8E3D6,stroke:#D97757,color:#B85C3E
class TV_CORE,NS_CORE,BD_CORE core
class TV_CFG,NS_CFG,BD_CFG cfg
class TV_EXCL,NS_EXCL,BD_EXCL excl
Tech Vector has the cleanest 70/30 split of the three product lines. The core is easy to define because the deliverable is tangible: a structured PDF, produced on NorthAI machines, from a corpus the buyer does not touch. The query methodology is invisible to the buyer by design. The output template is fixed because it has to be: buyers plan their read cycles around a known structure, and changing it per buyer would mean the institutional value of the deliverable is not compounding. The configurable surface is real but bounded. Technology area and time horizon are the primary knobs. Named accounts and depth dial add specificity without restructuring the delivery workflow. Tech Vector is positioned as the Phase III SKU: the same 70/30 structure applies whether the contract vehicle is a direct commercial sale or a Phase III sole-source award under CHN paper.
Bar is illustrative. "Excl" segment represents hard-excluded items (buyer data, tool access, classified) that exist as buyer requests but are outside the SKU.
NorthStar's 70/30 split is harder to enforce than Tech Vector's because conversational products resist scope-fencing. The fundamental risk: the next question is always a new question. The 70% standardization strategy for NorthStar is to treat the session structure as the product, not the questions. The buyer gets a defined session: a fixed number of questions, a defined session length, a specific output format. They do not get an open-ended conversation that can run indefinitely. The session structure is what makes NorthStar deliverable on a repeatable basis without the delivery team having to re-scope every engagement.
NorthStar carries slightly more analyst time per engagement than Tech Vector, which compresses the standardization ceiling. The 70% target is achievable with strict session structure discipline.
Defense BD is the hardest of the three to productize because the buyer wants operational integration, not a quarterly artifact. The L2 form is a deliberate constraint: a budget posture brief on named line items, not a live dashboard. The 70% standardization holds because the tracking methodology, the memo structure, and the data sourcing are all consistent across buyers. The configurable 30% is the named line items and the prioritization weighting, which are buyer-specific without requiring a structural change to the workflow.
Defense BD carries the largest "excluded" segment of the three products because buyers will frequently ask for live dashboard access and internal planning system integration. Both are explicitly excluded from the L2 form.
Not every buyer request that is specific to their situation belongs in the 30% configurable surface. Some belong in CLIN 0003 custom work. Some belong in the excluded category entirely. The test for whether something goes in the configurable 30% is all four of the following:
| Test | What it means | Example: passes | Example: fails |
|---|---|---|---|
| 1. It is a filter, not a rebuild | The feature adjusts which data surfaces in the standard output. It does not change the output structure or the delivery workflow. | Named accounts: adds depth to existing actor profiles. The template does not change. | Buyer's internal documents: changes the corpus, changes the data handling requirements, changes the delivery workflow. |
| 2. It can be set at contract signing | The buyer makes the choice once, at contract signing. They do not make it per delivery. | Time horizon: set at signing, applies to every quarterly delivery for the contract term. | "Can we change the focus area this quarter?": mid-term change, not a configuration, a contract modification. |
| 3. It does not vary across customers within the same configuration class | If two buyers select the same configuration options, they get the same standardized delivery experience. | Two buyers both select directed energy, 5-year horizon, Standard depth: they receive the same template applied to the same focus, independently. | "Our organization has a special format requirement for internal circulation": format requirement is customer-specific, not a configuration class. Custom work. |
| 4. It does not change the authorization posture | The feature does not add new data flows, new integrations, or new data types that would affect what the authorization covers. | Named accounts (up to 5): adds tracking depth within the existing corpus scope. No new data flows. | "Can you also pull from our internal SharePoint?": new data source, new data flow, new authorization scope. Hard excluded. |
The most common productization failure mode is not a bad initial design. It is good-faith accommodation that accumulates into structural drift. The 70/30 split does not drift all at once. It drifts one "reasonable exception" at a time. The patterns below are the ones to watch.