coulomb/prj-canon-federation
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record counterparty model completion and validation

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
tegwick 2026-09-05 22:21:55 +02:00
parent ec51ab6deb
commit 829d2b7e0b
6 changed files with 191 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

55
docs/evidence/2026-09-05-counterparty-model.md Normal file
View file

@ -0,0 +1,55 @@
# 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:
```bash
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.