Add commercial identity research corpus and binding concepts

Record deep research on commercial identity coupling across theory, law,
regulation, and software (KYC, LEI, DUNS, eIDAS, CRM). Introduce Commercial
Commitment, Legal Person, and Beneficial Owner to the canon model and document
the fluid-to-bound identity gradient in the conceptual model.

DownstreamRecommendations.md

@@ -107,4 +107,17 @@ later explicit package is extracted.
 | DID / VC | Identifier, Credential, Claim | Trust relationship |
 | Entity resolution | Synonymity Assertion | — |
 | Stripe / CRM billing | Commercial Record, Commercial Relationship | Subscription state |
-| Auth0 / Stytch B2B | Organization, Customer role, Tenant, Membership | Account, Subscriber label |
+| Auth0 / Stytch B2B | Organization, Customer role, Tenant, Membership | Account, Subscriber label |
+| KYC / AML / LEI / DUNS | Commercial Record, Beneficial Owner, Registry Identifier | Assurance, Evidence |
+| Salesforce / CRM | Commercial Record, Contact as Natural Person | Account hierarchy |
+
+## Commercial Binding
+
+- Model fluid identity (trials, leads, pseudonyms) without Commercial Commitment until
+  counterparty reliance exists.
+- On subscription, contract, or KYC acceptance, create Commercial Commitment with
+  Evidence Source and lifecycle state.
+- Link registry identifiers (LEI, DUNS, UEI, company reg) to Organization/Legal Entity
+  via Synonymity Assertion when multiple registries describe one entity.
+- Separate CRM Account and Stripe Customer as Commercial Records; never merge with login Account.
+- Use qualified credentials (eIDAS seal, VC) as Evidence for Commercial Commitment where applicable.

OpenQuestions.md

@@ -159,6 +159,56 @@ Source notes use:
 
 No separate bibliography file added.
 
+## Commercial Identity Research (2026)
+
+Deep research recorded under `research/commercial-identity/`. Key finding:
+identity and commerce are coupled in practice through **commercial binding** —
+evidenced obligations that raise counterparty reliance and make identity less fluid.
+
+### Commercial Commitment placement
+
+**Status:** Tentatively resolved — first-class Relationship-layer concept.
+
+Contracts, subscriptions, payment mandates, and regulated onboarding acceptance
+map to **Commercial Commitment** attached to Commercial Relationship or
+Commercial Record. See `commercial-identity-synthesis.md`.
+
+**Remaining:** Whether pipeline stages (CRM Opportunity) are commitments or
+downstream-only.
+
+### Beneficial Owner modeling
+
+**Status:** Open.
+
+KYC sources require natural persons behind legal entity customers. Candidate:
+Beneficial Owner as Natural Person + Ownership/Representation with Evidence.
+
+**Decision needed:** Dedicated relationship type vs. Ownership subtype with
+`beneficial` role metadata.
+
+### Reputation as canon concept
+
+**Status:** Open — leaning toward Evidence Source aggregation.
+
+Credit scores (PAYDEX), performance history, and repeat-play trust may not need
+a separate Reputation entity if modeled as Evidence Source + Trust Relationship
+with temporal scope.
+
+### Registry identifier subtype
+
+**Status:** Open.
+
+LEI, DUNS, UEI, and company registration numbers share renewal, authority, and
+cross-registry linking needs. Candidate: authoritative **Registry Identifier**
+subtype with renewal Lifecycle State.
+
+### Payment credential boundary
+
+**Status:** Open (downstream-heavy).
+
+Whether payment methods on Commercial Record map to Credential in canon or remain
+PCI-scoped downstream artifacts only.
+
 ## New Questions From Corpus Review
 
 ### Cerbos derived roles vs. explicit relationships

canon/CanonicalGlossary.md

@@ -144,6 +144,24 @@ as separate relationships or specializations.
 
 An organization or other actor recognized by a legal system.
 
+## Legal Person
+
+A person recognized by law as holder of rights and duties. Includes **Natural
+Person** and juridical persons (**Organization** / **Legal Entity**).
+
+Use Legal Person when law, registries, or qualified trust services (eIDAS seals,
+LEI) treat the party as a liability-bearing subject. Use Natural Person or
+Organization when the distinction matters for modeling.
+
+## Beneficial Owner
+
+A natural person who ultimately owns or controls a legal entity customer in
+regulated commercial contexts (KYC/AML).
+
+Maps to **Natural Person** linked to **Organization** or **Legal Entity** via
+**Ownership Relationship** or **Representation Relationship**, with **Evidence
+Source** from CDD/EDD onboarding. Not a substitute for Organization actor.
+
 ## Customer
 
 A commercial role played by an actor (usually an Organization, sometimes a
@@ -168,6 +186,18 @@ commercial or subscription purpose within a stated scope.
 May reference a Commercial Record for billing state. Does not imply membership,
 authorization, or identity equivalence.
 
+## Commercial Commitment
+
+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.
+
+Commercial Commitment carries lifecycle state (proposed, active, breached,
+fulfilled, expired, revoked) and may attach to Commercial Relationship,
+Commercial Record, or Legal Entity/Organization actors.
+
 ## Commercial Record
 
 A record in a billing, CRM, or commerce system that tracks payment methods,

canon/DesignPrinciples.md

@@ -78,6 +78,13 @@ dimensions (NIST IAL, AAL, FAL). Do not collapse them into a single "trust
 level" on an account. Record assurance metadata on bindings, credentials, and
 federation relationships where sources provide it.
 
+## P15. Model Commercial Binding Explicitly
+
+When commercial activity creates reliance between parties, model the binding
+artifacts: Commercial Relationship, Commercial Record, Commercial Commitment,
+and supporting Evidence. Fluid identity is valid when stakes are low; do not
+force login or CRM identifiers to carry commercial liability by default.
+
 ## P14. Separate Commercial Records From Accounts
 
 Billing customers (Stripe), CRM accounts (Salesforce), and login accounts are

model/ConceptualModel.md

@@ -28,7 +28,9 @@ collapsing into `user`, `group`, or `tenant`.
 - Service Account: software-oriented account.
 - Identity Record: source-specific record about an actor or account.
 - Commercial Record: billing, CRM, or commerce-system record linked to an actor
-  or tenant (e.g., Stripe Customer).
+  or tenant (e.g., Stripe Customer, Salesforce Account).
+- Commercial Commitment: evidenced obligation binding commercial parties (contract,
+  subscription, payment mandate, regulated onboarding).
 - Profile: presentation or attribute surface.
 - Persona: contextual presentation of an actor.
 
@@ -75,7 +77,9 @@ Core relationship classes:
   scope.
 - Trust: actor, issuer, verifier, or system relies on another for a purpose.
 - Commercial: vendor actor provides services to customer actor; may reference a
-  Commercial Record for billing or subscription state.
+  Commercial Record and one or more Commercial Commitments.
+- Ownership (beneficial): natural person owns or controls organization customer
+  (KYC beneficial owner pattern).
 - Synonymity: records or identifiers are asserted to refer to the same target
   under stated evidence and scope.
 
@@ -201,6 +205,18 @@ revocation/supersession path via `Lifecycle State`.
 more `Tenant` scopes → `Representation Relationship` for authorized persons or
 agents.
 
+## Commercial Binding Gradient
+
+Identity representations vary in persistence based on commercial stake:
+
+- **Fluid**: no Commercial Commitment; personas and scoped identifiers may rotate
+  freely (low counterparty reliance).
+- **Bound**: Commercial Commitment + Evidence + often Commercial Record; identifiers
+  stabilize because counterparties bear risk (billing, contract, KYC, LEI).
+
+Commercial binding does not merge layers. It increases assurance requirements and
+lifecycle rigor on the records and relationships already in the model.
+
 ## Scenario Gaps
 
 No scenario requires glossary or principle changes that the current model
@@ -208,8 +224,7 @@ cannot satisfy. Remaining ambiguities are documented in `OpenQuestions.md`:
 
 - mandatory Synonymity Assertion field set;
 - Realm vs. Tenant promotion for Keycloak-heavy mappings;
-- Customer Account resolved: use Commercial Record + Commercial Relationship;
-  see `OpenQuestions.md`.
+- Beneficial Owner as dedicated relationship type vs. Ownership subtype.
 
 ## Invariants
 

research/CorpusIndex.md

@@ -54,6 +54,17 @@ The repository is focused on research and terminology. The corpus should collect
 - `b2b-saas-subscriber-tenancy.md`
 - `stripe-customer-billing.md`
 
+### commercial-identity
+
+- `commercial-identity-synthesis.md`
+- `commercial-trust-binding-theory.md`
+- `legal-person-agency-contract.md`
+- `lei-gleif-legal-entity-identifier.md`
+- `duns-commercial-credit-identity.md`
+- `kyc-aml-commercial-identity-binding.md`
+- `eidas-eudi-legal-person-wallet.md`
+- `salesforce-crm-commercial-record.md`
+
 ## Source Note Template
 
 Each source note should capture:

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

@@ -0,0 +1,133 @@
+# Commercial Identity Synthesis
+
+## Source Type
+
+identity-canon research synthesis connecting commercial theory, law, regulation,
+and software practice to the canonical model.
+
+## Domain
+
+Cross-cutting commercial identity — binding, trust, persistence, and layer separation.
+
+## Why This Source Matters
+
+This note captures the research prompt: **identity and commerce are tightly coupled
+in practice**. Conceptual or login-only identity can remain fluid when no commercial
+value or enforceable promises attach. **Commercial binding** increases an identity's
+relevance to other actors and creates foundations for trust, shared information, and
+durable relationships.
+
+## The Binding Gradient
+
+| Stage | Commercial stake | Identity behavior | Canon pattern |
+| --- | --- | --- | --- |
+| Anonymous browse | None | Fluid, discardable | Persona, ephemeral Identifier |
+| Free trial / lead | Low | Pseudonymous, reversible | Account + weak Commercial Record |
+| Paying subscriber | Medium | Stable tenant + billing ID | Organization + Tenant + Commercial Record |
+| KYC/AML customer | High | Verified, monitored, retained | Commercial Record + Evidence + BO linkage |
+| Regulated markets (LEI) | Very high | Renewed legal identity, ownership public | Legal Entity + LEI Identifier + Lifecycle |
+| Contractual enterprise | High | Agency, seals, signatures | Commercial Commitment + Representation |
+
+**Insight:** fluidity is not a bug — it is rational when commercial externalities are
+absent. Binding is what makes identity **economically and legally salient**.
+
+## Layer Model (Commercial + Identity)
+
+```text
+Actor Layer          Natural Person, Organization, Legal Entity
+Record Layer         Account (access), Commercial Record (billing/CRM/regulatory)
+Reference Layer      Identifiers (LEI, DUNS, UEI, VAT, stripe_customer_id)
+Relationship Layer   Commercial Relationship, Representation, Ownership, Trust
+Commitment Layer     Commercial Commitment (contract, subscription, payment mandate)
+Evidence Layer       KYC files, credit history, registry extracts, qualified credentials
+Projection Layer     Auth Subject, Auth Principal (unchanged — not commercial roots)
+```
+
+Commerce does not replace identity layers; it **selectively hardens** them when
+counterparties must rely, sue, invoice, or report.
+
+## How Binding Creates Trust
+
+From commercial theory and practice:
+
+1. **Attribution**: counterparties know **who** bears liability (legal person, BO, agent).
+2. **Commitment**: contracts, subscriptions, and payment authorizations create **costly exit**.
+3. **Evidence**: KYC, LEI, registry credentials, and credit files provide **verifiable history**.
+4. **Reputation**: PAYDEX, performance history, and repeat play increase **trust without re-verification**.
+5. **Enforcement**: law of agency and contract makes promises **actionable** beyond platform ToS.
+
+Trust Relationship in canon should often be **justified by** Commercial Relationship +
+Commercial Commitment + Evidence, not declared ad hoc.
+
+## Software Mirrors (Practical)
+
+| System | Commercial artifact | Identity separation lesson |
+| --- | --- | --- |
+| Stripe | Customer | Billing ≠ login |
+| Salesforce | Account / Contact | CRM ≠ User |
+| Auth0/Stytch | Organization / Member | Subscriber ≠ billing record |
+| KYC platforms | Customer profile + BO | Regulated counterparty ≠ session |
+| GLEIF | LEI | Legal entity ID for markets |
+| D&B | DUNS + PAYDEX | Credit identity + reputation |
+| eIDAS/EUDI | Legal person wallet | Qualified org credentials |
+
+## Canon Decisions From This Research
+
+### Rejected
+
+- **Customer Account** as canonical type (overloads layers).
+
+### Added / strengthened
+
+- **Commercial Record** — billing, CRM, regulatory counterparty records.
+- **Commercial Relationship** — vendor/customer commercial link.
+- **Commercial Commitment** — enforceable or costly promise binding parties (contract,
+  subscription, payment mandate, regulatory onboarding acceptance).
+- **Beneficial Owner linkage** — Natural Person to Organization for entity customers.
+
+### Unchanged roots
+
+- **Actor** remains participation root.
+- **Account** remains operational access record.
+- Login, authz, and social layers unchanged; commerce **binds** them when stakes require.
+
+## Fluid ↔ Bound Transitions
+
+Model as lifecycle events, not silent merges:
+
+- Lead → Account (CRM conversion): weak → medium evidence.
+- Trial → paid subscription: attach Commercial Commitment + payment Credential.
+- Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
+- Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.
+
+## Scenario Impact
+
+- **S04 (vendor/customer tenants)**: add Commercial Record per customer tenant, Commercial
+  Commitment for subscription/contract.
+- **S14 (pseudonymous profile)**: incompatible with active Commercial Commitment unless
+  explicitly scoped (e.g., marketplace escrow with privacy partition).
+- **S15 (legal entity + tenants)**: LEI/registry Identifier + Commercial Record + renewals.
+
+## Research Gaps
+
+- Payment Credential vs. authentication Credential boundary in PCI contexts.
+- Smart contracts and automated Commercial Commitment lifecycle.
+- Cross-border registry Synonymity for same legal entity (LEI ↔ DUNS ↔ company reg).
+- Reputation as first-class canon concept vs. Evidence Source aggregation.
+
+## Source Notes in This Stack
+
+- `commercial-trust-binding-theory.md`
+- `legal-person-agency-contract.md`
+- `lei-gleif-legal-entity-identifier.md`
+- `duns-commercial-credit-identity.md`
+- `kyc-aml-commercial-identity-binding.md`
+- `eidas-eudi-legal-person-wallet.md`
+- `salesforce-crm-commercial-record.md`
+- `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
+- `../commercial-subscription/stripe-customer-billing.md`
+
+## References
+
+See individual source notes. Primary external anchors: GLEIF/ISO 17442, FinCEN CIP,
+EU eIDAS, D&B DUNS, Salesforce Account model, Auth0/Stytch org tenancy, FATF digital identity.

research/commercial-identity/commercial-trust-binding-theory.md

@@ -0,0 +1,118 @@
+# Commercial Trust and Identity Binding Theory
+
+## Source Type
+
+Academic and industry synthesis. Transaction-cost economics, contract performance
+literature, digital trust research, and identity-canon conceptual framing.
+
+## Domain
+
+Commercial theory, trust formation, identity persistence, and the economic
+function of binding commitments.
+
+## Why This Source Matters
+
+Practitioners often treat login identity and billing identity as separate
+accidents of software architecture. Commercial theory suggests a deeper
+pattern: **commercially unbound identities stay fluid**; **commercially bound
+identities become durable points of coordination** for trust, information
+sharing, and enforceable promises.
+
+## Key Concepts
+
+- **Fluid identity**: participation with low exit cost and weak external reliance;
+  pseudonymous handles, trial accounts, anonymous browsing.
+- **Commercial binding**: attachment of economic or legal obligation to an
+  identity representation (payment authorization, contract, subscription, KYC
+  onboarding, credit exposure).
+- **Reputation capital**: value accumulated when past performance is observable
+  and attributable to a stable identity.
+- **Transaction costs**: search, bargaining, monitoring, and enforcement costs
+  that trust mechanisms reduce (Williamson, Coase tradition).
+- **Contract performance assurance**: market and legal mechanisms ensuring
+  parties keep promises (bonding, hostages, repeat play, legal enforcement).
+- **Transient trust**: short-lived trust between previously unknown parties
+  enabled by verified credentials and real-time assurance (EU digital wallet
+  discourse).
+- **Perpetual master data**: continuous re-validation of enterprise identity
+  attributes once commercial relationships depend on accuracy (KYC/KYB, LEI
+  renewal).
+- **Counterparty risk**: commercial exposure to wrong or misidentified party;
+  drives identity rigor.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| Binding | Attachment of enforceable or costly-to-break obligation. |
+| Commitment | Promise backed by legal, financial, or reputational stake. |
+| Trust | Willingness to rely on another party under uncertainty. |
+| Reputation | Observable history attributed to an identity. |
+| Fluid identity | Low-stakes, easily abandoned or rotated representation. |
+| Bound identity | Identity whose change imposes cost on self or counterparties. |
+| Assurance | Mechanism increasing confidence in performance or identity. |
+| Counterparty | Other party in a commercial transaction. |
+
+## Modeling Assumptions
+
+- Identity relevance scales with **stakes of reliance** by other parties.
+- Without commercial binding, actors optimize for **low friction and privacy**
+  (fluid personas, ephemeral identifiers).
+- Commercial activity introduces **attribution requirements** (who invoiced,
+  who signed, who is liable).
+- Trust between commercial actors rests on **identity stability + evidence +
+  enforceable commitments**, not on profile richness alone.
+- Digital systems separate layers (login, CRM, billing, KYC) but commercial
+  reality treats them as **one counterparty** when risk is integrated.
+- Reputation and legal liability create **path dependence**: past bindings make
+  future identity changes costly (account migration, LEI renewal, contract novation).
+
+## Identity-Canon Implications
+
+- Distinguish **fluid participation** (Actor/Persona/Account with no commercial
+  commitment) from **commercially bound participation** (Commercial Record +
+  Commercial Relationship + Commercial Commitment).
+- **Trust Relationship** in canon should often be **downstream of** Commercial
+  Relationship and evidenced commitments, not a substitute for them.
+- **Synonymity Assertion** strength should rise when commercial counterparty
+  risk requires deterministic matching (KYC, LEI, registry ID).
+- **Lifecycle State** on commercial artifacts gates access and trust (subscription
+  active, delinquent, KYC expired, LEI lapsed).
+- User insight formalized: conceptual identity without commercial binding may
+  remain intentionally fluid; binding increases **relevance to other commercial
+  actors** and justifies **stronger identifiers and promises**.
+
+## Terminology Conflicts
+
+- **Trust (social)** vs. **trust (commercial)**: following ≠ credit trust.
+- **Identity (conceptual)** vs. **identity (counterparty)**: philosophy vs. KYC record.
+- **Binding (technical)** vs. **binding (legal)**: OIDC binding ≠ contract.
+- **Reputation (brand)** vs. **reputation (performance history)**: marketing vs. credit.
+
+## Candidate Canonical Mappings
+
+| Theory concept | Candidate canonical concept |
+| --- | --- |
+| Fluid identity | Persona / Scoped Identifier without Commercial Commitment |
+| Commercial binding | Commercial Commitment on Commercial Relationship |
+| Reputation capital | Evidence Source history + Trust Relationship |
+| Counterparty identification | Commercial Record + Legal Entity + Identifiers |
+| Contractual promise | Commercial Commitment (contract subtype) |
+| Assurance mechanism | Assurance Level + Evidence Source |
+| Transient trust | Trust Relationship with short lifecycle + VC/qualified ID |
+| Perpetual MDM | Ongoing Evidence Source refresh on Commercial Record |
+
+## Open Questions
+
+- Should Commercial Commitment be a Relationship subclass or metadata on
+  Commercial Relationship?
+- How should fluid-to-bound transitions be modeled (trial → paid, anonymous → KYC)?
+- Does reputation warrant a canonical concept or remain Evidence Source aggregation?
+
+## References
+
+- Klein and Leffler (1981), role of market forces in contractual performance
+- Williamson, transaction cost economics (institutional trust)
+- FATF Guidance on Digital Identity (trust frameworks for financial identity)
+- Spherity/EUDI organizational wallet discourse on transient trust and perpetual MDM
+- identity-canon ResearchSeed (trust, synonymity, evidence)

research/commercial-identity/duns-commercial-credit-identity.md

@@ -0,0 +1,85 @@
+# DUNS and Commercial Credit Identity
+
+## Source Type
+
+Industry registry. Dun & Bradstreet Data Universal Numbering System (D-U-N-S).
+
+## Domain
+
+Commercial credit, vendor onboarding, procurement identity, and business verification.
+
+## Why This Source Matters
+
+DUNS predates LEI as a global commercial identifier for **business entities** in
+trade and credit. It ties identity to **creditworthiness and payment behavior**
+(PAYDEX), illustrating how commercial activity creates durable, high-stakes identity
+interest among counterparties.
+
+## Key Concepts
+
+- **DUNS number**: nine-digit proprietary identifier for a business location/entity.
+- **D&B database**: 300M+ business records; global trade and procurement usage.
+- **Business entity**: company or location receiving DUNS; not a natural person.
+- **PAYDEX score**: D&B payment performance score (credit behavior).
+- **Credit file**: aggregated commercial history attributed to DUNS.
+- **Government procurement**: historically required DUNS (US); migrated to SAM UEI.
+- **UEI (Unique Entity Identifier)**: US federal successor identifier in SAM.gov.
+- **ISO/IEC 6523 ICD 0060**: standard representation for DUNS in ISO identifiers.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| DUNS / D-U-N-S | D&B business identifier. |
+| Business entity | Company or site in D&B registry. |
+| PAYDEX | Payment performance score. |
+| Credit file | Commercial history record. |
+| UEI | US government unique entity ID (SAM.gov). |
+| Vendor onboarding | Procurement verification using DUNS/UEI. |
+| Headquarters vs. branch | Separate DUNS per distinct business location. |
+
+## Modeling Assumptions
+
+- **Commercial identity serves credit and procurement**, not authentication.
+- **Payment history feeds reputation** attributable to identifier.
+- **Multiple national ID schemes** (DUNS, UEI, LEI, VAT, company reg) coexist; linking
+  requires Synonymity Assertion or registry crosswalk.
+- **Identifier assignment is vendor-operated** (D&B), not self-asserted.
+- **Commercial counterparties rely on DUNS** for risk decisions beyond bare legal existence.
+
+## Identity-Canon Implications
+
+- DUNS maps to **Identifier** on **Commercial Record** / **Organization**.
+- PAYDEX and credit file map to **Evidence Source** influencing **Trust Relationship**
+  and counterparty risk.
+- UEI maps to **Identifier** (government authoritative) on Commercial Record.
+- Illustrates user thesis: once credit exposure exists, identity becomes **economically
+  binding** and **reputationally persistent**.
+- Link to LEI via Synonymity Assertion when same legal entity holds both.
+
+## Terminology Conflicts
+
+- **DUNS** vs. **LEI**: credit/procurement vs. financial regulatory identifier.
+- **Business entity (D&B)** vs. **Tenant**: vendor record ≠ SaaS isolation.
+- **Customer (credit)** vs. **Customer (role)**: credit customer vs. relationship role.
+
+## Candidate Canonical Mappings
+
+| D&B / procurement concept | Candidate canonical concept |
+| --- | --- |
+| DUNS number | Identifier |
+| D&B business record | Commercial Record |
+| PAYDEX | Evidence Source (credit performance) |
+| UEI | Identifier (government registry) |
+| Vendor onboarding check | Trust Relationship + Evidence Source |
+| Parent/branch linkage | Organization structure Relationship |
+
+## Open Questions
+
+- Should credit scores be canonical metadata or strictly downstream risk signals?
+
+## References
+
+- Dun & Bradstreet DUNS — https://www.dnb.com/duns-number.html
+- Wikipedia, Data Universal Numbering System — https://en.wikipedia.org/wiki/Data_Universal_Numbering_System
+- GSA Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update

research/commercial-identity/eidas-eudi-legal-person-wallet.md

@@ -0,0 +1,98 @@
+# eIDAS and EUDI Wallet for Legal Persons
+
+## Source Type
+
+Regulatory framework and industry analysis. EU eIDAS Regulation, eIDAS 2.0 / EUDI
+Wallet, European Business Wallet (organizational wallet) initiatives.
+
+## Domain
+
+EU digital identity, qualified trust services, legal person credentials, and
+cross-border commercial trust.
+
+## Why This Source Matters
+
+eIDAS bridges **legal identity** and **commercial trust** at EU scale: electronic
+signatures, seals, timestamps, and (via EUDI) wallets for natural and **legal
+persons** carrying verifiable credentials for B2B and B2G exchange.
+
+## Key Concepts
+
+- **eIDAS**: EU regulation for electronic identification and trust services.
+- **eID (electronic identification)**: national schemes with mutual recognition.
+- **Qualified trust services**: legally recognized signatures, seals, timestamps, etc.
+- **Electronic seal**: legal-entity counterpart to personal e-signature.
+- **EUDI Wallet**: European Digital Identity Wallet for citizens (eIDAS 2.0).
+- **Organizational / legal person wallet**: extension for companies (EUBW discourse).
+- **Verifiable credential (EU context)**: credentials in wallet (licenses, compliance certs).
+- **Transient trust**: real-time verified trust between unknown parties via credentials.
+- **KYB/KYS**: Know Your Business / Supplier via registry-sourced credentials.
+- **Delegation of rights**: organizational members present credentials on behalf of legal person.
+- **Authorization chains**: parent-subsidiary credential issuance hierarchies.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| eIDAS | EU trust framework regulation. |
+| Qualified signature/seal | Highest assurance trust service. |
+| Legal person | Company or organization under law. |
+| EUDI Wallet | EU digital identity wallet. |
+| Organizational wallet | Wallet for legal person credentials. |
+| Electronic seal | Entity-level signing mechanism. |
+| Trust service provider | TSP issuing qualified services. |
+| Verifiable credential | Attested claim in wallet. |
+
+## Modeling Assumptions
+
+- **Natural person and legal person wallets differ materially** — org wallets need
+  delegation, hierarchy, API integration, higher volume.
+- **Legal person acts through representatives** with scoped credentials (aligns with agency law).
+- **Qualified services carry legal equivalence** to paper in EU cross-border context.
+- **Registry-sourced credentials** (e.g., company register) anchor commercial identity to authority.
+- **Commercial binding increases** when seals/signatures and compliance credentials are used.
+- **Citizen wallet stack cannot be naively copied** for organizational use cases.
+
+## Identity-Canon Implications
+
+- Legal person wallet maps to **Organization/Legal Entity** + **Commercial Record** +
+  **Credential** (qualified seal) + **Claim** set.
+- Representative presenting org credential maps to **Representation Relationship**
+  with scoped **Delegation**.
+- Registry-issued credential maps to **Claim** with government **Evidence Source**.
+- Transient trust maps to **Trust Relationship** established at transaction time with
+  VC/qualified credential evidence.
+- Supports user thesis: commercial credentials make identity **relevant and durable**
+  to counterparties across borders.
+- Pairwise/pseudonymous identity insufficient for qualified seal; commercial binding
+  requires legal person resolution.
+
+## Terminology Conflicts
+
+- **Legal person (civil law)** vs. **Legal Entity (canon)**: legal person includes natural persons.
+- **Digital identity (eIDAS)** vs. **Identity Record**: assured ID vs. directory record.
+- **Trust service** vs. **Trust Relationship**: regulatory service vs. canon relationship.
+
+## Candidate Canonical Mappings
+
+| eIDAS/EUDI concept | Candidate canonical concept |
+| --- | --- |
+| Legal person | Organization / Legal Entity |
+| Organizational wallet | Commercial Record + Credential store (Scope) |
+| Electronic seal | Credential (entity signing) |
+| Qualified certificate | Credential + Assurance Level |
+| Member presenter | Natural Person + Representation |
+| Registry credential | Claim + authoritative Evidence Source |
+| KYB/KYS process | Commercial Relationship onboarding |
+| Authorization chain | Delegation + org hierarchy Relationships |
+
+## Open Questions
+
+- Should qualified electronic seal be Credential subtype tied to Legal Entity only?
+- How should EUDI organizational wallet Scope relate to Tenant vs. Commercial Record?
+
+## References
+
+- EU eIDAS Regulation — https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
+- EU EUDI Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
+- Spherity, EUDI Wallet for legal persons — https://www.spherity.com/post/the-european-busienss-wallet-eubw-and-legal-person-identity-redefining-trust-in-the-eu-s-digital

research/commercial-identity/kyc-aml-commercial-identity-binding.md

@@ -0,0 +1,100 @@
+# KYC AML and Commercial Identity Binding
+
+## Source Type
+
+Regulatory framework synthesis. USA PATRIOT Act CIP, FinCEN KYC/AML, FATF digital
+identity guidance.
+
+## Domain
+
+Financial regulation, customer identification, beneficial ownership, and ongoing
+commercial relationship monitoring.
+
+## Why This Source Matters
+
+KYC/AML is where governments **mandate** commercial identity binding: institutions
+must verify who they transact with, retain evidence, and monitor behavior. This is
+the strongest practical force turning fluid identities into **regulated,
+high-stakes counterparty records**.
+
+## Key Concepts
+
+- **KYC (Know Your Customer)**: policies ensuring institutions know customers and risks.
+- **AML (Anti-Money Laundering)**: broader program preventing illicit finance.
+- **CIP (Customer Identification Program)**: US mandate to verify identity before account opening.
+- **CDD (Customer Due Diligence)**: risk assessment of customer relationship.
+- **EDD (Enhanced Due Diligence)**: heightened review for high-risk customers.
+- **Beneficial owner (BO)**: natural persons owning/controlling legal entity customers
+  (historically 25% threshold; may be lowered for high risk).
+- **Ongoing monitoring**: transaction surveillance after onboarding.
+- **Record retention**: CIP records kept years after relationship ends.
+- **Sanctions / PEP screening**: compare identities against government lists.
+- **Digital identity (FATF)**: guidance on digital ID assurance for KYC.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| KYC | Know-your-customer compliance program. |
+| CIP | Customer identification at onboarding. |
+| Beneficial owner | Natural person behind legal entity customer. |
+| PEP | Politically exposed person (elevated risk). |
+| Due diligence | Risk-based identity and activity review. |
+| Ongoing monitoring | Continued scrutiny of customer activity. |
+| Risk profile | Customer risk classification. |
+| FinCEN | US Financial Crimes Enforcement Network. |
+
+## Modeling Assumptions
+
+- **Commercial relationship triggers identity rigor** proportional to risk.
+- **Legal entity customers require beneficial owner identification** — natural
+  persons bound to organization customers.
+- **Identity verification is not one-time**; monitoring continues across lifecycle.
+- **Evidence must be retained** even after account closure.
+- **False identity has regulatory and criminal consequences** — binding is external,
+  not user preference.
+- **Friction is accepted** where commercial stakes require it.
+
+## Identity-Canon Implications
+
+- KYC onboarding creates **Commercial Record** + **Commercial Commitment** (regulated
+  relationship) bound to **Natural Person** and/or **Organization/Legal Entity**.
+- **Beneficial owner** maps to **Natural Person** linked via **Ownership** or
+  **Representation** to Organization customer.
+- CIP evidence maps to **Evidence Source** with **Assurance Level**.
+- Ongoing monitoring produces **Evidence Source** events affecting **Lifecycle State**
+  and **Trust Relationship**.
+- Supports fluid-to-bound transition: anonymous lead → verified customer with retained proof.
+- **Account** (bank/login) is insufficient alone; KYC binds the **counterparty**.
+
+## Terminology Conflicts
+
+- **Customer (KYC)** vs. **Customer (Stripe)** vs. **Customer (role)**: regulated
+  counterparty vs. billing object vs. commercial role.
+- **CIP customer** vs. **Account holder**: verified party vs. access credential.
+- **Digital identity** vs. **login identity**: assurance-ranked ID vs. session user.
+
+## Candidate Canonical Mappings
+
+| KYC/AML concept | Candidate canonical concept |
+| --- | --- |
+| Verified customer | Commercial Record + Actor binding |
+| CIP evidence | Evidence Source |
+| Beneficial owner | Natural Person + Ownership Relationship |
+| Risk profile | Assurance Level + metadata on Commercial Relationship |
+| EDD review | Evidence Source (enhanced) |
+| Sanctions hit | Lifecycle State / Trust Relationship revocation |
+| Transaction alert | Evidence Source event |
+| Record retention | Lifecycle/archival policy on Commercial Record |
+
+## Open Questions
+
+- Should Beneficial Owner be a canonical relationship role or Ownership subtype?
+- How to model BOI registry volatility in lifecycle without canon becoming legal advice?
+
+## References
+
+- Thomson Reuters, Customer Identification Program overview — https://legal.thomsonreuters.com/blog/overview-customer-identification-program-cip/
+- Okta KYC definition — https://www.okta.com/identity-101/kyc/
+- FinCEN, USA PATRIOT Act Section 326 — https://www.fincen.gov/resources/statutes-regulations/usa-patriot-act
+- FATF Guidance on Digital Identity — https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-on-Digital-Identity.html

research/commercial-identity/legal-person-agency-contract.md

@@ -0,0 +1,111 @@
+# Legal Person, Agency, and Contract Binding
+
+## Source Type
+
+Legal doctrine synthesis. Common-law agency principles, contract privity, and
+juridical person concepts used in commercial law.
+
+## Domain
+
+Commercial law foundations for representation, liability, and binding promises
+between parties.
+
+## Why This Source Matters
+
+Commercial software models "accounts" and "organizations," but courts and
+regulators reason about **principals, agents, legal persons, and contractual
+obligations**. Agency law explains how organizations act through people and why
+commercial identity must bind **liability**, not just login state.
+
+## Key Concepts
+
+- **Legal person**: entity recognized by law as holder of rights and duties;
+  includes natural persons and juridical persons (corporations, LLCs, etc.).
+- **Juridical person**: organization recognized as legal person distinct from
+  members (corporation, association).
+- **Principal**: party on whose behalf an agent acts.
+- **Agent**: party authorized to act for principal and bind principal within scope.
+- **Fiduciary duty**: agent's duty of loyalty and care to principal.
+- **Actual authority**: express or implied permission granted to agent.
+- **Apparent authority**: third party reasonably believes agent has authority
+  based on principal's conduct.
+- **Agency by contract**: principal-agent relationship created by agreement
+  (employment, power of attorney, brokerage).
+- **Contract**: agreement creating enforceable obligations; requires parties with
+  capacity.
+- **Privity**: doctrine limiting contract rights/obligations to parties to the
+  contract (with modern statutory exceptions).
+- **Representation**: agent acts **for** principal; principal may be bound by
+  authorized acts.
+- **Termination**: agency ends by agreement, operation of law (death, bankruptcy),
+  or breach.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| Principal | Party represented by agent. |
+| Agent | Party acting on principal's behalf. |
+| Legal person | Rights-bearing entity under law. |
+| Juridical person | Non-human legal person (company). |
+| Fiduciary | Trust-based duty relationship. |
+| Power of attorney | Written agency authorization. |
+| Binding | Creating legal obligation on a party. |
+| Capacity | Legal ability to enter contracts. |
+| Apparent authority | Authority as seen by third parties. |
+
+## Modeling Assumptions
+
+- **Organizations act only through agents** (officers, employees, representatives).
+- **Commercial binding requires identifiable parties** with legal capacity.
+- **Representation is contractual or statutory**, not merely technical (API token).
+- **Principal liability** may attach to unauthorized acts if apparent authority exists.
+- **Agency terminates**; commercial systems must model lifecycle and revocation.
+- **Natural person ≠ company** even when sole proprietor; legal structure matters
+  for liability and contract.
+
+## Identity-Canon Implications
+
+- **Organization** collective actor maps to juridical person when legally recognized.
+- **Natural Person** maps to natural-person legal person.
+- **Representation Relationship** in canon aligns with agency (acts for).
+- **Delegation Relationship** is narrower grant of authority; agency may be broader.
+- **Commercial Commitment** (contracts, PO acceptance) binds **Legal Entity** or
+  **Organization** actors through **Representation** chains.
+- Login **Account** does not create agency; employment or explicit authorization does.
+- **Apparent authority** explains why enterprises must govern service accounts and
+  admin roles carefully (S05, S10, S11).
+
+## Terminology Conflicts
+
+- **Agent (legal)** vs. **Artificial Agent (canon)**: lawyer's agent ≠ AI agent;
+  overlap when AI acts under delegated authority.
+- **Principal (legal)** vs. **Authorization Principal**: legal principal vs. Cedar principal.
+- **Legal person** vs. **Legal Entity** in canon: legal person includes natural persons.
+- **Account holder** vs. **contracting party**: bank account ≠ signatory authority.
+
+## Candidate Canonical Mappings
+
+| Legal concept | Candidate canonical concept |
+| --- | --- |
+| Natural person (legal) | Natural Person |
+| Juridical person | Organization / Legal Entity |
+| Principal | Organization or Natural Person (represented party) |
+| Agent (human) | Natural Person + Representation Relationship |
+| Agent (org acting) | Organization + Representation Relationship |
+| Power of attorney | Delegation Relationship + Credential |
+| Contract | Commercial Commitment (contract) |
+| Apparent authority | Trust Relationship risk + Administration governance |
+| Agency termination | Lifecycle State on Representation/Delegation |
+
+## Open Questions
+
+- Should canon add **Legal Person** as umbrella for Natural Person + juridical
+  Organization/Legal Entity?
+- How should apparent authority risks be represented for service accounts?
+
+## References
+
+- Stimmel Law, Agency – The Basic Law — https://www.stimmel-law.com/en/articles/agency-basic-law
+- Contract privity doctrine (common law overview)
+- Harvard Law School Forum, FinCEN beneficial ownership and corporate persons

research/commercial-identity/lei-gleif-legal-entity-identifier.md

@@ -0,0 +1,90 @@
+# LEI and GLEIF Legal Entity Identifier
+
+## Source Type
+
+Standard and registry. ISO 17442 Legal Entity Identifier; GLEIF global LEI index.
+
+## Domain
+
+Regulated financial markets, legal entity identification, and ownership transparency.
+
+## Why This Source Matters
+
+LEI is the post-2008-crisis global standard for identifying **legal entities** in
+financial transactions. It encodes **who** and **who owns whom**, making it a
+canonical example of commercially binding identity with regulatory renewal
+requirements.
+
+## Key Concepts
+
+- **LEI**: 20-character ISO 17442 identifier for a legal entity.
+- **Legal entity (LEI scope)**: organization participating in financial transactions;
+  individuals cannot obtain LEI.
+- **GLEIF**: Global Legal Entity Identifier Foundation; oversees LOUs and data quality.
+- **LOU (Local Operating Unit)**: issuer/registrar for LEIs in a jurisdiction.
+- **Level 1 data**: business card data — legal name, address, jurisdiction.
+- **Level 2 data**: ownership — direct and ultimate parent relationships.
+- **Renewal**: LEI valid one year; annual renewal required for continued use.
+- **Regulatory mandate**: 45+ jurisdictions require LEI for certain financial reporting.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| LEI | Legal Entity Identifier code. |
+| Legal entity | Juridical person in financial markets. |
+| Level 1 | Entity reference data. |
+| Level 2 | Parent/ownership reference data. |
+| GLEIF | Global LEI system operator. |
+| LOU | Local issuing organization. |
+| Renewal | Annual reaffirmation of LEI validity. |
+| Regulator reporting | MiFIR, derivatives reporting, etc. |
+
+## Modeling Assumptions
+
+- **LEI identifies legal entities only**, not natural persons or login accounts.
+- **Ownership is first-class** in LEI Level 2 (parent chains).
+- **Identity persistence is maintained by renewal**, not immutability of business facts.
+- **Public global directory** enables counterparty verification.
+- **LEI does not prove good behavior**; it proves identifiable legal presence.
+- **One LEI per legal entity** for global financial identification.
+
+## Identity-Canon Implications
+
+- LEI maps to **Identifier** for **Legal Entity** / **Organization** actors.
+- Level 2 parent data maps to **Ownership** or structural Organization relationships.
+- LEI record maps to **Commercial Record** or authoritative **Identity Record**
+  with registry **Evidence Source**.
+- Renewal maps to **Lifecycle State** on Identifier/Commercial Record.
+- LEI exemplifies **commercial binding**: regulatory participation requires stable,
+  renewed legal identity.
+- Distinct from DUNS (credit/commerce) and from OIDC sub (authentication).
+
+## Terminology Conflicts
+
+- **Legal entity (LEI)** vs. **Legal Entity (canon)**: aligned when jurisdictionally recognized.
+- **Legal entity** vs. **Organization**: not every organization has LEI; LEI subset is regulated finance participants.
+- **LEI** vs. **company registration number**: national registry ID vs. global LEI.
+
+## Candidate Canonical Mappings
+
+| LEI concept | Candidate canonical concept |
+| --- | --- |
+| LEI code | Identifier (authoritative, global) |
+| Legal entity | Legal Entity / Organization |
+| Level 1 data | Commercial Record / registry Profile |
+| Level 2 parent | Ownership Relationship |
+| GLEIF registry | Evidence Source (authoritative) |
+| Annual renewal | Lifecycle State maintenance |
+| LOU issuance | Issuer Scope + Trust Relationship |
+
+## Open Questions
+
+- Should authoritative registry identifiers (LEI, company reg number) be a distinct
+  Identifier subtype with renewal semantics?
+
+## References
+
+- ISO 17442 — https://www.iso.org/standard/78829.html
+- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
+- Wikipedia, Legal Entity Identifier — https://en.wikipedia.org/wiki/Legal_Entity_Identifier

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

@@ -0,0 +1,89 @@
+# Salesforce CRM Commercial Record Model
+
+## Source Type
+
+Product data model reference. Salesforce Account, Contact, Lead, and B2B relationship patterns.
+
+## Domain
+
+CRM, sales operations, commercial customer records, and B2B account hierarchies.
+
+## Why This Source Matters
+
+Salesforce **Account** is the archetypal **commercial record** in enterprise software:
+a company or household you sell to, distinct from **Contact** (people) and **User**
+(login). It operationalizes commercial identity separate from authentication.
+
+## Key Concepts
+
+- **Account**: company, household, or partner organization in CRM; core commercial record.
+- **Contact**: person associated with accounts; human relationship endpoint.
+- **Lead**: unqualified prospect before conversion to Account/Contact.
+- **Opportunity**: potential revenue deal tied to Account.
+- **Account hierarchy**: parent-child account relationships (global HQ → subsidiaries).
+- **Account-Contact Relationship**: many-to-many person-to-account roles (ACR).
+- **Person Account**: B2C pattern merging person and account for individual consumers.
+- **Partner / Customer / Competitor**: account type labels for commercial role hints.
+- **User (Salesforce)**: internal login for CRM operators, not customer identity.
+
+## Relevant Terminology
+
+| Term | Source meaning |
+| --- | --- |
+| Account | CRM commercial entity record. |
+| Contact | Person linked to accounts. |
+| Lead | Pre-qualification prospect. |
+| ACR | Account-Contact Relationship with roles. |
+| Account hierarchy | Parent/child commercial structure. |
+| Person Account | B2C combined person+account pattern. |
+| Customer account (informal) | Often means CRM Account object. |
+
+## Modeling Assumptions
+
+- **Commercial party (Account) ≠ login User**; sales data outlives individual logins.
+- **Multiple contacts** represent people acting for commercial account (agency in practice).
+- **Hierarchy models corporate structure** for roll-up revenue and ownership context.
+- **Lead → Account conversion** is fluid-to-bound transition in commercial funnel.
+- **Person Account** blurs person/account boundary for B2C — convenient but risky for canon purity.
+- **Account type** hints customer/vendor/partner but is not authorization.
+
+## Identity-Canon Implications
+
+- Salesforce **Account** maps to **Commercial Record** linked to **Organization**
+  (B2B) or **Natural Person** (person account).
+- **Contact** maps to **Natural Person** + **Affiliation** or **Representation** to Organization.
+- **ACR** maps to **Membership** or **Representation** with role metadata.
+- **Account hierarchy** maps to Organization parent/child structural relationships.
+- **Lead** maps to provisional Identity/Commercial prospect with weak evidence until conversion.
+- **User** maps to internal **Account** (employee), not customer.
+- Validates Commercial Record concept from Customer Account resolution work.
+
+## Terminology Conflicts
+
+- **Account (CRM)** vs. **Account (login)**: Salesforce naming collision.
+- **Customer account** language vs. **Account object**: product uses Account for all.
+- **Person Account** vs. **P2 separation**: B2C shortcut vs. canon layers.
+
+## Candidate Canonical Mappings
+
+| Salesforce concept | Candidate canonical concept |
+| --- | --- |
+| Account (B2B) | Commercial Record + Organization |
+| Contact | Natural Person |
+| Account-Contact Relationship | Affiliation / Representation |
+| Account hierarchy | Organization structure Relationship |
+| Lead | Prospective Commercial Record (weak) |
+| Opportunity | Commercial Commitment (pipeline stage) |
+| 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?
+
+## References
+
+- Salesforce Account object reference — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_account.htm
+- Shellblack, Leads vs Account and Contacts — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
+- SalesforceBen, Account best practices — https://www.salesforceben.com/best-practices-salesforce-account-object/

terminology/TerminologyInventory.md

@@ -41,6 +41,17 @@ has incompatible meanings across source families.
 | 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. |
 | commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. |
+| commercial commitment | Commercial Commitment | contracts, subscriptions, KYC | Binding obligation raising identity stakes. |
+| beneficial owner | Beneficial Owner | KYC/AML, FinCEN | Natural person controlling legal entity customer. |
+| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
+| lei | Identifier (registry) | GLEIF, ISO 17442 | Legal entity identifier for financial markets. |
+| duns | Identifier (registry) | D&B | Commercial/credit identifier. |
+| uei | Identifier (registry) | SAM.gov | US federal entity identifier. |
+| paydex | Evidence Source | D&B | Credit/payment performance history. |
+| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. |
+| crm account | Commercial Record | Salesforce | Company/household commercial record. |
+| fluid identity | Persona / weak binding | theory | Low commercial stake; intentional mutability. |
+| bound identity | Commercial Commitment present | theory | High counterparty reliance; stable identifiers. |
 | tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. |
 | realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. |
 | scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. |
@@ -113,6 +124,7 @@ Terms above are grounded in backfilled notes under:
 - `research/verifiable-claims/` (3 notes)
 - `research/entity-resolution-privacy/` (3 notes)
 - `research/commercial-subscription/` (2 notes)
+- `research/commercial-identity/` (8 notes)
 
 ## Remaining Backfill Needs