What is in the Tech Vector quarterly deliverable, what is configurable, what is out of scope. The spec the buyer sees. The spec that holds at delivery.
Standardize the wrong things and you lose customers. Customize the wrong things and you lose your business. The 70/30 principle: aim for approximately 70% standardized core and 30% configurable surface.
Defense-adjacent program officers, S&T directors, and policy analysts at DoD components and federally funded research entities who need structured intelligence on emerging technology areas but lack the time or the tool access to construct it themselves. Typical profile: Office of Directed Energy, OSD R&E components, DARPA program offices, defense prime R&D divisions.
Decision-makers at these organizations know technology is moving faster than their read cycles. They cannot build and maintain corpus access. They do not want to operate a complex query tool. They want structured answers on a named technology, delivered on a cadence that matches their planning cycles, with a point of contact for the follow-on questions a structured PDF will always generate.
The table below maps every major component of the Tech Vector SKU to either the standardized 70% core or the configurable 30% surface. The 70/30 split is not a quality spectrum. High-quality work lives on both sides. The split is a delivery architecture decision. Standardized elements run identically for every buyer without additional scope. Configurable elements vary per engagement within defined parameters. Anything that does not appear in this table is outside the SKU boundary by default.
| Component | Bucket | Parameters | Rationale |
|---|---|---|---|
| 200M-document corpus | 70% Core | Fixed. Same corpus for every buyer. No buyer-specific data ingestion in L2. | The corpus is the defensible moat. Fragmenting it per buyer destroys the cross-document signal that makes the pack valuable. |
| Query methodology | 70% Core | NorthAI's proprietary guided-query construction approach. Not exposed to the buyer. Not customized per engagement. | The methodology is the IP. Exposing it to customization is exposing the IP to commoditization. |
| Output template structure | 70% Core | Fixed section order. Fixed section naming. Fixed appendix structure. The buyer knows what to expect every quarter. | Predictability is a product feature, not a constraint. Buyers plan their read cycles around a known structure. Changing it per buyer breaks the institutional value of the deliverable. |
| Delivery format | 70% Core | Structured PDF. Delivered via secure file transfer to a named recipient at the buyer organization. No raw data dumps. No API access in L2. | Keeping the delivery format standard keeps the delivery workflow repeatable. API access is an L3/L4 feature, not an L2 promise. |
| Delivery cadence | 70% Core | Quarterly. Delivery within 15 business days of quarter open. Not adjustable per buyer in the L2 form. | Variable cadences multiply the delivery management overhead. Quarterly is the standard. Annual buyers get four deliveries. No exceptions for "can we get it monthly." |
| Follow-up call structure | 70% Core | 60 minutes. Named analyst. Questions on pack content only. Not a new scoping session. Not a strategy consultation. | Without a defined call structure, the follow-up becomes an unbounded consulting engagement. The 60-minute hard stop is the boundary. |
| Technology area (named) | 30% Config | Buyer selects one named technology area per engagement. Examples: directed energy, hypersonics, quantum sensing, autonomous underwater systems. Selection is fixed at contract signing and holds for the contract term. | The technology area is the buyer's primary customization lever. It is defined at contract signing, not per quarter. Mid-term changes to the named technology area are a scope change, not a configuration. |
| Time horizon | 30% Config | Buyer selects one of three horizons at contract signing: near-term (12-24 months), medium-term (2-5 years), long-term (5-10 years). The horizon shapes which signals the pack emphasizes. | Time horizon affects the depth distribution of the pack but not its structure. It is a filter, not a rebuild. |
| Named accounts / organizations | 30% Config | Buyer may specify up to 5 named organizations for heightened tracking within the technology area. Organizations appear in the key actors section with additional depth. | Named account focus is a legitimate buyer-specific need that does not require a structural change to the deliverable. It is a filter applied to the standard output. |
| Depth dial | 30% Config | Buyer selects Standard (40 pages) or Deep (80 pages) at contract signing. Deep adds additional sourcing detail and expanded actor profiles. Price point differs by tier. | Page count varies. Structure does not. The delivery workflow for both depths uses the same template; Deep simply runs additional sections. |
| Buyer's internal data ingestion | Excluded | Not available in L2. If a buyer wants NorthAI to ingest and cross-reference internal documents, that is a separate custom engagement under CLIN 0003. | Internal data ingestion changes the corpus boundary, the data handling requirements, and potentially the authorization boundary. It is not an L2 feature. |
| Custom query construction | Excluded | Buyer cannot specify query parameters or access the query tool. The methodology is NorthAI's, applied by NorthAI analysts. | Exposing the query interface to buyers converts the product from a deliverable to a tool license, which requires different authorization and pricing architecture. |
| Live data access / API | Excluded | No API access, no dashboard access, no tool access in L2. All access to NorthAI's corpus and tooling is mediated through the quarterly deliverable. | Live access requires an ATO the product does not yet have. This is an L3/L4 feature, not an L2 promise. |
Tag key: 70% Core = standardized, ships identically to every buyer. 30% Config = configurable within defined parameters, selected at contract signing. Excluded = outside the SKU boundary; custom work priced under CLIN 0003 or deferred to L3/L4.
Hard boundaries are different from configurable limits. A configurable limit can be adjusted within parameters. A hard boundary cannot be adjusted regardless of who is asking or what they are willing to pay. Hard boundaries exist because crossing them changes the authorization posture, the delivery model, or the IP control framework in ways that cannot be reversed cleanly.
| Boundary | Why it holds | Compliant alternative |
|---|---|---|
| No buyer-specific corpus or data ingestion in L2 | Ingesting a buyer's internal data changes the data handling requirements, potentially the authorization boundary, and the ISSO scope. This is not an L2 feature. | Custom engagement under CLIN 0003. Scoped as a separate deliverable with a separate data handling agreement. Priced at T&M NTE. |
| No access to the query tool or corpus interface | Tool access converts the product from a deliverable to a SaaS license. SaaS licensing requires authorization that the L2 product does not yet have. | The quarterly deliverable is what the buyer gets. If the buyer needs tool access, the conversation moves to the L3/L4 roadmap, which depends on authorization progress. |
| No technology area changes mid-contract | Technology area is selected at contract signing. Mid-term changes are a scope modification, not a configuration. They require a contract modification under the appropriate CLIN. | Contract modification process via CHN. Priced at the delta between what was contracted and the new scope. Effective at the next quarterly delivery, not mid-quarter. |
| No real-time or on-demand delivery | The delivery cadence is quarterly. On-demand delivery requires a fundamentally different staffing model and cannot be promised within the L2 margin structure. | Rush delivery is not offered. If a buyer has a near-term decision that cannot wait for the standard quarterly cycle, the alternative is a one-time custom briefing under CLIN 0003, priced as a standalone engagement. |
| No classified data or systems | The Tech Vector corpus is unclassified. NorthAI operates in GCC High or GovCloud environments. CUI handling may be in scope; classified data handling is not, and requires a separate facility clearance and system authorization that Tech Vector does not carry. | If a buyer needs classified context for their technology intelligence, that is a separate engagement requiring a separately cleared and authorized system. Not a Tech Vector extension. |
The Tech Vector L2 product has a specific relationship with the FedRAMP authorization boundary. This section defines what stays inside the boundary (and therefore under whatever ConMon obligation the product carries) and what spills outside it (and therefore is not subject to ConMon scrutiny).
The Tech Vector L2 product has four integration points with external systems or parties. Each is documented because each is a potential boundary-change trigger.
| Touchpoint | Direction | Data type | Boundary implication |
|---|---|---|---|
| Corpus data ingest (ongoing) | External sources into NorthAI corpus | Public / FOUO / open-source technical literature | Corpus updates are in-boundary. Adding new data source types (e.g., buyer-provided, classified feeds) requires ISSO review and potential boundary change assessment. |
| Deliverable file transfer to buyer | NorthAI to buyer | Structured PDF, potentially CUI | Transfer mechanism must align with the buyer's data handling requirements. GCC High to GCC High is the cleanest path. If the buyer is on a different classification-level environment, the transfer mechanism needs separate review. |
| CHN contracting layer | Bilateral (contract paper, billing) | Contract data, pricing, buyer identity | CHN handles the contracting surface. NorthAI's authorization boundary does not extend to CHN's contracting operations. Contract data and billing are outside the NorthAI authorization boundary. |
| Named analyst email access | Buyer to NorthAI analyst | Questions about pack content | Email is not a system within the authorization boundary. If the buyer's email domain is on a GCC High or classified system and they want to communicate on that system, a separate secure messaging arrangement needs to be made. Standard email is the default. |
Tech Vector at Level 2 is structured for Phase III sole-source delivery under the CHN contracting vehicle. The CLIN structure below applies to the Phase III award. Custom work falls to CLIN 0003 regardless of the contracting vehicle.
Phase III sole-source awards can draw on multiple appropriation types. Tech Vector is structured to accept any of the following without requiring a scope change:
When briefing the customer Contracting Officer on Phase III eligibility under the derive-extend-complete framework, use the language below verbatim or adapted. Do not improvise the eligibility argument; the mapping from FA8649-21-P-0756 to Tech Vector is specific and the wording matters.
| Derive-extend-complete element | FA8649-21-P-0756 Phase I language | Tech Vector execution |
|---|---|---|
| Derives from | AI-over-connected-big-data method for identifying relevant research across government-funded output | Tech Vector's 200M-document corpus query methodology is the direct commercial application of that method. Same algorithm class. Same data source types. |
| Extends | Scope was demonstration-scale: patents, grants, financial records for a bounded technology area | Tech Vector extends to production scale: 200M documents, continuous ingestion, quarterly delivery cadence, named technology areas across the defense portfolio. |
| Completes | Phase I produced a feasibility result. No product. No repeatable delivery. No buyer-facing interface. | Tech Vector completes the Phase I promise: a structured, repeatable, buyer-facing intelligence product built on the proven method. Phase III funding closes that gap without additional R&D. |
Full artifact: A2 derive-extend-complete-mapping. Reference it in the CO briefing by title. Do not reconstruct the mapping from memory during a CO conversation.