commerce-canon/infospace/models/counterparty/CommerceCanonCounterpartyModel.md
tegwick 55a0134b94 Publish draft counterparty model with explicit canon imports
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
2026-09-05 22:20:49 +02:00

15 KiB

id title namespace type status version imports owned_concepts convenience_terms import_manifest created updated
commerce-counterparty CommerceCanon Counterparty Model commerce-counterparty domain-model draft 0.1.0
itc-ident
itc-evid
itc-org
itc-gov
Registry Identifier
Proxy Commercial Identifier
Legal Entity
Legal Person
Beneficial Owner
Beneficial Ownership Relationship
Beneficial Ownership Exemption
Customer
Vendor
Commercial Relationship
Commercial Commitment
Payment Instrument Reference
Payment Mandate
Pipeline Pursuit
Commercial Record
Counterparty Assurance Gradient
Reputation Signal
Performance Evidence
Reputation
Customer Account
imports.json 2026-09-05 2026-09-05

CommerceCanon Counterparty Model

Draft 0.1.0 implements the accepted CUST-ADR-006 commerce assignments. It defines counterparty roles, commercial relationships and binding records while importing identity, actor, governance and evidence semantics. Registration does not assert stable promotion, consumer adoption or a legal determination.

1. Imports and ownership

Upstream model Imported meaning
ITC-IDENT Identifier, Scoped Identifier, Identity Record, Account, Scope, Tenant, Lifecycle State, Synonymity Assertion, Representation Relationship, Trust Relationship, Assurance Level, Profile
ITC-EVID Evidence, Evidence Source, Adjudication Outcome, Evidence strength
ITC-ORG Actor, Person, Organization, Role, Ownership
ITC-GOV Obligation, Decision, AssuranceCase, AssuranceConclusion

imports.json pins reviewed source versions and their hashes. Natural Person maps to imported Person. Commercial roles characterize Actors; they do not redefine Actor or Organization. Imported concepts remain defined upstream, including Adjudication Outcome. Identity Assurance Level, governance assurance arguments, and Counterparty Assurance Gradient remain distinct.

2. Owned concepts

2.1 Registry Identifier

Registry Identifier — An Identifier issued under a registered organization-identification scheme with a known issuing authority, scope and applicable jurisdiction. It specializes imported ITC-IDENT Identifier. Record scheme, authority, value, jurisdiction, relevant validity/renewal information and source references. A registry entry is a record about the entity; it is not the identifier itself. Multiple identifiers may be linked with an evidenced Synonymity Assertion, never by assuming equal strings imply the same entity.

2.2 Proxy Commercial Identifier

Proxy Commercial Identifier — A Registry Identifier issued by a commercial registry or information provider that does not itself create the identified legal entity. It specializes Registry Identifier and therefore imported Identifier. Record the issuer's commercial-proxy role explicitly; do not interpret the identifier as proof of incorporation or legal recognition.

Legal Entity — An Organization or other Actor recognized as an entity under a stated legal system. Record the recognition context and evidence rather than inferring it from a tenant, account, brand or registry number alone. This commercial characterization imports Actor/Organization and does not redefine their general semantics.

Legal Person — An Actor recognized in a stated legal context as capable of holding rights and duties. The model records that recognition for a natural Person or a juridical person without collapsing Person, Organization and Legal Entity. The applicable recognition and its limits must be supported by a source; this model does not decide legal status.

2.5 Beneficial Owner

Beneficial Owner — A role played by a natural Person asserted to ultimately own or control a Legal Entity or Organization customer under an identified rule and scope. It is not a new participation root. Represent the assertion with Beneficial Ownership Relationship; authorized representation and corporate-parent Ownership are distinct relations.

2.6 Beneficial Ownership Relationship

Beneficial Ownership Relationship — A scoped relationship asserting that a Person is a Beneficial Owner of a specified Legal Entity or Organization customer under a stated jurisdiction and rule/version. Record the ownership or control basis, applicable measurement/threshold reference, effective time, intermediary chain where relevant, and supporting Evidence with its Evidence Sources. This relation is not a subtype of generic operational Ownership. No universal percentage or list of qualifying positions is prescribed here.

2.7 Beneficial Ownership Exemption

Beneficial Ownership Exemption — An Evidence assertion that a specified counterparty is exempt from a specified beneficial-ownership collection requirement under an identified rule and scope. It specializes imported Evidence; the document or captured registry record supporting it is a separate Evidence Source. Record exemption basis, applicable rule/version, validity, and lifecycle. Missing ownership relationships do not establish an exemption.

2.8 Customer

Customer — A commercial role played by an Actor that consumes services or goods from a Vendor in a Commercial Relationship. It is not a Tenant, Organization, login Account or Commercial Record. One Actor may play different commercial roles in different relationships.

2.9 Vendor

Vendor — A commercial role played by an Actor that provides services or goods to a Customer in a Commercial Relationship. The role is neither a tenant nor a synonym for the actor's organizational form.

2.10 Commercial Relationship

Commercial Relationship — A typed, scoped relationship connecting vendor and customer Actors for a commercial or subscription purpose. It may connect Commercial Records and Commitments. It does not by itself imply membership, authorization, identity equivalence or a binding obligation.

2.11 Commercial Commitment

Commercial Commitment — A record of an evidenced binding undertaking between commercial parties under a stated scope and basis. It uses imported Obligation and Evidence rather than redefining them. Record parties, commitment type, binding basis/trigger, terms or source references, effective time and lifecycle. A signed agreement or evidenced acceptance may support the record; a CRM stage or forecast label alone does not establish a commitment. A downstream policy classifying a deal as won may be evidence of internal classification, but is not by itself evidence that the counterparty became bound.

2.12 Payment Instrument Reference

Payment Instrument Reference — A Scoped Identifier referring to a payment instrument in a payment-provider scope. Record provider scope, opaque reference value, instrument category, permitted reuse and lifecycle where applicable. It can be linked to a Commercial Record. It is not an identity Credential, a mandate, raw card data, or evidence that a payment occurred. The model holds references rather than payment secrets.

2.13 Payment Mandate

Payment Mandate — A Commercial Commitment recording scoped consent or authority for future charges against a Payment Instrument Reference. Record the parties, scope and limits, consent/authority Evidence, source and lifecycle. A saved reference alone does not establish a mandate; a mandate is distinct from a subscription and from evidence of completed payment. Actual charging and mandate enforcement belong downstream.

2.14 Pipeline Pursuit

Pipeline Pursuit — A record of an in-flight sales or procurement opportunity before the relevant Commercial Commitment is established. Record stage, role, expectations and lifecycle as planning information. Stage-change telemetry is an Evidence Source; an assertion drawn from it describes the stage change, not necessarily a binding undertaking. Promotion requires evidence of the binding trigger. A renewal may amend an existing commitment while retaining a separate pursuit for forecasting.

2.15 Commercial Record

Commercial Record — A billing, CRM or commerce-system record tracking commercial contact details, payment references, subscriptions, invoices, contracts or related state for an Actor or Tenant. It is distinct from the Actor, Customer role and login Account. Link the record through scoped Identifiers or a Commercial Relationship; record equivalence, when needed, with an evidenced Synonymity Assertion.

2.16 Counterparty Assurance Gradient

Counterparty Assurance Gradient — A named commercial application of imported Evidence strength, distinguishing opinion, observed, committed and adjudicated bases for reliance. The four tiers structure the nature of commercial support; they are not identity proofing/authentication/federation levels or a universal probability scale. Assess relevance, scope, validity and contradictions. A higher-tier item does not make every assertion about the counterparty stronger or erase conflicting evidence.

2.17 Reputation Signal

Reputation Signal — An Evidence assertion expressing crowd-sourced, platform-computed or third-party opinion about an Actor, Profile or Commercial Record. It specializes imported Evidence and uses the opinion tier of Counterparty Assurance Gradient. A review page or rating export is the Evidence Source. Record attribution, method, scope and susceptibility to manipulation; opinion does not establish a Commercial Commitment.

2.18 Performance Evidence

Performance Evidence — An Evidence assertion about observed commercial performance or a stated verification result, grounded in identified measurements or attestations. It specializes imported Evidence and uses the observed tier of Counterparty Assurance Gradient. Record the metric/question, period, method, relevant counterparty/record and Evidence Sources. Observed performance is not a commitment or a universal identity-assurance result.

3. Worked import and evidence patterns

Identifier specialization

itc-ident:Identifier
  <- Registry Identifier
       <- Proxy Commercial Identifier
itc-ident:Scoped Identifier
  <- Payment Instrument Reference

A fictional registry reference contains scheme, issuer, scope and value. The registry document is an Evidence Source; an assertion that it assigns that value to an entity is Evidence. A second registry reference needs its own context and an evidenced Synonymity Assertion before the two references are linked.

Counterparty assurance application

Tier Supporting meaning Typical record
opinion Attributed opinion or social assessment Reputation Signal drawn from a review/export
observed Observed performance or verification assertion Performance Evidence drawn from a measurement/report
committed Evidenced binding undertaking Commercial Commitment with acceptance/terms evidence
adjudicated Outcome asserted from a determination document Imported Adjudication Outcome drawn from an award/judgment

The adjudication document is an Evidence Source; the imported outcome is a distinct assertion. Record its scope and status without inferring finality or cross-jurisdiction effect. Downstream use may support a commitment transition, but the outcome does not itself execute that transition or grant authorization.

P14 — Separate Commercial Records From Accounts

A login Account and a billing Commercial Record may refer to the same Actor and Tenant while remaining different records. A Customer role identifies participation in the Commercial Relationship. Changing or deleting the login does not by itself resolve or erase the commercial record or commitment.

P15 — Model Commercial Binding Explicitly

A Pipeline Pursuit may be marked won for internal planning. Establish a Commercial Commitment only when a recorded binding basis is evidenced for the stated parties and scope. A saved payment reference additionally needs mandate/consent evidence before it represents a Payment Mandate. A record of a mandate is not a payment.

Exemption assertion and source

A fictional onboarding record states that collection is not required under rule R, version V, for counterparty C during interval T. Capture the exemption assertion with those limits and the source URI/version. An empty beneficial-owner list without that assertion is an unresolved absence, not evidence of exemption.

4. Convenience terms

Reputation is an overloaded convenience term, not an owned root concept. Resolve it to the specific signal, observation or reliance basis. Customer Account is also non-canonical: resolve login to Account, subscribing party to Actor plus Customer role, billing/CRM data to Commercial Record, and isolation to Tenant.

5. Boundary acceptance cases

Case Expected interpretation
Two equally spelled identifiers have different schemes No inferred equivalence.
A rating page is labelled Reputation Signal without an assertion Separate Evidence Source and captured opinion assertion.
A performance report is treated as a guarantee Retain observed evidence; require a separate commitment.
A beneficial-owner list is empty Do not infer an exemption.
A CRM opportunity is marked won Planning/classification evidence alone does not prove a binding undertaking.
A payment reference is saved No inferred consent, mandate or completed payment.
A judgment is copied into commerce as a new root definition Import ITC-EVID Adjudication Outcome instead.
An account is closed Do not infer termination of commercial obligations.
An adjudicated item contradicts an opinion Preserve attribution and scope; assess the conflict rather than delete provenance.

6. Provenance and publication limits

The ownership ledger pins the original mixed glossary at 4bb474970b73d500da03b6482e84e6c256146b79. All 18 commerce concepts and two convenience terms are accounted for here. P14/P15 are adapted from the donor DesignPrinciples. Source-subtype language for Reputation Signal, Performance Evidence and Beneficial Ownership Exemption is replaced by assertion specializations with distinct sources, per ADR R3/R5/R7.

Donor jurisdiction-specific examples and thresholds remain research provenance; this general model records applicable rule/version references instead of freezing those examples as universal rules. The corpus is unchanged; CFED T07 owns its recorded disposition, and T08 owns reciprocal interface cards. Native COMMERCE-WP-0002 implements this draft. No runtime service is introduced.