The 11 tabs at a glance

The right sidebar: Analysis Controls

The right edge of the workbench has a collapsible sidebar with the simulation controls. Click the small ‹ tab to collapse it for full-width viewing of dashboards. Key controls:

• Run Simulation — fires the Monte Carlo engine. Auto-run can be toggled in Settings → General.
• Scenario — Pre-mitigation, Post-mitigation, or Uncertainty-only.
• Focus dimension — Schedule / Cost / Performance — drives which P-value is the headline KPI.
• P-value slider — 50 to 95. Default is 80 (industry-standard confidence target).
• Iterations — 1,000 to 100,000. Default 5,000. Convergence banner advises if more are needed.
• Sampling method — Monte Carlo (random) or Latin Hypercube (stratified, fewer iterations needed).
• Distribution — BetaPert (default), Triangular, Uniform, Normal, LogNormal, Beta, Trigen, Discrete, Bitriangular, Two-point, Point.
• Mitigation effectiveness — slider for the Post scenario, scales risk impacts.

Roles & permissions

The platform uses Firebase custom claims for role-based access. Roles are assigned by your administrator and govern what you can do:

Loading data — file formats

Drop any combination onto the workspace:

• Primavera P6 XER — full schedule with TASK, TASKPRED, TASKRSRC, RSRC, UMEASURE tables. Activities, relationships, resource assignments, units-of-measure all populate.
• Excel risk register — .xlsx / .xls. Multi-sheet workbook with the platform's 20-column Schedule sheet (see Module 12 for round-trip).
• CSV / TSV — flat risk register. Schema auto-detection picks up ID, Description, Probability, three-point impacts, Category, Owner, etc.
• JSON — full project archive (re-import an exported project).
• PDF / Word / PowerPoint — unstructured documents. Parser extracts candidate risks for review; you confirm before they enter the register.

Anatomy of a risk record

Every risk record carries these fields:

• ID — unique identifier (R-001, R-002... or user-defined)
• Description — clear, specific risk statement (avoid generic "schedule risk" — describe the actual event)
• Category — risk category for grouping (Design, Procurement, Construction, Commissioning, External)
• Owner — person accountable for managing this risk
• Probability — 0–100% chance of firing during the project
• Three-point impacts — Min / Most Likely / Max for each dimension (Schedule days, Cost currency, Performance % loss)
• Per-KPI estimates — if you've defined custom KPIs, three-point per KPI overrides the legacy single "performance %"
• Activity links — risks linked to one or more activities anchor the impact spatially in the schedule
• Response strategy — Avoid / Reduce / Transfer / Accept
• Source citation — where this risk came from (workshop, SME interview, lessons learned)
• Apply-mode override — per-risk Add/Replace setting (see Module 05)

Probability × Impact

Two independent quantities. Probability is "how likely is this event to occur at all during the project life." Impact is "if it does occur, how bad is it." The product P × I gives you the expected value — useful for sorting but never a substitute for the full Monte Carlo run.

Risk categories

Categories enable grouping in tornado charts, sensitivity analysis, and reports. Default categories on a new project:

Add custom categories via Settings → Categories. The tornado view supports a "by category" tornado-mode to roll up sensitivity to the category level.

Risk vs Uncertainty — two registers

The platform distinguishes two types of variability:

Use both. A complete model has a risk register for things-that-might-happen and an uncertainty register for things-that-have-uncertain-magnitude-regardless. The QSRA / QCRA / QPRA tabs let you scenario-toggle between Pre (risks active), Post (mitigated risks), or Uncertainty-only (just the bands, no risk events).

Why link risks to activities

An unlinked risk is a project-level overlay — sampled days are added to the bottom-line schedule, not routed through any specific activity. This is fine for high-level risks ("strategic alignment shift") but loses precision for activity-specific risks.

A linked risk is routed through the CPM network. If the risk fires in a given iteration:

• The sampled time impact extends the linked activity's working duration in that iteration.
• The CPM forward-pass recomputes early start and early finish dates downstream.
• If the activity is on the critical path, the entire project shifts. If not, the activity may consume float silently — until it doesn't, and the path becomes critical.
• The PRA convention: each linked activity receives the full sampled impact. Multiple links = multiple parallel effects.

The activity picker in the risk dialog

Type-ahead search resolves on code or name. Click a result to add it as a chip. Click the × on a chip to unlink. Multiple chips = multiple linked activities (the risk's impact applies to each).

The chip's tooltip shows the activity's start/finish dates and duration. For in-progress activities, both original and remaining are displayed in the chip text.

The activity context block

Once you link one or more activities, the dialog renders a context panel directly below the chip area. This is the platform's calibration aid — it shows you the actual schedule footprint so your three-point estimates are grounded in reality.

The panel auto-aggregates if multiple activities are linked (heading becomes "Linked activities (N) — aggregated"). Resources shown are filtered to those ticked as performance-relevant in Settings → Performance → Resources.

Inline baseline strips above three-point inputs

Each impact section (Schedule, Cost, Performance) now carries a thin strip directly above the Min/ML/Max inputs. This is the operative reference for your estimate.

Multi-activity linkage and aggregation

When a risk is linked to multiple activities, both the engine and the dialog handle aggregation:

• In the engine — each linked activity independently receives the full sampled impact (PRA convention). If the sampled value is 20d and there are 3 links, each activity's working duration gains 20d in that iteration. The CPM forward-pass then determines which activity drives the project finish.
• In the dialog baseline display — durations and costs are summed across linked activities. The strip shows the totals (e.g. "Total remaining: 187d across 3 activities").
• Replace mode with multi-link — each linked activity's working duration is set independently to the sampled value, so each gets sample - this_activity's_remaining as its delta. Multiple replace-mode risks on overlapping activities accumulate deltas (additive engine consequence — slightly more pessimistic than pure replace; usually conservative).

The two modes — concept

The visual point: add mode lengthens the activity by the sampled amount. Replace mode resets the activity's remaining duration to the sampled amount, regardless of what was there before.

Worked example — Add mode

Worked example — Replace mode

The per-risk override + the global setting

Apply-mode is configurable at two levels:

When to use which

• Default Add globally — most projects, most risks. Standard Monte Carlo PRA convention.
• Per-risk Replace when an individual risk fundamentally re-bases the activity, not just adds to it. Examples: "Permit forces a complete redesign approach" (the activity is now a different activity), "Site access change makes the work much faster" (opportunity risk).
• Global Replace — rare, but useful for sensitivity testing ("if I treat all my estimates as the new totals, what's the P80?").

Settings → Advanced panel showing the global apply-mode dropdown introduced in Phase 13.

Scope: schedule and cost only

The apply-mode dropdown has no effect on the Performance dimension. Performance is structurally different:

• Performance is measured as percentage loss against 100% nominal, not as an absolute number.
• The sampled value IS already a delta (% reduction), not a candidate "new total".
• There's no XER-derived "remaining performance baseline" the way duration and cost have. Performance baselines are KPI definitions, not schedule data.
• Add and Replace would produce identical results for performance — sample - 0 = sample.

The dialog's performance baseline indicator carries an APPLY-MODE N/A badge to make this explicit. The explainer says: "Multiple risks compound via the global performance mode (mult / add / max) — the per-risk Add/Replace toggle has no effect on performance."

The core principle

Risks model future uncertainty. They can only affect work that has not yet happened. Work already completed is in the past, immutable, not subject to perturbation.

Why this matters — concrete comparison

Consider the same in-progress activity (90d original, 63d remaining), same risk (sample = 80d), with two different engine designs:

The replace-mode case is where the old approach went badly wrong. A pure "set the activity to 80d" treatment doesn't make physical sense for an in-progress activity — you can't un-burn the 27d already in the bank. The remaining-based engine handles this correctly by treating sample as the new remaining, then letting the engine derive the right delta.

Engine internals — how it's implemented

Inside simulate(), the platform precomputes two structures from App.activities:

// Precomputed once per simulation run (outside iteration loop)
const _remainDurByIdx = new Float64Array(network.acts.length);
for (let i = 0; i < network.acts.length; i++) {
  const a = network.acts[i];
  // Trust explicit 0 for completed activities; fall back only when missing
  _remainDurByIdx[i] = (a.remainDrtnDays != null)
    ? a.remainDrtnDays
    : (network.baseDuration[i] || 0);
}

// Per-risk baseline for replace-mode delta
const riskBaselines = risks.map(risk => {
  let baseSched = 0, baseCost = 0;
  String(risk.activityId || '').split(/[;,]/).forEach(code => {
    const a = App.activityIndex[code];
    if (!a) return;
    baseSched += (a.remainDrtnDays != null) ? a.remainDrtnDays : (a.origDrtnDays || a.drtnDays || 0);
    baseCost  += (a.remainCost     != null) ? a.remainCost     : (a.origCost     || 0);
  });
  return { baseSched, baseCost, mode: risk.applyMode || globalMode };
});

Then per iteration, workingDurations is reset from _remainDurByIdx (not network.baseDuration):

// Per-iteration reset — start from REMAINING, not original
workingDurations.set(_remainDurByIdx);

// Per-risk handling in inner loop
const inc = _replaceLinked
  ? (schedSample - _remainDurByIdx[links[li]])  // Replace: delta against remaining
  : schedSample;                                // Add: just the sample
workingDurations[links[li]] += inc;

// Cost — same pattern
cost += _replaceCost ? (costSample - _rb.baseCost) : costSample;

What changes practically

If you previously ran the same XER through a legacy build, expect these differences in the new (current) build:

• P80 schedule numbers may be lower on schedules with significant in-progress portions. The engine isn't double-counting burned time.
• Per-activity Confidence dates are sharper — early finish dates reflect remaining-from-data-date, not from project start.
• Replace-mode behaviour on in-progress activities is now correct — sample becomes the new remaining, not the new total elapsed.
• Completed activities (remain = 0) contribute zero to the CPM working durations, even when linked to risks. (You shouldn't link risks to completed activities, but if you do, they're a no-op.)

Same philosophy for cost

Cost dimension follows identical logic. The cost variable per iteration is a "delta over project baseline cost" — it represents additional cost beyond the planned remaining cost.

• _rb.baseCost is the sum of remaining costs of linked activities (from XER TASKRSRC remain_cost field, or backfilled from import).
• Add mode: cost += costSample — extra cost added to the project overrun.
• Replace mode: cost += (costSample - _rb.baseCost) — if sample is below remaining baseline, this can be negative (an opportunity / savings).

For a 100k-remaining-cost activity with a 30k replace-mode sample: cost += (30 - 100) = -70k. The project's cost forecast drops by 70k for that iteration, reflecting that the new remaining cost is lower than the planned remaining. Replace mode handles opportunity risks correctly.

Performance under the philosophy

Performance handling is consistent with the philosophy because:

• Each risk's sampled performance value IS a % loss — it's always relative.
• The loss conceptually applies to remaining work (which is the only work the simulation horizon covers).
• There's no need for an explicit "remaining performance baseline" because percentage loss is dimensionless.
• The perfMode setting (mult / add / max) controls how multiple losses compound. Default is multiplicative: retention = (1 - loss1) × (1 - loss2) × ...

Add/replace toggle is therefore N/A for performance — and the dialog says so explicitly. Module 5 covered the scope; Module 7 deep-dives the KPI framework.

Defining KPIs

Settings → Performance has the KPI table. Each KPI carries these attributes:

Per-KPI three-point estimates in the risk dialog

Once KPIs are defined, the risk dialog renders a grid where you enter Min/ML/Max per KPI. This replaces the single legacy "performance %" field.

Resources also appear in this grid (Phase 9 unification — "Resources ARE KPIs"). Tick a resource as performance-relevant in Settings → Performance → Resources, and it appears here for per-risk three-point input.

Resources from the schedule

When you load a Primavera XER, the parser reads the RSRC table (resource catalog) and TASKRSRC table (assignments). Each resource carries:

• Name + Code — from rsrc_name + rsrc_short_name
• Type — Labour, Material, Non-Labour
• UOM — from the UMEASURE table (units like crew-hr, m³, tonnes, kWh)
• targetQty / remainQty — aggregated from TASKRSRC target_qty / remain_qty across all assignments
• targetCost / remainCost — aggregated from TASKRSRC target_cost / remain_cost
• targetDurDays / remainDurDays — aggregated duration across assignments
• selectedForPerf — user-controlled tick; only ticked resources surface as performance KPIs

Why tick a resource as performance-relevant

Three things happen when a resource is ticked (selectedForPerf = true):

1. It appears in the per-KPI grid of every risk dialog. You can enter three-point % loss estimates against it.
2. The engine includes it in the per-KPI simulation pass (_simulateKpisOnly), producing per-resource P50/P80/P90 numbers.
3. If amplification is configured (Module 8), the engine multiplies impacts against this resource based on its consumption ratio.

Not every resource needs ticking. Tick only the ones that meaningfully drive project performance — typically the critical-path resources, scarce specialist resources, or anything that's near its capacity ceiling.

The per-KPI driver tornado

After a simulation, the QPRA dashboard shows a per-KPI driver tornado — the top risks ranked by Spearman rank correlation with each KPI's iteration outcome. This tells you "if you mitigate this one risk, which KPI shifts most".

Drivers are computed independently per KPI, so the same risk might be a high driver for one KPI and low for another. This is the value of the unified framework: a single risk register feeds into multiple KPI-specific dashboards.

Custom resources — what and when

XER schedules don't always contain every resource the project cares about. Some examples that warrant a custom resource:

• Specialist crews not modelled in the schedule (e.g. permits team, design review board)
• Environmental constraints (e.g. allowable noise hours, water-extraction permit volume)
• Capital constraints (e.g. drawdown limits, working capital)
• Stakeholder bandwidth (e.g. owner review hours, regulator engagement days)

Sanity-clamping on save: remainQty is bounded between 0 and targetQty. If you enter values outside this range, the platform clamps them silently.

The amplification concept

Real-world intuition: a project that's already consumed 90% of its specialist welding crew is more exposed to further perturbation than one at 30% consumed. Less buffer, fewer alternatives, more cascading impact.

The amplification math

Settings → Performance has two knobs:

• Resource consumption amplification (resourceAmp) — 0 to 2, default 0 (off)
• Amplification threshold (resourceAmpThreshold) — 0.5 to 0.95, default 0.8

function _resourceConsumptionMultiplier(metric) {
  if (metric.kind !== 'resource') return 1;
  const r = metric.resource;
  const orig = r.targetQty || 0;
  const remain = r.remainQty != null ? r.remainQty : orig;
  if (orig <= 0) return 1;
  const ratio = (orig - remain) / orig;
  const amp = App.settings.resourceAmp || 0;
  const threshold = App.settings.resourceAmpThreshold || 0.8;
  if (ratio <= threshold || amp <= 0) return 1;
  const excess = (ratio - threshold) / (1 - threshold);
  return 1 + amp * excess;
}

In words: at exactly the threshold, multiplier = 1. At 100% consumed, multiplier = 1 + resourceAmp. Linear in between.

Worked example

When to use amplification

• Late-stage projects with significant resource consumption — set resourceAmp > 0 to capture fragility.
• Greenfield projects — leave at 0 (default). Nothing's consumed yet.
• Stress-testing — set amp = 1.0 or 2.0 to model "what if our specialist resources are near their limit by month X."
• Threshold tuning — 0.8 (80% consumed = stressed) is the default. Lower it (e.g. 0.6) for projects where you want amplification to kick in earlier.

What lives in App.activities

{
  task_id: 'T12345', code: 'A-4010', name: 'Earthworks and foundations',
  wbs_id: '1.3.2', type: 'Task', status: 'Active',
  // Duration fields
  drtnDays: 90,           // target/planned (legacy)
  origDrtnDays: 90,       // from XER target_drtn_hr_cnt
  remainDrtnDays: 63,     // from XER remain_drtn_hr_cnt — USED BY ENGINE
  pctComplete: 30,
  // Schedule dates
  startISO: '2025-07-23', endISO: '2025-10-21',
  // Float & criticality
  tfDays: 0, ffDays: 0, isCritical: true,
  // Cost (aggregated from TASKRSRC)
  origCost: 850000, remainCost: 595000,
  // Per-resource assignment breakdown
  assignments: [{ rsrc_id: 5, targetQty: 3200, remainQty: 2240, targetCost: 850000, remainCost: 595000 }],
}

CPM forward-pass — the engine's heartbeat

Every simulation iteration:

1. Reset workingDurations to per-activity remaining (_remainDurByIdx)
2. Sample each risk; add sampled value (Add mode) or compute delta (Replace mode) to each linked activity's working duration
3. Run _cpmForwardPass(network, workingDurations, workES, workEF) — Kahn's topological sort + forward-pass honouring FS/SS/FF/SF lag
4. Compute cpmDelta = iterFinish - baselineCpmFinish for this iteration's schedule contribution

All four relationship types and lag values are honoured — from the XER's TASKPRED table or from Excel round-trip via _rebuildTaskRelationshipsFromImport.

Critical path identification

The Schedule tab can be filtered to "critical only" — activities with TF below the criticality threshold (default 1 day). Use this filter to identify candidate activities for risk linkage.

The simulate() function — high level

function simulate(risks, scenario) {
  // 1. Pre-compute (once per simulation)
  const network = _buildCPMNetwork();
  const riskActIdx = _buildRiskActivityMap(risks, network);
  const riskBaselines = risks.map(...);          // remaining-based
  const _remainDurByIdx = ...;                  // per-slot remaining
  
  // 2. Per-iteration loop (N = iterations)
  for (let it = 0; it < N; it++) {
    let sched = 0, cost = 0;
    workingDurations.set(_remainDurByIdx);
    
    for (let r = 0; r < risks.length; r++) {
      if (probSamples[r][it] > risk.effProb) continue;  // gate
      const schedSample = sampleDist(impSamples[r][it], min, ml, max, distTime);
      
      if (links.length > 0) {
        for (let li = 0; li < links.length; li++) {
          const inc = _replaceLinked
            ? (schedSample - _remainDurByIdx[links[li]])
            : schedSample;
          workingDurations[links[li]] += inc;
        }
      } else sched += schedSample;
      
      cost += _replaceCost ? (costSample - _rb.baseCost) : costSample;
      perfRetention *= Math.max(0, 1 - perfSample / 100);
    }
    
    const iterFinish = _cpmForwardPass(network, workingDurations, workES, workEF);
    schedTotals[it] = Math.max(0, iterFinish - baselineCpmFinish) + sched;
    costTotals[it] = cost;
    perfLosses[it] = (1 - perfRetention) * 100;
  }
  
  return processResults(schedTotals, costTotals, perfLosses, ...);
}

Sampling — Monte Carlo vs Latin Hypercube

• Monte Carlo (default) — Independent uniform draws. Robust, well-understood. Needs more iterations to converge (5,000–10,000 typical).
• Latin Hypercube — Stratified sampling. Converges with fewer iterations (2,000–5,000). Slightly biased estimator for far-tail percentiles (P95+) on heavily correlated inputs.

Convergence and reproducibility

After every run, the engine computes the relative standard error (RSE) of the schedule mean: RSE = (σ / √N) / μ. The Convergence slider sets the target (default 1%); when exceeded, an amber banner recommends N' = N × (RSE / target)².

Reproducibility: enable Seed Lock in Settings → Engine. The locked seed is captured in archive snapshots, the Run Log sheet, and report cover pages. Two analysts with the same locked seed get bit-identical results.

Scenarios — Pre / Post / Uncertainty

• Pre-mitigation — every risk uses raw probability and impact. The "untouched" view.
• Post-mitigation — every risk uses postProb / postImp (or scaled by mitEffect). Models project after planned mitigation.
• Uncertainty-only — no risk events fire; only activity-level uncertainty bands. Models inherent estimating noise.

The eleven shapes

Distribution choice guide

Correlation groups

Risks in the same correlation group sample their probability die-rolls together. Pooling three 50%-probability risks into one group → in any iteration either all three fire or none do.

Effect: increases variance of the sum (heavier right tail). Use when risks share a root cause — e.g. three weather-related risks driven by the same monsoon timing.

The 20 columns

Template and export workbook use the SAME 20 columns — single source-of-truth header (SCHEDULE_SHEET_HEADERS).

Predecessor / Successor format

A-1020 (FS,0d); A-1030 (SS,5d); A-1040 (FF,-2d)

• Types: FS Finish-to-Start, SS Start-to-Start, FF Finish-to-Finish, SF Start-to-Finish
• Lag: in days; negative = lead
• Parser is tolerant: (FS, 0d), (FS,0d), (FS 0d), and A-1020 alone (defaults FS,0d) all work

Resource format

Earthworks Crew (3200 crew-hr, 850000); Concrete Plant (400 hr, 240000)

• Format: <name> (<qty> <uom>, <cost>)
• Multiple assignments separated by semicolons
• On first import, remaining defaults to target (no consumption recorded). Refine via the resource editor afterward.

Round-trip flow

Filename pattern: <project_name>_Risk_Intelligence.xlsx for export, <project_name>_Risk_Intelligence_Template.xlsx for the empty template. Project name normalised (non-alphanumeric → underscore).

The Excel workbook

PDF reports

• Standard PDF — on-screen Report tab printed as PDF. Quick; methodology summary, top drivers, recommendations. Use for internal review.
• Detailed PDF — formal multi-page report: cover, executive summary, methodology with reproducibility statement, risk matrix, sensitivity drivers, per-risk appendix, per-KPI breakdown. Use for client deliverables and dispute panels.

Word export

The Word format wraps the Report tab's HTML in a Microsoft Word-compatible structure (Word-HTML with xmlns:o/w/Mso). Opens cleanly in Word for native editing — useful when the report needs annotation or further drafting.

Filename: <project_name>_Risk_Intelligence.doc

The Report tab structure

1. Executive Summary — three KPI tiles (P80 sched / cost / perf) + headline recommendations
2. Methodology — iteration count, sampling method, distribution choice, seed status
3. Per-Dimension Analysis — QSRA, QCRA, QPRA
4. 3a · Performance KPI Breakdown — per-KPI P50/P80/P90 table
5. 3b · Top Driver Risks per KPI — Spearman-ranked drivers for each KPI
6. Scenario Comparison — Pre vs Post deltas, mitigation effectiveness
7. 4b · Section — additional dimensional analysis
8. Risk Register Appendix + Sensitivity Drivers

Workshop facilitation patterns

• Capture the source citation for every risk. "Workshop 2026-04-12 · SME interview with K. Patel" is defensible; a blank source field is a vulnerability in a claim.
• Calibrate against the activity context. Use the remaining-duration baseline strip as your reality check. If you're entering 60d ML for an activity with 30d remaining, that's a replace-mode call, not an add.
• Don't conflate uncertainty with risk. Activity-level estimating uncertainty (Uncertainty register) is separate from discrete risk events (Risk register).
• Iterate on the apply-mode call. Default Add. Switch to Replace when the three-point estimates the new total, not additional time. Document reasoning in the Description.

Calibrating three-point estimates

• Min ≠ absolute lowest. The 10th–15th percentile. Use optimistic-but-plausible.
• ML = the most likely if everything goes as expected.
• Max ≠ apocalyptic. The 85th–90th percentile. Worst plausible given current info.
• Width check: Min and Max too close → BetaPert near-deterministic. Widen if the team has uncertainty.
• Skew check: Max − ML > 4 × (ML − Min) → heavily right-skewed. Consider LogNormal.

When Add, when Replace

• Use Replace when the three-point estimates the new total: contractor change, permit-driven redesign, fundamentally different execution approach.
• Stay Add when the three-point estimates additional impact: weather delays, scope additions, defect rework.
• Document the call in the risk description. Future reviewers should understand why this specific risk is in Replace mode.
• Don't mix without reason. Categorical consistency makes the rationale clear in audit.

Audit trail discipline

• Every override, sign-off, deletion, and material edit is logged automatically with timestamp + user.
• Use the Source / Citation field for traceability — workshop date, SME name, document reference.
• Use Review and Approve sign-offs (Settings → Categories → Reviewers) to capture two-eye gates on risk register edits.
• Archive snapshots at every major engagement milestone — "Pre-mitigation review", "Post-Apr workshop", "Final submission". The archive history acts as your audit trail.
• Export the Audit Trail CSV (Settings → Audit) at engagement close.

Common pitfalls

Master glossary

Filename conventions

Project name is normalised: non-alphanumeric characters become underscores. "ACME / Phase 2 Construction" becomes ACME_Phase_2_Construction.

Where to go from here

• Try a real XER end-to-end: load → review activities → link risks → run engine → publish report. The platform's intuition is hard to build without hands-on iteration.
• Read the Help tab in the app. It mirrors this training course plus has FAQ entries that capture answers to common engagement questions.
• Build a personal library of risk-source citations you trust. Workshop minutes, SME interview notes, lessons-learned databases. Reference these in the Source / Citation field consistently across projects.
• Pair-review. Every claim-package level analysis should have a second analyst review the register, distribution choices, apply-mode calls, and per-KPI estimates. The audit trail will capture the review.
• Iterate the methodology. Capture your own engagement-specific patterns. Keep them in a project README so the next analyst on the same engagement has continuity.