Resolve payment credential and CRM pipeline commitment boundaries

Add research on PCI/tokenized payment references vs login Credentials (Payment
Instrument Reference, Payment Mandate) and CRM Opportunity promotion thresholds
(Pipeline Pursuit, binding_trigger). Resolve OpenQuestions for both topics.
Update glossary, conceptual model, terminology, and downstream recommendations.

research/CorpusIndex.md

@@ -67,6 +67,8 @@ The repository is focused on research and terminology. The corpus should collect
 - `beneficial-ownership-kyc-boi.md`
 - `registry-identifier-subtypes.md`
 - `reputation-assurance-gradient.md`
+- `payment-credential-pci-boundary.md`
+- `crm-pipeline-commitment-threshold.md`
 
 ## Source Note Template
 

research/commercial-identity/commercial-identity-synthesis.md

@@ -91,6 +91,8 @@ Commercial Commitment + Evidence, not declared ad hoc.
   subtypes with authority class, ICD scheme, and renewal lifecycle.
 - **Counterparty Assurance Gradient** — opinion → observed → committed →
   adjudicated; Reputation Signal, Performance Evidence, Adjudication Outcome.
+- **Payment Instrument Reference** + **Payment Mandate** — PCI boundary; not Credential.
+- **Pipeline Pursuit** — CRM Opportunity before Commercial Commitment promotion.
 
 ### Unchanged roots
 
@@ -103,7 +105,9 @@ Commercial Commitment + Evidence, not declared ad hoc.
 Model as lifecycle events, not silent merges:
 
 - Lead → Account (CRM conversion): weak → medium evidence.
-- Trial → paid subscription: attach Commercial Commitment + payment Credential.
+- Opportunity opened: Pipeline Pursuit — not Commercial Commitment until binding trigger.
+- Trial → paid subscription: Commercial Commitment (subscription) + Payment Mandate
+  + Payment Instrument Reference.
 - Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
 - Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.
 
@@ -117,7 +121,8 @@ Model as lifecycle events, not silent merges:
 
 ## Research Gaps
 
-- Payment Credential vs. authentication Credential boundary in PCI contexts.
+- Standard `binding_trigger` enum across CRM adapters.
+- Network token (Visa VTS) mapping to Payment Instrument Reference.
 - Smart contracts and automated Commercial Commitment lifecycle.
 - Synonymity strength bands for LEI ↔ DUNS ↔ company reg crosswalks.
 - Cross-platform reputation portability (Synonymity between Reputation Signals).
@@ -136,6 +141,8 @@ Model as lifecycle events, not silent merges:
 - `beneficial-ownership-kyc-boi.md`
 - `registry-identifier-subtypes.md`
 - `reputation-assurance-gradient.md`
+- `payment-credential-pci-boundary.md`
+- `crm-pipeline-commitment-threshold.md`
 - `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
 - `../commercial-subscription/stripe-customer-billing.md`
 

research/commercial-identity/crm-pipeline-commitment-threshold.md

@@ -0,0 +1,154 @@
+# CRM Pipeline and Commercial Commitment Threshold
+
+## Source Type
+
+Product data model and sales-operations synthesis. Salesforce Opportunity stages,
+forecast categories, and contract-law binding thresholds.
+
+## Domain
+
+When CRM pipeline artifacts (Opportunity, deal stage, forecast) constitute
+canonical **Commercial Commitment** vs. provisional pursuit evidence only.
+
+## Why This Source Matters
+
+Salesforce **Opportunity** tracks potential revenue — but most pipeline stages are
+**forecasts**, not enforceable obligations. Treating every Opportunity as
+Commercial Commitment would:
+
+- falsely elevate identity binding during early prospecting;
+- collide with **Counterparty Assurance Gradient** (pipeline ≠ committed tier);
+- ignore that **Closed Won** often precedes executed contract in real orgs.
+
+Canon needs a **promotion threshold** — when pipeline becomes commitment.
+
+## Key Concepts
+
+### Salesforce Opportunity model
+
+- **Opportunity**: deal record tied to Account; amount, stage, close date, forecast.
+- **Stage**: position in sales process (e.g., Prospecting → Proposal → Negotiation
+  → Closed Won / Closed Lost).
+- **Forecast category**: Pipeline, Best Case, Commit, Closed — revenue prediction
+  semantics, not legal commitment.
+- **Closed Won**: deal marked won in CRM — operational signal; may or may not
+  coincide with signed contract depending on org process.
+- **Closed Lost**: pursuit ended — no commitment.
+- **Quote / Order** (CPQ): closer to binding when customer accepts quote or order
+  is placed — stronger evidence than early stage.
+
+### Binding threshold (legal/commercial)
+
+A **Commercial Commitment** requires evidenced obligation that raises counterparty
+reliance — aligned with canon definition and tier 3 assurance:
+
+| Signal | Binding strength | Canon treatment |
+| --- | --- | --- |
+| Lead created | None | Pipeline Pursuit or weak Commercial Record |
+| Opportunity Prospecting | None | Pipeline Pursuit |
+| Opportunity Proposal | Low | Pipeline Pursuit + stage Evidence |
+| Signed quote / LOI | Medium | Commercial Commitment `proposed` |
+| Executed PO / order | High | Commercial Commitment `active` |
+| Closed Won (CRM only) | Org-dependent | `proposed` until contract Evidence |
+| Signed MSA / SOW | High | Commercial Commitment `active` |
+| Active subscription (Stripe) | High | Commercial Commitment `active` (billing) |
+
+**Rule:** CRM stage alone is **never sufficient** for `active` Commercial Commitment
+unless org policy equates Closed Won with executed agreement **and** that policy
+is recorded as Evidence Source (downstream configuration).
+
+### Fluid-to-bound transition
+
+Lead → Account conversion raises commercial attribution (Organization +
+Commercial Record). Opportunity creation adds **Pipeline Pursuit**. Commitment
+materializes only at binding trigger — not at Opportunity create.
+
+## Modeling Assumptions
+
+- **Pipeline is prospective** — counterparties may rely for forecasting internally
+  but external legal reliance is limited until commitment artifacts exist.
+- **Multiple Opportunities** per Account are normal; commitments may coexist.
+- **Opportunity amount** is expected value, not obligation amount until contracted.
+- **Forecast Commit category** (Salesforce) is sales-team confidence, not legal
+  commitment — do not map to Commercial Commitment `active`.
+- **CPQ Quote accepted** or **e-signature completed** are valid binding triggers
+  with Evidence Source.
+
+## Identity-Canon Implications
+
+### Resolved: Opportunity is not Commercial Commitment by default
+
+Map Salesforce **Opportunity** (and HubSpot deal, etc.) to **Pipeline Pursuit** —
+Record layer artifact for in-flight commercial deal pursuit.
+
+**Pipeline Pursuit** fields:
+
+- `source_system` — Salesforce, HubSpot, etc.
+- `stage` — vendor stage name (Prospecting, Negotiation, Closed Won, …)
+- `forecast_category` — pipeline, best_case, commit, closed
+- `expected_amount`, `expected_close_date`
+- `linked_commercial_record` — CRM Account / Commercial Record
+- `lifecycle_state` — open, won, lost, abandoned
+- `binding_status` — `none` | `proposed` | `active` (derived from evidence, not stage alone)
+
+### Promotion to Commercial Commitment
+
+Create or activate **Commercial Commitment** only when `binding_trigger` satisfied:
+
+| Trigger | Commitment state | Evidence |
+| --- | --- | --- |
+| Signed LOI / quote acceptance | `proposed` | Document, e-sign event |
+| Executed PO / order | `active` | Order record |
+| Closed Won + contract on file | `active` | Contract Evidence Source |
+| Subscription checkout complete | `active` | Stripe webhook (billing) |
+| Stage-only Closed Won | **No auto-promotion** | Pipeline Pursuit `won` only |
+
+**Pipeline Pursuit** may **reference** a Commercial Commitment once promoted;
+do not replace Opportunity with commitment in CRM adapters — mirror both.
+
+### What Opportunity stage provides
+
+Stage changes produce **Evidence Source** events on Pipeline Pursuit (observed
+tier — internal sales telemetry). They support **Trust Relationship** only for
+**internal** vendor forecasting, not external counterparty assurance at tier 3.
+
+### Lead and Account (unchanged)
+
+- **Lead** → provisional prospect (weak Commercial Record or Pipeline Pursuit seed).
+- **Account** → **Commercial Record** + Organization.
+- **Opportunity** → **Pipeline Pursuit** (not Commercial Commitment).
+
+## Terminology Conflicts
+
+- **Opportunity (CRM)** vs. **Commercial Commitment**: forecast vs. obligation.
+- **Forecast Commit (Salesforce)** vs. **Commercial Commitment (canon)**: homonym disaster.
+- **Closed Won** vs. **contract signed**: CRM ops vs. legal binding.
+- **Deal (informal)** vs. **Pipeline Pursuit**: resolve to Pipeline Pursuit.
+
+## Candidate Canonical Mappings
+
+| CRM concept | Canonical mapping |
+| --- | --- |
+| Account | Commercial Record + Organization |
+| Contact | Natural Person |
+| Lead | Pipeline Pursuit (seed) / weak Commercial Record |
+| Opportunity | Pipeline Pursuit |
+| Stage change | Evidence Source on Pipeline Pursuit |
+| Quote accepted | Commercial Commitment `proposed` |
+| Order / contract executed | Commercial Commitment `active` |
+| Closed Lost | Pipeline Pursuit lifecycle `lost` |
+| Forecast category "Commit" | Pipeline Pursuit metadata only |
+
+## Open Questions
+
+- Standard `binding_trigger` enum for cross-CRM adapters.
+- Whether **renewal Opportunity** on existing contract is Pipeline Pursuit or
+  commitment amendment (lean: amendment on existing Commercial Commitment).
+- Partner Opportunity vs. customer Opportunity — same Pipeline Pursuit type with role metadata.
+
+## References
+
+- Salesforce Opportunity object — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm
+- Shellblack, Salesforce data model overview — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
+- Internal: `salesforce-crm-commercial-record.md`, `commercial-identity-synthesis.md`,
+  `reputation-assurance-gradient.md`, `legal-person-agency-contract.md`

research/commercial-identity/payment-credential-pci-boundary.md

@@ -0,0 +1,167 @@
+# Payment Credential Boundary — PCI and Commercial Commitment
+
+## Source Type
+
+Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment
+Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment
+separation.
+
+## Domain
+
+Payment instruments on billing customers — what belongs in canonical identity
+model vs. PCI-scoped downstream vaults, and how charge authorization relates to
+Commercial Commitment.
+
+## Why This Source Matters
+
+Stripe **Customer** objects carry **payment methods**, and canon **Credential**
+already covers secrets and proof material. Collapsing them causes two failures:
+
+1. **PCI scope bleed** — modeling PAN, CVV, or vault secrets in identity canon
+   implies they belong in general identity stores.
+2. **Semantic collision** — login passkeys and payment mandates both "authorize
+   something" but authorize **authentication** vs. **commercial debit**.
+
+Payment methods are commercially binding (tier 3 assurance) when they encode
+**mandate to charge** — but the binding artifact is the **authorization/commitment**,
+not the token reference.
+
+## Key Concepts
+
+### PCI DSS data categories
+
+- **CHD (cardholder data)**: PAN, cardholder name, expiration, service code.
+- **Sensitive authentication data (SAD)**: CVV/CVC, full track data, PIN — never
+  stored after authorization per PCI.
+- **Token**: surrogate value replacing PAN; if properly implemented, token in
+  merchant environment is **out of PCI CHD scope** (PCI tokenization guidelines).
+- **Scope principle**: systems that store, process, or transmit CHD fall under PCI;
+  token references (`pm_xxx`) in app DBs are not CHD when only the token exists.
+
+### Stripe payment object model
+
+- **PaymentMethod** (`pm_xxx`): reusable payment details attached to Customer;
+  contains type-specific non-transaction data (last4, fingerprint, billing details).
+- **SetupIntent**: establishes future off-session payment — creates mandate to charge.
+- **PaymentIntent**: one-time or reusable charge attempt.
+- **Customer**: billing container; payment methods attach here, not to login User.
+- **Mandates** (SEPA, Bacs, etc.): explicit customer authorization for debits.
+
+### Authentication vs. payment authorization
+
+| Dimension | Authentication credential | Payment authorization |
+| --- | --- | --- |
+| Proves | Identity / session control | Right to debit funds |
+| Scope | IdP, app login, federation | Payment network / acquirer |
+| Regulation | NIST 800-63, OIDC | PCI DSS, PSD2 SCA, Nacha |
+| Canon home | Credential | Payment Mandate (Commercial Commitment) |
+| Secret handling | Passkey, password hash | CHD in vault only; token ref in app |
+
+## Modeling Assumptions
+
+- **Canon is implementation-neutral** but must not encourage CHD in identity layers.
+- **Payment provider owns payment truth**; app holds references and commitment state.
+- **Reusable payment method** implies **Commercial Commitment** (payment mandate)
+  when customer consented to future charges (SetupIntent succeeded, card on file).
+- **Single-use payment methods** may exist only for one PaymentIntent — weaker
+  commitment, often no reusable mandate.
+- **Subscription** is separate Commercial Commitment (recurring service obligation);
+  payment mandate is **enabling** commitment for collection.
+- **Webhook events** (`setup_intent.succeeded`, `payment_method.attached`) are
+  **Evidence Source** for mandate lifecycle.
+
+## Identity-Canon Implications
+
+### Resolved: do not map payment methods to Credential
+
+**Credential** in canon covers authentication, federation, and entitlement proof
+(passkey, password, certificate, VC). **Payment methods are not Credentials.**
+
+Raw CHD and SAD are **out of canon entirely** — downstream PCI vault / payment
+provider only.
+
+### Payment Instrument Reference
+
+Add **Payment Instrument Reference** — Reference layer value scoped to a payment
+provider (Stripe `pm_xxx`, fingerprint, display last4, mandate ID). Links to
+**Commercial Record**, not to login **Account**.
+
+Properties:
+
+- `provider_scope` — Stripe account, Adyen merchant, etc.
+- `instrument_type` — card, sepa_debit, us_bank_account, etc.
+- `reference_id` — provider token (not PAN).
+- `reusable` — boolean.
+- `lifecycle_state` — attached, detached, expired, revoked.
+
+This is a **Scoped Identifier** specialization, not a Credential.
+
+### Payment Mandate as Commercial Commitment
+
+When a customer authorizes future charges (SetupIntent success, SEPA mandate
+signed, card saved with explicit consent), model **Payment Mandate** as a
+**Commercial Commitment** subtype:
+
+- `commitment_type: payment_mandate`
+- `lifecycle_state`: proposed → active → revoked → expired
+- Parties: customer actor (via Commercial Record) and vendor/payment facilitator
+- **Evidence Source**: SetupIntent result, mandate document, SCA proof metadata
+- `assurance_tier: committed` on Counterparty Assurance Gradient
+
+**Subscription** remains `commitment_type: subscription` — distinct but often
+co-created at checkout.
+
+### Commercial Record role
+
+**Commercial Record** (Stripe Customer) **references** payment instrument refs
+and **hosts** links to Payment Mandate commitments. Do not embed CHD attributes
+in Commercial Record canon fields — only provider references and lifecycle flags
+(`delinquent`, default payment method ref).
+
+### Layer diagram
+
+```text
+Login Account          → Credential (passkey, password)
+Commercial Record      → Payment Instrument Reference (pm_xxx)
+Commercial Commitment  → Payment Mandate + Subscription
+PCI Vault / Stripe     → CHD (downstream only, not canon)
+Evidence Source        → webhooks, mandate PDF, SCA audit
+```
+
+## Terminology Conflicts
+
+- **Payment method (Stripe)** vs. **Credential (canon)**: both grant "permission"
+  but different permission domains.
+- **Payment credential (informal)** vs. **Credential (glossary)**: avoid informal
+  phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
+- **Saved card** vs. **payment mandate**: saved token may exist before explicit
+  off-session mandate — lifecycle `proposed` until SetupIntent completes.
+- **customer_account (Stripe)** vs. **Account (login)**: reinforces commercial split.
+
+## Candidate Canonical Mappings
+
+| Source artifact | Canonical mapping |
+| --- | --- |
+| PAN / CVV | Out of canon (PCI downstream) |
+| PaymentMethod `pm_xxx` | Payment Instrument Reference |
+| SetupIntent succeeded | Payment Mandate Commercial Commitment + Evidence |
+| Subscription object | Commercial Commitment (subscription) |
+| Default payment method | Reference on Commercial Record |
+| Payment webhook | Evidence Source |
+| 3DS / SCA step-up | Evidence Source on mandate (not Credential) |
+| Passkey for login | Credential (unchanged) |
+
+## Open Questions
+
+- Network tokens (Visa VTS) — same Payment Instrument Reference pattern?
+- Shared payment methods across Stripe org customers — scope on reference.
+- Wallet balances (Stripe Customer balance) — Commercial Record attribute vs. commitment.
+
+## References
+
+- PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
+- Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
+- Stripe Customer object — https://docs.stripe.com/api/customers/object
+- Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
+- Internal: `../commercial-subscription/stripe-customer-billing.md`,
+  `reputation-assurance-gradient.md`, `commercial-identity-synthesis.md`

research/commercial-identity/salesforce-crm-commercial-record.md

@@ -73,14 +73,20 @@ a company or household you sell to, distinct from **Contact** (people) and **Use
 | Account-Contact Relationship | Affiliation / Representation |
 | Account hierarchy | Organization structure Relationship |
 | Lead | Prospective Commercial Record (weak) |
-| Opportunity | Commercial Commitment (pipeline stage) |
+| Opportunity | Pipeline Pursuit (promotes to Commercial Commitment on binding trigger) |
 | User | Account (internal operator) |
 | Person Account | Commercial Record + Natural Person (combined projection) |
 
 ## Open Questions
 
-- Should pipeline Opportunity map to Commercial Commitment subtype or downstream only?
 - How should Person Account be discouraged in canon-aligned adapters?
+- Renewal Opportunity — Pipeline Pursuit vs. commitment amendment.
+
+## Resolved (see crm-pipeline-commitment-threshold.md)
+
+- Opportunity → **Pipeline Pursuit**; Commercial Commitment only on binding trigger
+  (signed LOI/quote, executed PO/contract, active subscription). Forecast "Commit"
+  category is not Commercial Commitment.
 
 ## References
 

research/commercial-subscription/stripe-customer-billing.md

@@ -80,7 +80,8 @@ customer** that is explicitly not a login account. It demonstrates why
 | --- | --- |
 | Customer object | Commercial Record |
 | Subscription | Commercial Record lifecycle / entitlement metadata |
-| Payment method | Credential (payment instrument) — downstream |
+| Payment method | Payment Instrument Reference (not Credential) |
+| SetupIntent / mandate | Payment Mandate (Commercial Commitment) |
 | Metadata.tenant_id | Identifier binding to Tenant Scope |
 | business_name | Commercial Record attribute |
 | individual_name | Commercial Record attribute (person-backed) |
@@ -90,11 +91,14 @@ customer** that is explicitly not a login account. It demonstrates why
 
 ## Open Questions
 
-- Should payment methods on Commercial Record map to Credential in canon, or
-  remain strictly downstream PCI-scoped artifacts?
 - Does sole-proprietor billing (person-backed Commercial Record without
   Organization) need a distinct pattern in scenario tests?
 
+## Resolved (see payment-credential-pci-boundary.md)
+
+- Payment methods → **Payment Instrument Reference**; mandates → **Payment Mandate**.
+  CHD out of canon; not **Credential**.
+
 ## References
 
 - Stripe Customer object — https://docs.stripe.com/api/customers/object