Temporal and Granularity Requirements for Data

Overview
In the PMI Cognitive Project Management for AI (CPMAI) methodology, Phase II: Data Understanding requires the team to identify exactly what data the AI solution needs. Two of the most important dimensions of that identification are temporal requirements (the time-related characteristics of data) and granularity requirements (the level of detail at which data is captured, stored and aggregated). Getting these wrong is one of the most common reasons AI projects fail. The data may exist, but it may be too old, too sparse in time, too aggregated, or not available quickly enough to support the business decision the model is meant to drive.

Why It Is Important
1. Model validity depends on it: A model trained on monthly sales totals cannot predict hourly demand. A fraud model trained on daily summaries cannot flag a single suspicious transaction. The temporal and granular nature of training data puts a ceiling on what the model can learn and predict.
2. It links data to the business question: CPMAI is business-first. Phase I (Business Understanding) defines the decision, and that decision dictates the time horizon and level of detail the data must support. If the business needs store-level weekly forecasts, the data must be at least store-level and weekly (or finer).
3. It prevents costly rework: Discovering in Phase IV (Model Development) that the data is too coarse forces the project back to Phase II. CPMAI's iterative nature allows this, but early identification saves time and money.
4. It affects feasibility and the go/no-go decision: If the required granularity or history does not exist and cannot be acquired, the project may be infeasible. CPMAI asks you to surface this early.
5. It drives data volume, cost and infrastructure: Finer granularity and longer history mean more storage, processing, labeling effort and possibly privacy exposure.
6. It protects against drift and staleness: Temporal requirements define how recent data must be and how often the model must be retrained once it is in operation (Phase VI).

What It Is
Temporal requirements cover the time-related properties of data:
- Historical depth (lookback window): How far back the data must go. Seasonal patterns usually need several full cycles, for example two to three years for annual seasonality.
- Recency/freshness: How current the data must be. Stale data leads to stale predictions.
- Frequency/sampling rate: How often observations are recorded (per second, hourly, daily, monthly).
- Latency: How quickly data must be available after an event occurs. Real-time inference needs streaming data; batch analytics can tolerate delay.
- Timestamp consistency: Time zones, synchronized clocks and consistent date formats across sources.
- Temporal coverage and continuity: Gaps, missing periods and irregular intervals.
- Point-in-time correctness: Using only data that was actually known at prediction time, which avoids data leakage from the future.
- Retention and refresh cadence: How long data is kept and how often it is updated for retraining.

Granularity requirements cover the level of detail:
- Unit of analysis: Individual transaction, customer, device, store, region or company.
- Aggregation level: Raw events versus summaries (sum, average, count).
- Spatial granularity: GPS coordinate, zip code, city or country.
- Attribute detail: SKU-level versus product category; individual sensor readings versus a device health score.
- Temporal granularity: Data resolution in time (minute versus month). This is where the two concepts overlap.

Key principle: You can always aggregate fine-grained data up to a coarser level, but you cannot disaggregate coarse data down to a finer level without making assumptions. When in doubt, acquire data at the finest granularity that is practical and compliant, then aggregate as needed.

How It Works in CPMAI
Step 1: Start from the business objective (Phase I). Identify the decision, its timing and its unit. Example: 'Predict which customers will churn in the next 30 days so retention offers can be sent weekly.' This implies customer-level granularity, a 30-day prediction horizon, at least weekly data refresh, and enough history to observe many churn events.
Step 2: Translate it into data requirements. Document the required lookback window, frequency, latency, unit of analysis and aggregation level for each data source and feature.
Step 3: Inventory the available data. Determine what granularity and time span actually exist in source systems, data warehouses, third-party providers or IoT feeds.
Step 4: Perform a gap analysis. Compare required against available. Common gaps include:
- Only aggregated data is stored, for example daily totals where transactions are needed.
- History is too short to capture seasonality or rare events.
- Sources have mismatched frequencies, such as hourly sensors and monthly maintenance logs.
- Latency is too high for a real-time use case.
- Time zones or timestamps are inconsistent.
Step 5: Decide on actions. Options include:
- Acquiring new data or purchasing external data.
- Instrumenting systems to capture finer data going forward, which means waiting for history to accumulate.
- Resampling or aligning data, for example by aggregating fine data to a common grain.
- Adjusting the scope or prediction horizon with stakeholder agreement.
- Making a no-go decision.
Step 6: Validate with stakeholders and data owners, including privacy and compliance checks. Finer granularity, such as individual-level location data, raises privacy risk and may require anonymization or aggregation.
Step 7: Carry the requirements forward. Phase III (Data Preparation) handles resampling, windowing, lag features and time-based train/test splits. Phase V (Model Evaluation) validates on out-of-time data. Phase VI (Operationalization) monitors freshness and drift and sets the retraining cadence.

Practical Examples
- Predictive maintenance: Needs high-frequency sensor data (seconds or minutes) at the individual-machine level, with enough history to include actual failure events.
- Demand forecasting: Needs SKU-by-store-by-day data spanning multiple years to capture seasonality and holidays.
- Fraud detection: Needs transaction-level, near-real-time data with low latency.
- Strategic planning model: May work well with monthly, regional aggregates. Finer data adds cost without value.

Common Pitfalls
- Assuming that because data exists, it is usable at the right grain.
- Data leakage: Using information not available at prediction time, such as a 'cancellation date' field when predicting churn.
- Using random train/test splits on time-series data instead of chronological splits.
- Mixing granularities without proper alignment, which creates duplicated or misleading records.
- Ignoring concept drift, so that old data no longer reflects current behavior.
- Over-collecting fine-grained personal data, which creates privacy and cost issues.

Exam Tips: Answering Questions on Temporal and Granularity Requirements for Data
1. Anchor to the business need first. The correct answer usually ties data requirements back to the business decision defined in Phase I. Prefer answers that say 'determine the granularity and time horizon the business decision requires' over technology-first answers.
2. Remember the aggregation rule. Fine data can be rolled up, but coarse data cannot be reliably broken down. If a scenario has only monthly data but needs daily predictions, the correct answer involves acquiring finer data or revising scope, not 'interpolating' or 'training anyway.'
3. Match the inference timing to latency. Real-time decisions need low-latency, streaming data. If a question describes real-time fraud blocking with data that arrives in a nightly batch, recognize the temporal gap.
4. Watch for seasonality and rare events. If the history is shorter than a seasonal cycle, or contains few examples of the target event, the best answer is to obtain more history or reconsider feasibility.
5. Spot data leakage. Answers that use future information, or that split time-series data randomly, are wrong. Choose point-in-time correct features and chronological validation.
6. Identify gaps in Phase II, not later. CPMAI emphasizes surfacing data issues during Data Understanding. If a question asks when to assess temporal or granularity needs, choose Phase II, with iteration back from later phases if needed.
7. Consider the go/no-go implication. If the required data cannot be obtained at the necessary grain or time span, the CPMAI-aligned answer often involves escalating to stakeholders, adjusting scope, or pausing the project rather than proceeding with unsuitable data.
8. Balance granularity against cost and privacy. The 'finest possible' answer is not always right. Choose the granularity sufficient for the business objective while respecting privacy, compliance and cost constraints.
9. Look for alignment issues. Multiple sources at different frequencies or time zones need harmonization. Answers mentioning time alignment, consistent timestamps or a common grain are usually strong.
10. Think about the lifecycle. Temporal requirements extend into operations: data freshness, monitoring for drift and the retraining cadence. Answers that recognize ongoing data needs reflect CPMAI's iterative mindset.
11. Eliminate distractors. Be wary of options that jump straight to algorithm selection, adding more compute, or 'collecting all available data' without regard to relevance. These ignore the data-needs analysis.
12. Use keywords as clues. Words such as 'hourly,' 'per transaction,' 'real-time,' 'seasonal,' 'last three years,' 'store-level' and 'aggregated' signal a temporal or granularity question. Ask yourself: does the available data match the required time and detail level?

Quick Summary
Temporal requirements define when, how often, how far back and how fast data is needed. Granularity requirements define at what level of detail it is needed. Both are derived from the business objective, assessed through gap analysis in CPMAI Phase II, and carried through preparation, evaluation and operationalization. On the exam, choose answers that align data to the business decision, respect the aggregation rule, avoid leakage, and raise feasibility concerns early.