diff --git a/README.md b/README.md index 22d3bd7..c1166de 100644 --- a/README.md +++ b/README.md @@ -15,4 +15,6 @@ Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the The [migration ledger](../prj-canon-federation/ledger/README.md) records concept destinations. Start with the draft [kernel](infospace/kernel/CommerceCanonCore.md), [registry](canon.yaml), and [layout assessment](docs/RepositoryLayout.md). -The model registries remain empty pending CFED-WP-0001-T05/T06/T11. +The draft [counterparty model](infospace/models/counterparty/CommerceCanonCounterpartyModel.md) +now defines the commerce assignments using explicit identity and evidence imports. +Corpus distribution and reciprocal interface cards remain pending T07/T08. diff --git a/SCOPE.md b/SCOPE.md index 95f099e..3abd4ea 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -25,8 +25,10 @@ CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon. The repository rename preserves history. The old mixed glossary remains a migration input. T04 establishes the draft kernel and directory layout; -CFED-WP-0001-T05/T06/T07/T11 still own model publication and provenance -distribution. The scaffold does not imply those publication gates have passed. +T05/T11 registered the draft identity and evidence models; T06 registers the +draft counterparty model. CFED T07/T08 still own provenance distribution and +reciprocal interface cards. Draft registration does not imply stable promotion +or consumer adoption. See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact. diff --git a/canon.yaml b/canon.yaml index 3525262..771d8f3 100644 --- a/canon.yaml +++ b/canon.yaml @@ -1,7 +1,7 @@ repository: commerce-canon title: CommerceCanon status: draft -version: 0.1.0-draft +version: 0.2.0-draft description: Counterparty and commercial-relationship semantics importing shared InfoTechCanon concepts. classification: kernel: Canon purpose, ownership boundary, and contribution rules. @@ -20,10 +20,12 @@ kernel: title: CommerceCanon Core path: infospace/kernel/CommerceCanonCore.md status: draft -models: [] +models: + - id: commerce-counterparty + title: CommerceCanon Counterparty Model + path: infospace/models/counterparty/CommerceCanonCounterpartyModel.md + status: draft + version: 0.1.0 + ledger_locator: counterparty standards: [] -planned_models: - - ledger_locator: counterparty - status: awaiting-model-migration - work_item: CFED-WP-0001-T06 - prerequisites: [CFED-WP-0001-T05, CFED-WP-0001-T11] +planned_models: [] diff --git a/docs/RepositoryLayout.md b/docs/RepositoryLayout.md index 26ce361..111e468 100644 --- a/docs/RepositoryLayout.md +++ b/docs/RepositoryLayout.md @@ -19,14 +19,14 @@ federation T04 requirement and InfoTechCanon's current canon.yaml layout family. Canon artifacts live under infospace/. Root assimilation/, mappings/, profiles/ are navigation entry points to that single tree, satisfying the project goal's root discovery locations without duplicating content. Legacy canon/ and model/ -remain migration inputs. Registry models and standards are intentionally empty. +remain migration inputs. The counterparty model is registered as draft; the standards registry remains empty. Full documentation conformance is not claimed: research/history retain legacy names, and spec/, wiki/, issues/ are not established. Finished IDENTITY-WP files remain unchanged in workplans/ as required by the accepted migration provenance rule, rather than being moved to history/. T07 owns source distribution. This -assessment does not claim that those models, provenance transfers, or interface -cards have been accepted. +assessment does not claim stable model promotion, provenance transfers, or interface +card completion. ## Validation diff --git a/infospace/kernel/CommerceCanonCore.md b/infospace/kernel/CommerceCanonCore.md index 8e10849..b5b4c31 100644 --- a/infospace/kernel/CommerceCanonCore.md +++ b/infospace/kernel/CommerceCanonCore.md @@ -10,7 +10,8 @@ version: 0.1.0-draft CommerceCanon owns counterparty and commercial-relationship semantics. It is an independently maintained domain canon governed by Custodian canon and the accepted CUST-ADR-006 ownership resolutions. This draft kernel establishes the -repository boundary; it does not publish the pending counterparty model. +repository boundary; the [counterparty model](../models/counterparty/CommerceCanonCounterpartyModel.md) +is now registered separately as draft 0.1.0. ## Authority and migration @@ -19,8 +20,7 @@ one owner per concept and pins the original identity-canon glossary. The old [glossary](../../canon/CanonicalGlossary.md) and [principles](../../canon/DesignPrinciples.md) remain migration inputs, not an alternative registry of CommerceCanon-owned definitions. The -[registry](../../canon.yaml) lists only artifacts present here; its model and -standard registries remain empty until their publication tasks are verified. +[registry](../../canon.yaml) lists only artifacts present here; it registers the draft counterparty model; standards remain unregistered. ## Ownership boundary @@ -29,38 +29,38 @@ standard registries remain empty until their publication tasks are verified. | Actor, Person, Agent, Organization, Group, Role, Membership, Ownership | itc-org | Import; commercial roles do not replace actor or ownership semantics. | | Subject, Principal, Relationship Tuple | itc-access | Import; commercial binding does not grant authorization. | | Obligation, Decision, AssuranceCase, AssuranceConclusion, Audit | itc-gov | Import; a commercial commitment may relate to obligations without redefining them. | -| Identifier, Account, Scope, Assurance Level and ledger-assigned identity concepts | itc-ident (pending T05) | Import when published; identifier specializations retain upstream identity semantics. | -| Evidence, Evidence Source, Adjudication Outcome, general evidence strength | itc-evid (pending T11) | Import assertions and their addressable sources as distinct concepts. | +| Identifier, Account, Scope, Assurance Level and ledger-assigned identity concepts | itc-ident (draft 0.1.0) | Import; identifier specializations retain upstream identity semantics. | +| Evidence, Evidence Source, Adjudication Outcome, general evidence strength | itc-evid (draft 0.1.0) | Import assertions and their addressable sources as distinct concepts. | | Community, Household | itc-org extension (pending T12) | Import distinct social collectives when available. | | Family | Separate InfoTechCanon concept-area seed (pending T13) | Reference only; not a CommerceCanon collective-actor definition. | Existing upstream models are [organization](../../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md), [access control](../../../info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md), and [governance](../../../info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md). -Evidence currently appears in governance; accepted R3/R7 assigns its transfer to -T11. This table records the accepted destination, not a completed transfer. -T05 must also reconcile Delegation Relationship with itc-org Delegation before -publication. Nothing in this kernel resolves that open review by duplication. +T11 transferred Evidence ownership to ITC-EVID; governance now imports it. +T05 consolidated Delegation into identity under accepted ownership, with +Organization retaining an import. Counterparty's import manifest pins the +reviewed identity, evidence, organization and governance sources. There is no single imported concept called “Assurance” covering all uses. Identity Assurance Level is distinct from governance AssuranceCase and -AssuranceConclusion. The pending Counterparty Assurance Gradient is CommerceCanon's +AssuranceConclusion. The Counterparty Assurance Gradient is CommerceCanon's named application of general evidence strength, not ownership of that dimension. ## Commerce model boundary -T06 will author the ledger's commerce assignments: legal entities and persons, +The counterparty model defines the ledger's commerce assignments: legal entities and persons, beneficial ownership relationships and exemptions, customer and vendor roles, commercial relationships and commitments, payment references and mandates, pipeline pursuits, commercial records, counterparty assurance, reputation and -performance assertions, and registry/proxy commercial identifiers. These are -assignments for migration, not definitions supplied by this kernel. +performance assertions, and registry/proxy commercial identifiers. The +model supplies the definitions; this kernel retains the ownership boundary. Registry Identifier and Proxy Commercial Identifier specialize imported Identifier. Reputation Signal, Performance Evidence, and Beneficial Ownership Exemption must distinguish evidence assertions from their sources. Adjudication -Outcome remains imported from itc-evid. Carry P14 (separate commercial records -from accounts) and P15 (model commercial binding explicitly) into T06. +Outcome remains imported from itc-evid. The model carries P14 (separate commercial records +from accounts) and P15 (model commercial binding explicitly). ## Contribution and acceptance diff --git a/infospace/models/README.md b/infospace/models/README.md index bbf5289..863ce64 100644 --- a/infospace/models/README.md +++ b/infospace/models/README.md @@ -1,3 +1,5 @@ # Models -Domain models belong here with explicit owned concepts and imports. No model is published yet; CFED-WP-0001-T06 owns the counterparty migration. +[Counterparty model](counterparty/CommerceCanonCounterpartyModel.md), draft 0.1.0, +owns the commerce ledger assignments. Its [import manifest](counterparty/imports.json) +pins the reviewed InfoTechCanon sources. diff --git a/infospace/models/counterparty/CommerceCanonCounterpartyModel.md b/infospace/models/counterparty/CommerceCanonCounterpartyModel.md new file mode 100644 index 0000000..16132e2 --- /dev/null +++ b/infospace/models/counterparty/CommerceCanonCounterpartyModel.md @@ -0,0 +1,222 @@ +--- +id: commerce-counterparty +title: CommerceCanon Counterparty Model +namespace: commerce-counterparty +type: domain-model +status: draft +version: 0.1.0 +imports: + - itc-ident + - itc-evid + - itc-org + - itc-gov +owned_concepts: + - 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 +convenience_terms: + - Reputation + - Customer Account +import_manifest: imports.json +created: "2026-09-05" +updated: "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](../../../../info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md) | Identifier, Scoped Identifier, Identity Record, Account, Scope, Tenant, Lifecycle State, Synonymity Assertion, Representation Relationship, Trust Relationship, Assurance Level, Profile | +| [ITC-EVID](../../../../info-tech-canon/infospace/models/evidence/InfoTechCanonEvidenceModel.md) | Evidence, Evidence Source, Adjudication Outcome, Evidence strength | +| [ITC-ORG](../../../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md) | Actor, Person, Organization, Role, Ownership | +| [ITC-GOV](../../../../info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md) | Obligation, Decision, AssuranceCase, AssuranceConclusion | + +[imports.json](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. + +### 2.3 Legal Entity + +**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. + +### 2.4 Legal Person + +**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 + +```text +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](../../../../prj-canon-federation/ledger/README.md) 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. diff --git a/infospace/models/counterparty/imports.json b/infospace/models/counterparty/imports.json new file mode 100644 index 0000000..2296c68 --- /dev/null +++ b/infospace/models/counterparty/imports.json @@ -0,0 +1,61 @@ +{ + "schema_version": 1, + "model": "commerce-counterparty", + "source_repository": "info-tech-canon", + "source_commit": "361c944325934ccdb190470baf6f55440b6b486e", + "imports": [ + { + "model": "itc-ident", + "path": "infospace/models/identity/InfoTechCanonIdentityModel.md", + "sha256": "20bc844d9de07041c40009cc5e3d6eeb42aeb7adcbb86b0194d4b2517aa23f32", + "concepts": [ + "Identifier", + "Scoped Identifier", + "Identity Record", + "Account", + "Scope", + "Tenant", + "Lifecycle State", + "Synonymity Assertion", + "Representation Relationship", + "Trust Relationship", + "Assurance Level", + "Profile" + ] + }, + { + "model": "itc-evid", + "path": "infospace/models/evidence/InfoTechCanonEvidenceModel.md", + "sha256": "a93472818b3ae60c07a4c6226090d63eebf1402dfd9f46dad643dbb5608ed086", + "concepts": [ + "Evidence", + "Evidence Source", + "Adjudication Outcome", + "Evidence strength" + ] + }, + { + "model": "itc-org", + "path": "infospace/models/organization/InfoTechCanonOrganizationModel.md", + "sha256": "98fb4569a555e5a91a1219b6e413b5b4e3c243d7bef15cb9db03fd8d6743f1b4", + "concepts": [ + "Actor", + "Person", + "Organization", + "Role", + "Ownership" + ] + }, + { + "model": "itc-gov", + "path": "infospace/models/governance/InfoTechCanonGovernanceModel.md", + "sha256": "5f3174147ec0d6f5bb6479a7ce4dc130bf61ecc0bab3936895b92c6baf21deb5", + "concepts": [ + "Obligation", + "Decision", + "AssuranceCase", + "AssuranceConclusion" + ] + } + ] +} diff --git a/workplans/COMMERCE-WP-0002-counterparty-model.md b/workplans/COMMERCE-WP-0002-counterparty-model.md new file mode 100644 index 0000000..e3ab6bc --- /dev/null +++ b/workplans/COMMERCE-WP-0002-counterparty-model.md @@ -0,0 +1,64 @@ +--- +id: COMMERCE-WP-0002 +type: workplan +title: "Counterparty model and explicit upstream imports" +domain: financials +repo: commerce-canon +status: finished +owner: codex +topic_slug: commerce-canon +created: "2026-09-05" +updated: "2026-09-05" +--- + +# Counterparty model and explicit upstream imports + +Implements CFED-WP-0001-T06 after T05/T11, from accepted ADR-006 and the ledger. + +## Author the commerce assignments + +```task +id: COMMERCE-WP-0002-T01 +status: done +priority: high +``` + +Represent 18 concepts and two convenience terms; carry P14/P15. Distinguish +commercial roles, records, commitments, payment references and mandates. + +## Establish explicit imports and evidence boundaries + +```task +id: COMMERCE-WP-0002-T02 +status: done +priority: high +``` + +Pin reviewed identity/evidence/organization/governance sources. Rewrite reputation, +performance and exemption as assertions with sources; import Adjudication Outcome. +Show Identifier specializations and preserve upstream ownership. + +## Validate and publish the draft + +```task +id: COMMERCE-WP-0002-T03 +status: done +priority: high +``` + +Check exact ledger coverage, import integrity, links, registry/frontmatter and +source preservation. Update current kernel/navigation and reconcile records. + +## Live continuation + +CFED T07 owns source-corpus disposition; T08 reciprocal interface cards; T09 fleet +references; T12/T13 social collective/Family work. No stable promotion or consumer +adoption is claimed. No service surface or new residual scope is introduced. + +## Verification — 2026-09-05 + +Exact ledger coverage: 18 concepts and two convenience terms. All 25 imports +resolve to four reviewed source models at InfoTechCanon commit 361c944; hashes +and registry/frontmatter match. All 53 protected files remain unchanged. Links +and whitespace checks pass; the federation ledger reports zero ownership gaps +or duplicates. See [project evidence](../../prj-canon-federation/docs/evidence/2026-09-05-counterparty-model.md).