diff --git a/DownstreamRecommendations.md b/DownstreamRecommendations.md
index 8e6713c..4e7c241 100644
--- a/DownstreamRecommendations.md
+++ b/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 |
\ No newline at end of file
+| 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.
\ No newline at end of file
diff --git a/OpenQuestions.md b/OpenQuestions.md
index 1631823..a6d81e0 100644
--- a/OpenQuestions.md
+++ b/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
diff --git a/canon/CanonicalGlossary.md b/canon/CanonicalGlossary.md
index 082be30..abe9208 100644
--- a/canon/CanonicalGlossary.md
+++ b/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,
diff --git a/canon/DesignPrinciples.md b/canon/DesignPrinciples.md
index 097491a..5164f1c 100644
--- a/canon/DesignPrinciples.md
+++ b/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
diff --git a/model/ConceptualModel.md b/model/ConceptualModel.md
index ca1e82f..0555a39 100644
--- a/model/ConceptualModel.md
+++ b/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
 
diff --git a/research/CorpusIndex.md b/research/CorpusIndex.md
index 318c8b0..c646717 100644
--- a/research/CorpusIndex.md
+++ b/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:
diff --git a/research/commercial-identity/commercial-identity-synthesis.md b/research/commercial-identity/commercial-identity-synthesis.md
new file mode 100644
index 0000000..8f6cf1a
--- /dev/null
+++ b/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.
\ No newline at end of file
diff --git a/research/commercial-identity/commercial-trust-binding-theory.md b/research/commercial-identity/commercial-trust-binding-theory.md
new file mode 100644
index 0000000..d8636dc
--- /dev/null
+++ b/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)
\ No newline at end of file
diff --git a/research/commercial-identity/duns-commercial-credit-identity.md b/research/commercial-identity/duns-commercial-credit-identity.md
new file mode 100644
index 0000000..efffcf1
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/research/commercial-identity/eidas-eudi-legal-person-wallet.md b/research/commercial-identity/eidas-eudi-legal-person-wallet.md
new file mode 100644
index 0000000..ec02760
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/research/commercial-identity/kyc-aml-commercial-identity-binding.md b/research/commercial-identity/kyc-aml-commercial-identity-binding.md
new file mode 100644
index 0000000..a4f4b15
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/research/commercial-identity/legal-person-agency-contract.md b/research/commercial-identity/legal-person-agency-contract.md
new file mode 100644
index 0000000..8994564
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/research/commercial-identity/lei-gleif-legal-entity-identifier.md b/research/commercial-identity/lei-gleif-legal-entity-identifier.md
new file mode 100644
index 0000000..1fa91f6
--- /dev/null
+++ b/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
\ 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
new file mode 100644
index 0000000..10c3323
--- /dev/null
+++ b/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/
\ No newline at end of file
diff --git a/terminology/TerminologyInventory.md b/terminology/TerminologyInventory.md
index 262fb2e..ecb6693 100644
--- a/terminology/TerminologyInventory.md
+++ b/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