The ICP Decision Record: Versioning Assumptions, Changes, and Ownership

Who this playbook is for

This playbook is for the business owner, research lead, revenue operations team, and affected commercial roles responsible for maintaining an ICP. It is valuable once an ICP influences list building, scoring, routing, outreach, qualification, reporting, or account ownership and informal document edits are no longer safe.

Contents

1 Define the authoritative decision record 2 Capture scope, assumptions, and evidence 3 Choose version and status rules 4 Review and approve proposed changes 5 Set effective dates and migrate work 6 Preserve history, exceptions, and reporting 7 Schedule reviews and event triggers 8 Illustrative example 9 Common mistakes 10 What this does not mean 11 Common questions 12 Sources and methodology

1. Define the authoritative decision record

The record should answer:

• What exact account, facility, application, and relationship does this ICP describe?

• What commercial decision is it authorized to make?

• Which criteria, gates, exclusions, and evidence rules apply?

• Which assumptions remain unproven?

• Which version is active, and from what date?

• Who owns, reviews, and approves it?

• How were existing accounts and active work handled?

• When must it be reviewed again? Keep one authoritative record and link summaries back to it. Slide decks, CRM labels, list queries, and campaign briefs should reference the ICP ID and version rather than carrying divergent copies. Configuration management is an established discipline for identifying versions and baselines and controlling changes. A NIST configuration-management concepts publication describes identifying components, versions, and baselines and recording changes in its original product-data context. NIST, Configuration Management Concepts Document SellersGPT adapts the traceability principle to editorial ICP governance; it does not claim that an ICP is an information system or that the cited document is a sales standard.

2. Capture scope, assumptions, and evidence

The record needs these sections: Identity and scope

• ICP ID, name, version, status;

• product and application;

• relationship type;

• geography;

• unit of analysis;

• authorized decision and exclusions. Decision logic

• inclusion criteria and weights;

• hard gates and outcomes;

• negative ICP;

• evidence states;

• minimum coverage;

• routing outputs. Assumption register Assumption Why it matters Current evidence State Failure consequence Next test [Claim] [Decision impact] [Sources] Confirmed/Contradi cted/Unknown [Action] [Owner/date] Evidence register Store source, claim, entity level, observation period, retrieval date, scope, limitations, and reviewer note. GAO's data-reliability guide emphasizes accuracy, completeness, and applicability for the intended purpose. GAO, Assessing Data Reliability The decision record should therefore explain why evidence is suitable for the decision, not only where it came from.

3. Choose version and status rules

Use a simple policy:

• Major version ( 2.0): changes eligible population, application, relationship type, gate, exclusion, scoring meaning, or authorized motion.

• Minor version ( 1.1): clarifies evidence, adds a compatible source, adjusts implementation, or corrects a definition without intentionally changing eligibility.

• Patch or editorial correction ( 1.1.1, if used): fixes presentation or a non-decision error. Before labeling a change minor, test whether account decisions actually remain stable. A new threshold described as clarification may change many records and therefore require a major version. Use statuses: draft, validation, approved, active, under review, superseded, and retired. Only active versions should drive new production decisions. NIST defines a configuration baseline in its systems context as a formally reviewed and agreed set of specifications that changes through change control. NIST CSRC, Configuration Baseline The useful analogy is an approved point-in-time reference. For ICPs, the business team must define its own approval and risk controls.

4. Review and approve proposed changes

Every proposal should contain:

• change ID and proposer;

• current and proposed version;

• exact before-and-after text;

• trigger and evidence;

• affected products, regions, relationship types, fields, and systems;

• estimated account impact;

• alternative explanations;

• validation plan and result;

• migration and rollback plan;

• owner and approver decision. Use a decision gate: Question Pass condition Is the problem material? It changes eligibility, action, quality, risk, or reproducibility Is the evidence applicable? Unit, geography, period, and source scope match Were alternatives tested? Data, classification, timing, and exposure effects considered Is the change reproducible? Reviewers can apply the new rule consistently Is migration controlled? Active accounts, tasks, and reports have explicit treatment Is ownership clear? Named accountable roles approve and operate it Do not approve based solely on one large deal, one failed campaign, or one executive preference. Record those as triggers and test the general decision consequence.

5. Set effective dates and migrate work

Separate:

• approval date;

• effective date for new research;

• migration cutoff for active work;

• reporting availability date;

• next review date. Build a migration inventory: Object Possible action Existing account assignments Preserve old assessment; add current reassessment Research tasks Continue, cancel, or regenerate under new rules Active outreach Continue if still eligible, pause for review, or stop Suppression Preserve unless the evidence and scope justify change Scores and queues Recalculate under new version with separate timestamp Reports Keep historical version; add bridge for future reporting Related documents Update references to active version Do not make the effective date retroactive merely to simplify reporting. If an account was qualified under version 1.0, store that historical fact and any new assessment under version 2.0 separately.

6. Preserve history, exceptions, and reporting

An immutable decision history contains:

• version and status changes;

• exact criteria and formulas;

• source and assumption snapshots;

• validation set and result;

• approvals and dates;

• migration actions;

• exceptions and expiry;

• superseding version. An exception must specify account or scope, rule waived or altered, rationale, approver, start, expiry, monitoring, and whether it can influence a future general change. Exceptions should not silently become the new rule. When a data system changes, preserve the version. The Census Bureau's NAICS site provides several historical revisions, concordances, reference files, and update information. U.S. Census Bureau NAICS A classification revision can change a query or universe without changing commercial reality; the record must distinguish technical migration from ICP strategy. For SEC data, EDGAR APIs document submissions and XBRL data structures and update behavior. SEC EDGAR APIs If a source interface or field changes, update the research implementation and retain the old provenance rather than rewriting earlier evidence.

7. Schedule reviews and event triggers

Use both calendar and event-driven review. Calendar review Set frequency from volatility, scale, and consequence. A stable application may use a longer interval than a rapidly changing partner or access rule. The record should state why the cadence is sufficient. Event triggers

• offer, price, service, or delivery change;

• new region or relationship type;

• repeated gate failures or unknown concentration;

• material classification or source revision;

• acquisition, facility, or ownership change;

• repeated evidence that a criterion no longer discriminates;

• compliance, procurement, or access change;

• conflicting local ICP variants;

• unexpected outcomes that survive exposure and data-quality checks. Every trigger opens review; it does not automatically change the ICP. The owner decides retain, clarify, validate, supersede, or retire. Track overdue reviews separately from expired evidence. An ICP can remain active while certain account claims require refresh, or it can be placed under review when the governing definition itself is uncertain.

8. Illustrative example

Illustrative example - fictional. A fictional industrial supplier approves ICP version 2.0 after adding a mandatory local-service gate. It has 240 historical account assessments under version 1.2 and 64 open research or outreach records requiring migration. The 240 historical assessments remain attributed to v1.2. The 64 open records are reassessed under v2.0:

• Gate pass: 38.

• Gate fail: 14.

• Gate unknown: 12.

• Check: 38 + 14 + 12 = 64. Migration shares are:

• Continue under v2.0 = 38 / 64 x 100 = 59.4%.

• Stop this motion = 14 / 64 x 100 = 21.9%.

• Hold for service evidence = 12 / 64 x 100 = 18.8% after rounding. The effective date is September 1, 2026. New research uses v2.0 from that date; open records must migrate before further contact. Historical v1.2 reports are not restated. The numbers are fictional governance counts, not a customer result or forecast.

9. Common mistakes

• Keeping several authoritative copies: CRM, deck, and research brief disagree.

• Editing the active version in place: historical attribution becomes impossible.

• Calling material threshold changes minor: account eligibility shifts without migration.

• Using one deal as general proof: an exception becomes a segment rule.

• Skipping effective dates: teams switch at different times.

• Rescoring history silently: past and current decisions are mixed.

• Migrating accounts but not tasks: old outreach continues under retired rules.

• Assigning ownership to a system: no accountable business role can approve or resolve change.

10. What this does not mean

Governance does not mean every edit requires a committee or long delay. Risk-based authority can make low-impact corrections quickly while preserving the log. A decision record does not prove that an ICP is correct; it makes the current hypothesis, evidence, uncertainty, and accountability inspectable. It does not expose private prompts, model routing, or internal security controls, and it does not replace specialist judgment.

11. Common questions

Who should own the ICP? A named business role accountable for the product-market and commercial decision should own it, supported by research and operations. A software field or external vendor cannot hold accountability. Should old accounts be rescored after every minor change? Only when the impact assessment shows the change affects current decisions or evidence. Preserve the old assessment and create a new one rather than overwriting. How should emergency changes work? Allow a documented temporary control with scope, owner, reason, effective time, expiry, and mandatory retrospective review. Urgency should not erase history. Can different regions have overlays under one version? Yes, if the portable core and governance are common and overlays are versioned, owned, and validated. If decision logic diverges materially, create separate ICPs. What is the minimum useful change log? Version, date, proposer, exact change, reason, evidence, decision impact, approver, effective date, migration, and superseded record.

12. Sources and methodology

NIST sources provide configuration-management and baseline concepts in their original technical contexts; GAO provides a purpose-based data-reliability framework; Census and SEC document evolving official data systems. SellersGPT adapts traceability principles into an ICP decision-record playbook. This is not a NIST, GAO, Census, or SEC sales standard. 1 National Institute of Standards and Technology, Configuration Management Concepts Document. https://www.nist.gov/publications/configuration-management-concepts-document. Accessed August 24, 2026. 2 National Institute of Standards and Technology, Configuration Baseline - CSRC Glossary. https://csrc.nist.gov/glossary/term/configuration_baseline. Accessed August 24, 2026. 3 U.S. Government Accountability Office, Assessing Data Reliability (GAO-20-283G). https://www.gao.gov/products/gao-20-283g. Accessed August 24, 2026. 4 U.S. Census Bureau, North American Industry Classification System. https://www.census.gov/naics/. Accessed August 24, 2026. 5 U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces. https://www.sec.gov/search-filings/edgar-application-programming-interfaces. Accessed August 24, 2026.