← Back to catalogue
Published

Enterprise Counterparty Relationship

vr.profile.enterprise-counterparty-relationship · enterprise-counterparty-relationship

Represent customer, supplier and partner roles for one Party without duplicating Party identity, upstream relationship records or contact endpoint values.

Enterprise profiles Cross-cutting context EnterpriseCommercialCounterpartyCRM
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

4 bundles · 8 layers · 16 findings · 32 questions

Identity and authority Govern identity and authority without duplicating upstream identity or authority.

Party anchoring

Make party anchoring explicit and testable.

Set identity

Validate set identity against the bounded profile contract.

  1. Which Party and observing Dimension identify this set? evidence
  2. Can any role create another Party? decision

Party master

Validate party master against the bounded profile contract.

  1. Which authority resolves partyRef? evidence
  2. Is a split Party master held rather than hidden? decision

Commercial authorities

Make commercial authorities explicit and testable.

Role ownership

Validate role ownership against the bounded profile contract.

  1. Which upstream model owns this role? evidence
  2. Does customer resolve only to 014 and supplier/partner to 015? decision

Exact referent

Validate exact referent against the bounded profile contract.

  1. Which versioned upstream record is bound? evidence
  2. Is lifecycle copied into the profile? decision
Scope and roles Govern scope and roles without duplicating upstream identity or authority.

Concurrent roles

Make concurrent roles explicit and testable.

Multi-role set

Validate multi-role set against the bounded profile contract.

  1. Which roles are active at the requested time? evidence
  2. Does adding a role preserve Party identity? decision

Role validity

Validate role validity against the bounded profile contract.

  1. What half-open interval applies to each binding? evidence
  2. How is upstream supersession surfaced? decision

Account scope

Make account scope explicit and testable.

Scope kind

Validate scope kind against the bounded profile contract.

  1. Is the frame seller, buyer, legal entity or group? evidence
  2. Which target resolves the scope? decision

Group boundary

Validate group boundary against the bounded profile contract.

  1. Which group perimeter authority is referenced? evidence
  2. Is membership inferred from tax ID or CRM hierarchy? decision
Contacts and classification Govern contacts and classification without duplicating upstream identity or authority.

Contact assignment

Make contact assignment explicit and testable.

Endpoint reference

Validate endpoint reference against the bounded profile contract.

  1. Which WM-PER-010 endpoint is assigned? evidence
  2. Does the assignment copy an endpoint value? decision

Assignment context

Validate assignment context against the bounded profile contract.

  1. Which purpose, role, scope and interval apply? evidence
  2. Does assignment imply consent or reachability? decision

Segmentation assertions

Make segmentation assertions explicit and testable.

Sourced segment

Validate sourced segment against the bounded profile contract.

  1. Which code, scheme, version and source support this assertion? evidence
  2. Is a bare segment label rejected? decision

Assertion history

Validate assertion history against the bounded profile contract.

  1. Which method and asserted time apply? evidence
  2. Are conflicts retained and corrections appended? decision
Projection and controls Govern projection and controls without duplicating upstream identity or authority.

Current projections

Make current projections explicit and testable.

rolesAt

Validate rolesat against the bounded profile contract.

  1. Which bindings are active at time t? evidence
  2. Does projection mint a relationship? decision

contactsFor

Validate contactsfor against the bounded profile contract.

  1. Which assignments match purpose and time? evidence
  2. Is current permission rechecked at endpoint authority? decision

Boundary controls

Make boundary controls explicit and testable.

Endpoint conflict

Validate endpoint conflict against the bounded profile contract.

  1. Is the PER-010/XCT-024 conflict still visible? evidence
  2. Can XCT-024 become a second party endpoint master? decision

Neighbor exclusion

Validate neighbor exclusion against the bounded profile contract.

  1. Which contract, order, consent and event refs remain external? evidence
  2. Does any profile field absorb their lifecycle? decision

Classifiers Filled

Family
Enterprise profiles
Category
Cross-cutting context
Entry kind
companion-contract
Navigation path
NAV.XCT
Domain
EnterpriseCommercialCounterpartyCRMProcurement
Industry
Cross-industry
Tags
EM-COM-01counterpartycustomersupplierpartnercontact-assignmentsegmentationparty-role
Also called
Counterparty Relationship Profile, Customer Supplier Partner Relationship, EM-COM-01

What it is Filled

A companion profile for a Company Dimension that represents the commercial roles one party plays towards the company, as customer, supplier or partner, in a stated scope, while party identity and contact values stay in their own masters.

Why it exists Filled

Represent customer, supplier and partner roles for one Party without duplicating Party identity, upstream relationship records or contact endpoint values.

Distinguishing features Filled

  • Represents the customer, supplier and partner roles of one party without duplicating the party record.
  • Holds references to contact endpoints rather than copies of their values.
  • Separates the commercial relationship from the legal identity of the counterparty.

What robots and AI may and may not do Filled

Must not

  • Create a second party identity for a party that already exists upstream.
  • Copy contact values into the relationship record.
  • Change the upstream party or CRM master while validating.

Only with a human decision

  • Starting or ending a relationship with a counterparty.
  • Resolving which upstream record is the master when two disagree.

May

  • Run profile validation on counterparty roles.
  • Read which roles a party holds and in which scope.

Moral aspects Filled

  • Contact details of people at counterparties are personal data and must stay minimal and purpose-bound.
  • Role labels such as blocked supplier affect livelihoods and need evidence and review.

Who is affected

  • Contact persons at customers, suppliers and partners
  • Sales and procurement staff

Owners Filled

Steward

The commercial operations owner stewards counterparty roles; party identity stays with the party master.

Master systems

  • Party or business partner master
  • CRM
  • Procurement or supplier management system

Links to other meta-models Filled

references

  • WM-ORG-014 - 0.3.0-research.1
  • WM-ORG-015 - 0.3.0-research.1
  • WM-PER-010 - 0.3.0-research.1
  • WM-XCT-024 - 0.3.0-research.1

aligned

  • vr.wm-org-014
  • vr.wm-org-015
  • vr.wm-per-010
  • vr.wm-xct-024

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • Party reference to the upstream master record.
  • Role and scope identifiers local to the Company Dimension.

Direct properties not applicable Not applicable

Not applicable

Institutional or informational subject: it has no physical body to measure.

Recognition optional Filled

  • A counterparty role names one party, a role type (customer, supplier, partner) and a scope.

Capabilities and actions required Filled

  • Run the profile validation without changing an upstream master.

Hazards and failure modes required Filled

  • Duplicate counterparties that split history and limits.
  • Stale roles that keep blocked or ended partners active.

Standards and interfaces required Filled

  • GLEIF LEI for legal entity identification.
  • Party models in CRM and ERP systems.

Context of use required Filled

  • Sales, procurement and partner management inside one company or group.

Sources Filled

  1. Research record EM-COM-01: independent provider studies, audits and reconciled findings - Evidence behind the release; claims in the card trace to it.
  2. Enterprise Counterparty Relationship 0.1.0 specification - Normative release, digest sha256:f6b101478d085ed109ef5ef24482353aadd92daa2b135618b9c32cfd746b3dc3

Open questions

  • Use the pinned companion schema/validator and trusted-host binding. Native outer validation alone does not enforce nested semantics. Consult the released adoption limits. Use only with authoritative Party resolution, pinned upstream records and the semantic evaluator. The profile does not own Party identity, relationship lifecycle, endpoint values, consent or classification schemes. Required reading: https://ver.cy/models/enterprise-counterparty-relationship/versions/0.1.0/publication-addendum.md

Machine files

Card as JSON Specification AGENTS.md Package Source Card backlog vercy.card/1

Provenance

enterprise research · reviewable-draft

Built from: models/enterprise-counterparty-relationship/versions/0.1.0/spec.json, models/enterprise-counterparty-relationship/catalogue-entry.json, ver-cy/world-models/card-supplements/enterprise-counterparty-relationship.json