diff --git a/DownstreamRecommendations.md b/DownstreamRecommendations.md index cdf9821..bef82fe 100644 --- a/DownstreamRecommendations.md +++ b/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. \ No newline at end of file +- 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. \ No newline at end of file diff --git a/OpenQuestions.md b/OpenQuestions.md index 5edd20f..76fb4f1 100644 --- a/OpenQuestions.md +++ b/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 diff --git a/canon/CanonicalGlossary.md b/canon/CanonicalGlossary.md index fa2be85..2f26193 100644 --- a/canon/CanonicalGlossary.md +++ b/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, diff --git a/model/ConceptualModel.md b/model/ConceptualModel.md index 6f98bb8..28751d1 100644 --- a/model/ConceptualModel.md +++ b/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. diff --git a/research/CorpusIndex.md b/research/CorpusIndex.md index bd0b9c2..71cc0b1 100644 --- a/research/CorpusIndex.md +++ b/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 diff --git a/research/commercial-identity/commercial-identity-synthesis.md b/research/commercial-identity/commercial-identity-synthesis.md index 5b11d09..fc4ac22 100644 --- a/research/commercial-identity/commercial-identity-synthesis.md +++ b/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` diff --git a/research/commercial-identity/crm-pipeline-commitment-threshold.md b/research/commercial-identity/crm-pipeline-commitment-threshold.md new file mode 100644 index 0000000..1b0498c --- /dev/null +++ b/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` \ No newline at end of file diff --git a/research/commercial-identity/payment-credential-pci-boundary.md b/research/commercial-identity/payment-credential-pci-boundary.md new file mode 100644 index 0000000..3dc2ed2 --- /dev/null +++ b/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` \ No newline at end of file diff --git a/research/commercial-identity/salesforce-crm-commercial-record.md b/research/commercial-identity/salesforce-crm-commercial-record.md index 10c3323..5334b8b 100644 --- a/research/commercial-identity/salesforce-crm-commercial-record.md +++ b/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 diff --git a/research/commercial-subscription/stripe-customer-billing.md b/research/commercial-subscription/stripe-customer-billing.md index df3cf5e..fb37591 100644 --- a/research/commercial-subscription/stripe-customer-billing.md +++ b/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 diff --git a/terminology/TerminologyInventory.md b/terminology/TerminologyInventory.md index 19aae66..0275a8b 100644 --- a/terminology/TerminologyInventory.md +++ b/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. |