From 3ccf841095e83fb4859396da06803d82afbf7a8a Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 21 Jun 2026 20:35:36 +0200 Subject: [PATCH] Resolve Customer Account question; add commercial subscription research Record B2B SaaS subscriber tenancy and Stripe billing source notes. Resolve the Customer Account open question: reject it as canonical, add Commercial Record and Commercial Relationship to the Record and relationship layers, and document Subscriber as a convenience term only. --- DownstreamRecommendations.md | 17 ++- OpenQuestions.md | 34 ++++-- canon/CanonicalGlossary.md | 48 ++++++++- canon/DesignPrinciples.md | 7 ++ model/ConceptualModel.md | 14 ++- research/CorpusIndex.md | 5 + .../b2b-saas-subscriber-tenancy.md | 102 ++++++++++++++++++ .../stripe-customer-billing.md | 102 ++++++++++++++++++ scenarios/ScenarioTests.md | 5 +- terminology/TerminologyConflictMap.md | 26 ++++- terminology/TerminologyInventory.md | 11 +- 11 files changed, 345 insertions(+), 26 deletions(-) create mode 100644 research/commercial-subscription/b2b-saas-subscriber-tenancy.md create mode 100644 research/commercial-subscription/stripe-customer-billing.md diff --git a/DownstreamRecommendations.md b/DownstreamRecommendations.md index 6133ee0..8e6713c 100644 --- a/DownstreamRecommendations.md +++ b/DownstreamRecommendations.md @@ -15,9 +15,14 @@ later explicit package is extracted. - Separate Natural Person, Account, Profile, Credential, and Principal in user-management schemas. Corpus confirms SCIM/LDAP use "user" for records, Keycloak/ZITADEL for accounts. -- Model Tenant as Scope; relate explicitly to Organization, Customer, Vendor, - and Realm. ZITADEL org-as-tenant and Keycloak realm-as-namespace are common - mapping patterns. +- Model Tenant as Scope; relate explicitly to Organization, Customer role, Vendor + role, Commercial Relationship, and Realm. ZITADEL org-as-tenant and Keycloak + realm-as-namespace are common mapping patterns. +- Store Stripe Customer / CRM Account as Commercial Record; link to Tenant and + Organization via Identifier binding. Do not create a `customer_account` table + that merges billing and login semantics. +- Map Auth0/Stytch "subscriber" to Organization + Customer role + Tenant; treat + Subscriber as convenience label only. - Store Synonymity Assertions with relation type, strength, scope, evidence, source system, lifecycle state, and privacy classification. Never default to destructive merge for duplicate detection. @@ -86,6 +91,8 @@ later explicit package is extracted. - Do not use MDM golden-record merge as default linking behavior. - Do not collapse Realm, Tenant, and Organization into one table without relationship modeling. +- Do not introduce `CustomerAccount` as a canonical type; use Commercial Record + for billing and Organization + Customer role for subscribing parties. ## Suggested Adapter Inventory @@ -98,4 +105,6 @@ later explicit package is extracted. | Cedar / Cerbos | Principal, Resource, Action, Context | Role, derived ownership | | ActivityPub / FOAF | Actor, Profile, Following | — | | DID / VC | Identifier, Credential, Claim | Trust relationship | -| Entity resolution | Synonymity Assertion | — | \ No newline at end of file +| 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 diff --git a/OpenQuestions.md b/OpenQuestions.md index d84fed9..1631823 100644 --- a/OpenQuestions.md +++ b/OpenQuestions.md @@ -20,15 +20,35 @@ explicit Organization + Tenant + Realm mapping in downstream adapters. ### Customer Account as canonical concept -**Status:** Open — leaning toward Organization + Customer role. +**Status:** Resolved — do not add Customer Account; add Commercial Record instead. -ZITADEL and Keycloak model customer-like boundaries as Organization with tenant -semantics, not a separate account type. No corpus source defines Customer -Account as distinct from Organization actor + Customer relationship role + -Tenant scope. +**Decision:** Customer Account is not a canonical concept. The term overloads +login Account, billing customer (Stripe), CRM account (Salesforce), and B2B +subscriber organization (Auth0/Stytch). -**Decision needed:** Whether billing/commercial account records warrant a -downstream-only model or a canonical Customer Account specialization. +**Canonical pattern:** + +| Source label | Canonical mapping | +| --- | --- | +| B2B subscriber / customer org (Auth0, Stytch, ZITADEL) | Organization actor + Customer Relationship role + Tenant Scope | +| Login user / member | Account + Membership Relationship | +| Stripe Customer / CRM Account | Commercial Record (Record layer) | +| Individual subscriber (no company) | Natural Person + Tenant Scope + Commercial Record | + +**New concepts added (not participation roots):** + +- **Commercial Record** — Record layer entity for billing/commerce system records. +- **Commercial Relationship** — typed relationship linking vendor and customer + actors, optionally referencing a Commercial Record. + +**Convenience term only:** Subscriber (map like User — resolve before use). + +**Citations:** + +- `research/commercial-subscription/b2b-saas-subscriber-tenancy.md` +- `research/commercial-subscription/stripe-customer-billing.md` +- `research/identity-provisioning/keycloak-organizations.md` +- `research/identity-provisioning/zitadel-organizations-projects.md` ### Team modeling diff --git a/canon/CanonicalGlossary.md b/canon/CanonicalGlossary.md index cff13c5..082be30 100644 --- a/canon/CanonicalGlossary.md +++ b/canon/CanonicalGlossary.md @@ -146,15 +146,39 @@ An organization or other actor recognized by a legal system. ## Customer -An actor in a commercial or service-consumption relationship. +A commercial role played by an actor (usually an Organization, sometimes a +Natural Person for individual subscriptions) that consumes services from a +vendor. -Customer is a relationship role, not automatically a tenant or organization. +Customer is a relationship role, not a record type and not interchangeable with +Tenant, Organization, Account, or Commercial Record. ## Vendor -An actor in a service-provider relationship. +A commercial role played by an actor (usually an Organization) that provides +services to customer actors. -Vendor is a relationship role, not automatically a tenant or organization. +Vendor is a relationship role, not a tenant, realm, or organization synonym. + +## Commercial Relationship + +A typed relationship connecting a vendor actor to a customer actor for a +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 Record + +A record in a billing, CRM, or commerce system that tracks payment methods, +subscriptions, invoices, contracts, or commercial contact details for an actor +or tenant. + +Examples: Stripe Customer, Salesforce Account, subscription billing profile. + +Commercial Record is in the Record layer. It is not an Account (login), not an +Organization actor, and not a Customer Account. Link it to Actor, Tenant, or +Scope via Identifier binding or Commercial Relationship. ## Community @@ -292,3 +316,19 @@ pseudonymization with separately stored re-identification keys. `User` may be used in prose when quoting or mapping external systems, but it should not be a canonical root concept. Resolve it to a specific canonical concept before using it in model definitions. + +## Non-Canonical Convenience Term: Subscriber + +`Subscriber` (common in Auth0 B2B SaaS documentation) usually means the +organization or party holding a subscription and tenant. Resolve to Organization ++ Customer Relationship role + Tenant Scope, or to Natural Person + Tenant for +individual subscriptions. Do not model as Customer Account or Account. + +## Non-Canonical Convenience Term: Customer Account + +Do not use `Customer Account` as a canonical term. Resolve by layer: + +- login/access → Account; +- subscribing company → Organization + Customer Relationship role; +- billing/CRM record → Commercial Record; +- isolation boundary → Tenant. diff --git a/canon/DesignPrinciples.md b/canon/DesignPrinciples.md index b1c66cc..097491a 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. +## P14. Separate Commercial Records From Accounts + +Billing customers (Stripe), CRM accounts (Salesforce), and login accounts are +different layers. Model billing and commerce artifacts as Commercial Records +linked to actors and tenants through Commercial Relationships — not as Customer +Accounts and not by overloading Account. + ## P13. Prefer Non-Destructive Linking Entity resolution, federation account linking, and semantic web equivalence diff --git a/model/ConceptualModel.md b/model/ConceptualModel.md index 5c78ada..ca1e82f 100644 --- a/model/ConceptualModel.md +++ b/model/ConceptualModel.md @@ -27,6 +27,8 @@ collapsing into `user`, `group`, or `tenant`. - Account: operational access record in a scope. - 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). - Profile: presentation or attribute surface. - Persona: contextual presentation of an actor. @@ -72,6 +74,8 @@ Core relationship classes: - Administration: actor manages records, relationships, or configuration in a 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. - Synonymity: records or identifiers are asserted to refer to the same target under stated evidence and scope. @@ -127,9 +131,10 @@ to org units → `Legal Entity` as specialization or relationship when evidenced ### S04 — Vendor Tenant Serving Customer Tenants -`Organization`(vendor) + `Organization`(customer) → `Vendor`/`Customer` -relationship roles → separate `Tenant` scopes → `Trust Relationship` for -federation → `Administration Relationship` for delegated support. +`Organization`(vendor) + `Organization`(customer) → `Commercial Relationship` +(vendor/customer roles) → separate `Tenant` scopes → optional `Commercial Record` +per customer tenant (billing) → `Trust Relationship` for federation → +`Administration Relationship` for delegated support. ### S05 — Customer Organization With Delegated Administrators @@ -203,7 +208,8 @@ cannot satisfy. Remaining ambiguities are documented in `OpenQuestions.md`: - mandatory Synonymity Assertion field set; - Realm vs. Tenant promotion for Keycloak-heavy mappings; -- Customer Account as separate concept vs. Organization + Customer role. +- Customer Account resolved: use Commercial Record + Commercial Relationship; + see `OpenQuestions.md`. ## Invariants diff --git a/research/CorpusIndex.md b/research/CorpusIndex.md index c5b063e..318c8b0 100644 --- a/research/CorpusIndex.md +++ b/research/CorpusIndex.md @@ -49,6 +49,11 @@ The repository is focused on research and terminology. The corpus should collect - `synonymity-assertions.md` - `gdpr-pseudonymization.md` +### commercial-subscription + +- `b2b-saas-subscriber-tenancy.md` +- `stripe-customer-billing.md` + ## Source Note Template Each source note should capture: diff --git a/research/commercial-subscription/b2b-saas-subscriber-tenancy.md b/research/commercial-subscription/b2b-saas-subscriber-tenancy.md new file mode 100644 index 0000000..2cbafaa --- /dev/null +++ b/research/commercial-subscription/b2b-saas-subscriber-tenancy.md @@ -0,0 +1,102 @@ +# B2B SaaS Subscriber and Organization Tenancy + +## Source Type + +Product documentation and industry practice synthesis. Auth0 Organizations and +B2B SaaS multi-tenancy guidance; Stytch B2B Auth School org-tenancy model. + +## Domain + +B2B SaaS identity, organization tenancy, subscriber administration, and +vendor/customer delineation in IAM products. + +## Why This Source Matters + +IAM vendors explicitly separate the subscribing party (customer/subscriber) from +login accounts and from billing records. This source clarifies why "customer +account" overloads identity, commercial, and access semantics. + +## Key Concepts + +- **Subscriber**: Auth0-preferred term for the immediate B2B customer — the + party that holds a provisioned tenant and subscription. +- **Vendor**: provider of the B2B SaaS application (platform operator). +- **Organization tenancy**: architecture where organizations are first-class + entities; members are scoped to their organization. +- **Member**: end user with membership in an organization (Stytch); distinct + from platform-wide user identity. +- **Tenant / tenancy holder**: operational partition occupied by a subscriber. +- **Org discovery**: determining which organization a user authenticates into. +- **Membership control**: granting/revoking which users may access a subscriber's + tenant. +- **Identity isolation**: per-subscriber credential and IdP configuration vs. + platform-wide user population. +- **B2B2C / B2B2B variants**: additional "customer" and "consumer" layers below + the subscribing organization. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Subscriber | B2B customer occupying a tenant; Auth0 avoids "customer" label. | +| Vendor | SaaS platform provider. | +| Organization | First-class customer entity; "the organization is the customer" (Stytch). | +| Member | Employee or invited user within an organization. | +| Tenant | Isolation boundary for subscriber data, branding, and config. | +| Customer (informal) | Often used interchangeably with subscriber or organization. | +| User | Login identity; may belong to multiple organizations. | +| Consumer | End user in B2B2C scenarios below the subscriber org. | + +## Modeling Assumptions + +- **The subscribing company is modeled as an organization**, not as a user + account or billing record. +- **One human can be a member of multiple subscriber organizations** (contractors, + agencies). +- **Platform stores users globally**; membership scopes them to subscriber orgs. +- **Billing is subscription-based** but handled outside core IAM in most products. +- **Vendor administration** may cross tenant boundaries with subscriber consent; + subscriber administration does not. +- **No IAM product defines "Customer Account"** as a separate entity type. + +## Identity-Canon Implications + +- **Subscriber** maps to **Organization** actor in **Customer Relationship** + with vendor + **Tenant** Scope — not a canonical noun. +- **Member** maps to **Account** + **Membership Relationship** to Organization. +- **Vendor** maps to **Vendor Relationship** role on vendor Organization actor. +- Supports S04, S05 without Customer Account concept. +- Individual (B2C-style) subscriber maps to **Natural Person** + **Tenant** + Scope, still without Customer Account. + +## Terminology Conflicts + +- **Customer vs. Subscriber vs. Organization**: three labels for overlapping B2B + party; IAM prefers organization or subscriber. +- **Customer vs. Consumer**: B2B2C uses both; subscriber org vs. end consumer. +- **Tenant vs. Organization**: Stytch equates customer to organization; tenant + is the isolation fabric they occupy. +- **Account**: must not be used for subscriber org or billing party. + +## Candidate Canonical Mappings + +| B2B SaaS IAM concept | Candidate canonical concept | +| --- | --- | +| Subscriber | Organization + Customer Relationship role | +| Organization (tenant holder) | Organization + Tenant Scope | +| Member | Account + Membership Relationship | +| Vendor (platform) | Organization + Vendor Relationship role | +| Tenant | Tenant (Scope) | +| User (login) | Account | +| Consumer (B2B2C) | Natural Person or Account (context-dependent) | + +## Open Questions + +- None blocking Customer Account resolution. Commercial billing layer documented + separately in `stripe-customer-billing.md`. + +## References + +- Auth0: Demystifying Multi-Tenancy in B2B SaaS — https://auth0.com/blog/demystifying-multi-tenancy-in-b2b-saas/ +- Auth0 Organizations — https://auth0.com/docs/manage-users/organizations +- Stytch: Organization tenancy — https://stytch.com/blog/organization-tenancy/ \ No newline at end of file diff --git a/research/commercial-subscription/stripe-customer-billing.md b/research/commercial-subscription/stripe-customer-billing.md new file mode 100644 index 0000000..df3cf5e --- /dev/null +++ b/research/commercial-subscription/stripe-customer-billing.md @@ -0,0 +1,102 @@ +# Stripe Customer and Subscription Billing + +## Source Type + +Product API documentation and SaaS architecture practice. Stripe Customer object +and B2B subscription billing integration patterns. + +## Domain + +Commercial billing, payment methods, subscriptions, and tenant-to-billing linkage +in multi-tenant SaaS. + +## Why This Source Matters + +Stripe's Customer object is the most widely deployed example of a **billing +customer** that is explicitly not a login account. It demonstrates why +"customer account" must be split into commercial records vs. identity records. + +## Key Concepts + +- **Customer (Stripe)**: billing entity with email, name, payment methods, + subscriptions, balance, and invoice settings. +- **Subscription**: recurring billing agreement tied to a Customer. +- **Payment method**: card or bank source attached to Customer for charges. +- **Metadata**: key-value pairs linking Stripe Customer to app tenant ID. +- **Delinquent**: billing health flag on Customer from invoice state. +- **Business name / individual name**: Customer may represent company or person. +- **customer_account (Stripe API)**: newer field referencing an Account object + representing a customer — explicit split from legacy Customer. +- **Webhook-driven sync**: Stripe owns payment state; app database owns business + state; webhooks bridge them. +- **Tenant mapping**: standard pattern stores `stripe_customer_id` on tenant record. + +## Relevant Terminology + +| Term | Source meaning | +| --- | --- | +| Customer | Stripe billing object; not authentication identity. | +| Subscription | Recurring charge agreement. | +| Invoice | Bill document; drives delinquent state. | +| Payment method | Stored payment instrument. | +| Balance | Credit or amount owed on Customer. | +| Metadata | App-defined correlation (e.g., tenant_id). | +| customer_account | Stripe Account representing customer (newer API). | +| Tenant (app) | Application isolation unit linked via metadata. | + +## Modeling Assumptions + +- **Billing state lives in payment provider**; app caches plan/feature access. +- **One Stripe Customer per tenant** is the common B2B pattern (not per login user). +- **B2B Customer** often has `business_name`; B2C may use `individual_name`. +- **Customer email** is billing contact, not necessarily login email. +- **Commercial identity can exist without Organization** (sole proprietor, individual + plan). +- **CRM "Account"** (Salesforce-style) follows similar commercial-record pattern. + +## Identity-Canon Implications + +- Stripe **Customer** maps to **Commercial Record** in Record layer — not Account, + not Customer Account, not Organization. +- Link Commercial Record to **Tenant** Scope and/or **Organization** / **Natural + Person** actor via **Commercial Relationship** or Identifier binding. +- Stripe **customer_account** field reinforces separate commercial vs. identity + account split at API level. +- **Subscription state** is Lifecycle State on Commercial Record (downstream). +- Supports S04 when billing is modeled alongside vendor/customer orgs. + +## Terminology Conflicts + +- **Customer (Stripe) vs. Customer (relationship role)**: same word, different + layers — billing object vs. vendor/customer commercial role. +- **Customer vs. Account**: Stripe uses "customer" and emerging "customer_account" + deliberately separate from login accounts. +- **Customer vs. Tenant**: integration stores stripe ID on tenant; not same entity. +- **CRM Account vs. Account (login)**: Salesforce Account = commercial record. + +## Candidate Canonical Mappings + +| Stripe / billing concept | Candidate canonical concept | +| --- | --- | +| Customer object | Commercial Record | +| Subscription | Commercial Record lifecycle / entitlement metadata | +| Payment method | Credential (payment instrument) — downstream | +| Metadata.tenant_id | Identifier binding to Tenant Scope | +| business_name | Commercial Record attribute | +| individual_name | Commercial Record attribute (person-backed) | +| customer_account (API) | Commercial Record variant / provider projection | +| Delinquent / balance | Lifecycle State on Commercial Record | +| Webhook event | Evidence Source for billing state change | + +## Open Questions + +- Should payment methods on Commercial Record map to Credential in canon, or + remain strictly downstream PCI-scoped artifacts? +- Does sole-proprietor billing (person-backed Commercial Record without + Organization) need a distinct pattern in scenario tests? + +## References + +- Stripe Customer object — https://docs.stripe.com/api/customers/object +- Stripe Billing — https://docs.stripe.com/billing +- Stripe org customer sharing — https://docs.stripe.com/get-started/account/orgs/sharing/customers-payment-methods \ No newline at end of file diff --git a/scenarios/ScenarioTests.md b/scenarios/ScenarioTests.md index b8983c1..42d260b 100644 --- a/scenarios/ScenarioTests.md +++ b/scenarios/ScenarioTests.md @@ -189,5 +189,6 @@ an explicit representation path for each scenario (S01–S15). All fifteen scenarios remain representable without glossary or principle changes. Remaining ambiguities are tracked in `OpenQuestions.md` (Realm promotion, -Customer Account concept, mandatory Synonymity Assertion fields). These affect -refinement, not scenario satisfiability. +mandatory Synonymity Assertion fields). Customer Account is resolved: use +Commercial Record for billing-side artifacts. These affect refinement, not +scenario satisfiability. diff --git a/terminology/TerminologyConflictMap.md b/terminology/TerminologyConflictMap.md index ae6e3c8..2fee6f3 100644 --- a/terminology/TerminologyConflictMap.md +++ b/terminology/TerminologyConflictMap.md @@ -53,7 +53,9 @@ Source evidence: - ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`) - ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`) -Canonical stance: Account is operational access record in a scope. +Canonical stance: Account is operational access record in a scope. Billing +records map to Commercial Record; commercial parties use Customer/Vendor roles +and Commercial Relationship. ## Conflict: Subject, Principal, Actor @@ -199,10 +201,28 @@ Source evidence: Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol role when mapping. +## Conflict: Customer Account + +Problem: `customer account` collapses login account, B2B subscriber organization, +Stripe billing customer, and CRM account into one product noun. + +Source evidence: + +- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`) +- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`) +- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`) +- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes) + +Canonical stance: **reject Customer Account** as canonical term. Resolve by layer: + +- login/access → Account; +- subscribing company → Organization + Customer role + Tenant; +- billing/CRM → Commercial Record; +- vendor↔customer link → Commercial Relationship. + ## Review Queue -- [ ] Decide Customer Account canonical concept — ZITADEL org-as-customer suggests - Organization + Tenant link, not separate Customer Account entity. +- [x] Customer Account — resolved; use Commercial Record + Commercial Relationship. - [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope specialization; promote in glossary if scenario review confirms. - [ ] Split authz `member` relation from social Membership in downstream adapters. diff --git a/terminology/TerminologyInventory.md b/terminology/TerminologyInventory.md index af2c34c..262fb2e 100644 --- a/terminology/TerminologyInventory.md +++ b/terminology/TerminologyInventory.md @@ -33,8 +33,14 @@ has incompatible meanings across source families. | machine user | Service Account | ZITADEL | Product term for non-human org identity. | | organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. | | legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. | -| customer | Customer | SaaS, vendor models | Commercial relationship role. ZITADEL org often plays customer tenant role. | -| vendor | Vendor | SaaS, multi-vendor | Provider role in commercial relationship. | +| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. | +| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. | +| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. | +| stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. | +| crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. | +| customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. | +| commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. | +| commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. | | 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. | @@ -106,6 +112,7 @@ Terms above are grounded in backfilled notes under: - `research/social-community-graphs/` (4 notes) - `research/verifiable-claims/` (3 notes) - `research/entity-resolution-privacy/` (3 notes) +- `research/commercial-subscription/` (2 notes) ## Remaining Backfill Needs