prj-canon-federation/docs/evidence/2026-09-05-counterparty-model.md

Counterparty model — 2026-09-05

COMMERCE-WP-0002 implements CFED-WP-0001-T06 with draft commerce-counterparty 0.1.0. It covers all 18 commerce-owned ledger concepts and the Reputation/Customer Account convenience mappings. Registry Identifier and Proxy Commercial Identifier specialize imported Identifier; Payment Instrument Reference specializes imported Scoped Identifier.

The model imports 25 concepts from four InfoTechCanon models, pinned to source commit 361c944325934ccdb190470baf6f55440b6b486e with per-file hashes. Reputation Signal, Performance Evidence and Beneficial Ownership Exemption are assertions using Evidence, not documents masquerading as assertions. Adjudication Outcome is imported. The opinion/observed/committed/adjudicated gradient remains a named commercial application of general evidence strength, distinct from identity and governance assurance.

P14 separates commercial records from login accounts; P15 distinguishes commercial binding from internal pipeline classification. A saved payment reference does not infer consent, a mandate or payment. Jurisdiction-specific thresholds remain donor research examples; the general model records applicable rule/version references instead of prescribing those thresholds universally. These are semantic model constraints, not legal determinations.

Kernel and current navigation now reflect registered identity, evidence and counterparty drafts. Original glossary, conceptual model, research, terminology, scenarios and finished workplans remain unchanged: 53 protected files match their SHA-256 snapshot. Corpus disposition remains T07; interface cards T08; social collective/Family placement T12/T13. No stable promotion, consumer adoption or runtime implementation is claimed.

Reproduce with Python 3 and PyYAML:

python3 docs/evidence/2026-09-05-counterparty-validate.py --commerce-repo ../commerce-canon --info-tech-repo ../info-tech-canon
python3 tools/validate_ownership.py --source-repo ../commerce-canon
git -C ../commerce-canon diff --check

Checks cover exact ledger/definition coverage, upstream concept presence and reviewed hashes, owned/imported disjointness, registry/frontmatter integrity, relative links and source preservation. Manual boundary cases in model section 5 cover missing evidence, false equivalence, pipeline/commitment conflation and source/assertion separation. These document checks are not runtime conformance certification. Final publication receipts follow below.

Validation result: 18 owned concepts, two convenience mappings, 25 imports from four models, 30 relative links, 53 unchanged protected files; registry/boundaries pass. Federation ledger still verifies its donor blob with zero unowned or multiply owned concepts.

Implementation commit 55a0134; published/reconciled CommerceCanon commit 8a07292dd78d094151f165d3ac1dfc7512114308. Repo-manager returned applied on primary/railiance01 with matching expected/derived commits and no refusals or retirements. Native workplan UUID 9c12f321-e413-5d96-971e-2359eaa9a411; read-back verifies all three tasks done. Progress logged for both workplans.