Specifications — Buying-Center Engagement Cube 

1) User Stories

As a Chief Marketing Officer, I want a system that computes Interest, Intent, and Ideal Prospect Profile (IPP) scores for each buyer or buying center using transparent proxy labels derived from existing signals. This will let me segment accounts into High, Medium, or Low across a 27-segment cube and prioritize engagement programs accordingly.

As a Market Strategist, I want a dashboard that displays each buying center’s High/Medium/Low standing for the three axes, so I can easily filter to high-priority segments and design campaigns for cohorts that share similar drivers of Interest, Intent, and IPP.

As a Sales Director, I want to view each buying center’s Interest, Intent, and IPP classifications directly aligned with my active pipeline accounts. This will help me identify which deals are heating up, where intent is emerging, and which prospects best fit our target profile. This way, I can allocate my team’s attention to the most promising opportunities.

2) Requirements

2.1 Functional Requirements

Definite

• Compute three independent continuous scores per account/buying center—Interest, Intent, and IPP—using programmatic proxy labels (e.g., recency-weighted event weights for Interest/Intent; similarity to ICP profile for IPP).

• Train baseline learners and a production multi-task model (shared encoder + three heads) using the proxy labels; evaluate and calibrate predicted probabilities.

• Aggregate and normalize the three axis scores; post-process into High/Medium/Low bins using cohort percentiles or robust z-scores, with deterministic thresholds saved in configuration, forming the 27-segment cube

Perhaps

• Add buying-stage inference (Explore, Identify, Select, Validate, Define, Not-in-Market) when signals support it.

• Include lightweight model explanations (top contributing features per score).

Improbable

• End-to-end real-time ingestion, retraining pipelines, or orchestration systems.

• Automated campaign blueprint generation from cube segments.

2.2 Non-Functional Requirements

Definite

• Usability: Provide a single, documented command or notebook that runs proxy-label creation → training/calibration → scoring → binning → export, with a clear README and example configuration.

• Reliability: Use fixed seeds for deterministic runs; include unit tests for proxy-label logic, normalization, and cube mapping; provide clear logging and error messages.

• Performance: Handle large datasets in a single batch on a standard development machine and support serverless inference under AWS Lambda limits.

• Supportability: Organize Python code by stage (proxies, features, models, calibration, binning, export); configuration via ENV; include docstrings and developer notes.

• Interface: Document I/O schemas for inputs and outputs to ensure consistency and reproducibility

Perhaps

• Portability: Provide a Conda or Docker environment file for setup simplicity.

Improbable

• Enterprise-grade SLAs, compliance, or high-availability systems beyond classroom scope.

2.3 Interfaces

Definite

• Execution Interface: Non-GUI execution to run end-to-end batch processing: proxy-label generation → model training/calibration → scoring → binning → export.

• File I/O:

  • Inputs: Cleaned structured data tables 

  • Outputs: CSV files and Supabase tables containing buyer identifiers, three numeric scores, three bucket labels (H/M/L)

  • Configuration: External ENV/YAML specifying model parameters, proxy weights, cohort thresholds, calibration settings, and file paths.

Perhaps

• Minimal dashboard integration using React/Next.js connected to Supabase and AWS Lambda for inference and filtering results by H/M/L or cube segment.

Improbable

• Fully interactive enterprise GUI or real-time APIs this semester.

2.4 Other (Constraints)

Scope focuses on ground-up model development using proxy-labeled data (supervised/weak supervision) instead of finetuning a pretrained model.

Serverless inference via AWS Lambda will handle user-submitted data; results are stored in Supabase and optionally displayed in a Next.js/React dashboard.

Traceability to client materials:

The Interest, Intent, and IPP axes and 27-segment cube design originate from Kinetik’s documentation.