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.

DownstreamRecommendations.md

@@ -131,4 +131,8 @@ later explicit package is extracted.
 - Map PAYDEX, SLA metrics, and credit bureau data to Performance Evidence (observed tier).
 - Map bonds, escrow, and signed SLAs to Commercial Commitment (committed tier).
 - Map arbitration awards and court judgments to Adjudication Outcome (adjudicated tier).
-- Trust Relationship projections must cite assurance_basis tier; weight opinion weak by default.
+- Trust Relationship projections must cite assurance_basis tier; weight opinion weak by default.
+- Never store PAN/CVV in identity-layer stores; use Payment Instrument Reference only.
+- Map SetupIntent/mandate success to Payment Mandate Commercial Commitment.
+- Map CRM Opportunity to Pipeline Pursuit; promote to Commercial Commitment only on binding_trigger.
+- Do not treat Salesforce Forecast "Commit" as Commercial Commitment active state.

OpenQuestions.md

@@ -167,14 +167,18 @@ evidenced obligations that raise counterparty reliance and make identity less fl
 
 ### Commercial Commitment placement
 
-**Status:** Tentatively resolved — first-class Relationship-layer concept.
+**Status:** Resolved — first-class concept with explicit promotion thresholds.
 
-Contracts, subscriptions, payment mandates, and regulated onboarding acceptance
-map to **Commercial Commitment** attached to Commercial Relationship or
-Commercial Record. See `commercial-identity-synthesis.md`.
+Contracts, subscriptions, payment mandates, purchase orders, and regulated
+onboarding map to **Commercial Commitment**. CRM **Opportunity** maps to
+**Pipeline Pursuit** — not commitment until `binding_trigger` (signed LOI/quote,
+executed PO/contract, active subscription). Salesforce Forecast "Commit" is
+pipeline metadata only.
 
-**Remaining:** Whether pipeline stages (CRM Opportunity) are commitments or
-downstream-only.
+**Citations:**
+
+- `research/commercial-identity/crm-pipeline-commitment-threshold.md`
+- `research/commercial-identity/commercial-identity-synthesis.md`
 
 ### Beneficial Owner modeling
 
@@ -245,10 +249,18 @@ OPI modeling under ISO 6523.
 
 ### Payment credential boundary
 
-**Status:** Open (downstream-heavy).
+**Status:** Resolved — Payment Instrument Reference + Payment Mandate; not Credential.
 
-Whether payment methods on Commercial Record map to Credential in canon or remain
-PCI-scoped downstream artifacts only.
+**Decision:** Do not map payment methods to **Credential**. CHD (PAN, CVV) is
+out of canon (PCI downstream). Tokenized provider references (`pm_xxx`) map to
+**Payment Instrument Reference** on **Commercial Record**. Customer authorization
+to charge maps to **Payment Mandate** (**Commercial Commitment**,
+`commitment_type: payment_mandate`). Login credentials remain separate.
+
+**Citations:**
+
+- `research/commercial-identity/payment-credential-pci-boundary.md`
+- `research/commercial-subscription/stripe-customer-billing.md`
 
 ## New Questions From Corpus Review
 

canon/CanonicalGlossary.md

@@ -104,6 +104,11 @@ Evidence or secret material used to prove control, entitlement, or a claim.
 Examples: password, passkey, certificate, hardware token, verifiable
 credential, recovery code, signed assertion.
 
+Excludes: payment card PAN, CVV, track data, and other PCI cardholder data —
+those stay in payment-provider or PCI-scoped downstream vaults. Excludes
+tokenized payment method references (`pm_xxx`); use **Payment Instrument
+Reference** and **Payment Mandate** instead.
+
 ## Claim
 
 A statement made by an issuer or source about an actor, account, identifier,
@@ -239,12 +244,55 @@ An evidenced obligation that binds commercial parties and raises the cost of
 identity fluidity for counterparties.
 
 Examples: signed contract, active subscription, payment mandate, regulated
-onboarding acceptance, qualified electronic seal on an agreement.
+onboarding acceptance, qualified electronic seal on an agreement, executed
+purchase order.
 
 Commercial Commitment carries lifecycle state (proposed, active, breached,
 fulfilled, expired, revoked) and may attach to Commercial Relationship,
 Commercial Record, or Legal Entity/Organization actors.
 
+Recommended `commitment_type`: `contract` | `subscription` | `payment_mandate` |
+`regulatory_onboarding` | `purchase_order` | other.
+
+Does not include CRM pipeline stages by default — see **Pipeline Pursuit**.
+Salesforce Forecast "Commit" category is sales confidence, not this concept.
+
+## Payment Instrument Reference
+
+A **Scoped Identifier** for a tokenized payment instrument in a payment-provider
+scope — not PAN, not a login **Credential**.
+
+Examples: Stripe `pm_xxx`, SEPA mandate reference, network token ID, display
+last4 + fingerprint.
+
+Links to **Commercial Record**. Carries `provider_scope`, `instrument_type`,
+`reusable`, and `lifecycle_state` (attached, detached, revoked). CHD stays
+downstream; canon holds references only.
+
+## Payment Mandate
+
+A **Commercial Commitment** (`commitment_type: payment_mandate`) authorizing
+future charges against a **Payment Instrument Reference**.
+
+Created when customer consent is evidenced (SetupIntent success, signed debit
+mandate, card-on-file with off-session authorization). Distinct from
+**subscription** commitment but often co-created at checkout. Assurance tier:
+committed.
+
+## Pipeline Pursuit
+
+A Record layer artifact for an in-flight sales or procurement deal before a
+binding **Commercial Commitment** exists.
+
+Examples: Salesforce Opportunity, HubSpot deal, renewal pursuit on existing
+account.
+
+Carries `stage`, `forecast_category`, expected amount/date, and `lifecycle_state`
+(open, won, lost). Stage changes are **Evidence Source** (internal telemetry);
+they do not alone create Commercial Commitment. Promote to commitment only when
+a `binding_trigger` is satisfied (signed quote/LOI → `proposed`; executed
+contract/PO/subscription → `active`).
+
 ## Commercial Record
 
 A record in a billing, CRM, or commerce system that tracks payment methods,

model/ConceptualModel.md

@@ -30,7 +30,9 @@ collapsing into `user`, `group`, or `tenant`.
 - Commercial Record: billing, CRM, or commerce-system record linked to an actor
   or tenant (e.g., Stripe Customer, Salesforce Account).
 - Commercial Commitment: evidenced obligation binding commercial parties (contract,
-  subscription, payment mandate, regulated onboarding).
+  subscription, payment mandate, purchase order, regulated onboarding).
+- Pipeline Pursuit: in-flight CRM/procurement deal before binding commitment
+  (Opportunity, deal record); promotes on binding trigger only.
 - Profile: presentation or attribute surface.
 - Persona: contextual presentation of an actor.
 
@@ -43,6 +45,9 @@ collapsing into `user`, `group`, or `tenant`.
   interchange encoding.
 - Proxy Commercial Identifier: Registry Identifier with commercial-proxy
   authority (e.g., DUNS).
+- Payment Instrument Reference: tokenized payment-provider instrument reference
+  (e.g., Stripe pm_xxx); scoped identifier on Commercial Record — not Credential,
+  not CHD.
 - Scoped Identifier: identifier designed for limited correlation.
 - Credential: proof or control material.
 - Claim: statement made by a source or issuer.

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

terminology/TerminologyInventory.md

@@ -37,6 +37,13 @@ has incompatible meanings across source families.
 | vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
 | subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
 | stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. |
+| payment method / pm_xxx | Payment Instrument Reference | Stripe, Adyen | Tokenized provider reference; not Credential; not CHD in canon. |
+| payment mandate / setup intent | Payment Mandate (Commercial Commitment) | Stripe, SEPA | Authorization to charge; commitment_type payment_mandate. |
+| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
+| opportunity (crm) | Pipeline Pursuit | Salesforce, HubSpot | In-flight deal; not Commercial Commitment until binding trigger. |
+| forecast commit (salesforce) | Pipeline Pursuit metadata | Salesforce | Sales forecast category; not Commercial Commitment. |
+| closed won | Pipeline Pursuit lifecycle + optional commitment | CRM | Won stage alone does not auto-create active commitment. |
+| quote accepted / loi signed | Commercial Commitment (proposed) | CPQ, sales | Binding trigger with document evidence. |
 | crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. |
 | customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. |
 | commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. |