prj-canon-federation/docs/evidence/2026-09-05-commerce-metadata.patch

--- a/README.md
+++ b/README.md
@@ -1,12 +1,16 @@
-# identity-canon
+# commerce-canon
 
-Orthogonal vocabulary and canonical model for identity-related concepts.
+CommerceCanon owns counterparty and commercial-relationship semantics and imports
+shared identity, organization, access, governance, and evidence concepts from
+InfoTechCanon. Custodian canon governs both domain canons.
 
-Start with:
+This repository continues the history of `identity-canon` under accepted
+CUST-ADR-006. The federation migration is coordinated by
+[CFED-WP-0001](../prj-canon-federation/workplans/CFED-WP-0001-foundation.md).
+The existing glossary and research remain migration inputs until the destination
+models pass their canon review gates; the rename alone does not publish them.
 
-- `INTENT.md` for purpose and project boundaries;
-- `ResearchProposal.md` for the research method and expected deliverables;
-- `research/CorpusIndex.md` for the source-note corpus;
-- `canon/CanonicalGlossary.md` and `model/ConceptualModel.md` for the current
-  draft canon;
-- `workplans/` for State Hub-tracked work.
+Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the
+[research corpus](research/CorpusIndex.md), and [workplans](workplans/).
+The [migration ledger](../prj-canon-federation/ledger/README.md) records concept
+destinations. The new canon layout is tracked by CFED-WP-0001-T04.
--- a/INTENT.md
+++ b/INTENT.md
@@ -1,168 +1,23 @@
-# INTENT.md
+# Intent
 
-## Purpose
+CommerceCanon provides researched, implementation-neutral semantics for
+counterparties, legal/commercial roles, commercial relationships and commitments,
+payment references, and counterparty assurance.
 
-`identity-canon` exists to research, clarify, and define a canonical terminology and conceptual data model for identity, user, organization, community, and relationship management across multi-tenant, multi-vendor, multi-community systems.
+Each concept has one owner. Commerce imports shared concepts from InfoTechCanon
+rather than redefining actors, accounts, identifiers, authorization, or evidence.
+For example, Commerce owns Registry Identifier as a specialization of the shared
+Identifier; Adjudication Outcome is imported from the evidence model.
 
-The project is intentionally focused on the **research and terminology layer**. It does not implement user management, identity provisioning, authentication, authorization, or UI workflows directly. Instead, it provides the conceptual foundation that later implementation projects can rely on.
+This repository continues the research and Git history of identity-canon under
+CUST-ADR-006, accepted 2026-08-17. Existing identity research migrates to its owning
+canon through the project ledger. Research remains provenance; draft definitions
+require destination review before publication.
 
-## Core Intent
+New commercial content requires a demand signal with named consumer evidence.
+Potential consumers include fin-hub, target-revenue, adaptive-pricing, and
+qonto-assistant; their adoption is not a federation completion gate.
 
-The core intent is to develop a clear, orthogonal vocabulary and canonical model for describing:
-
-* natural persons, users, accounts, identities, personas, and profiles
-* organizations, enterprises, sub-organizations, vendors, tenants, customers, and legal entities
-* communities, families, households, teams, spontaneous groups, and social graphs
-* actors, agents, bots, service accounts, and delegated representatives
-* memberships, affiliations, followers, ownership, representation, delegation, and trust relationships
-* weak and strong synonymity between identities, accounts, identifiers, and real-world actors
-* the distinction between social, legal, operational, and authorization-relevant relationships
-
-The project should help avoid the common collapse of overloaded terms such as `user`, `group`, `role`, `tenant`, `organization`, `account`, and `identity`.
-
-## Strategic Role
-
-`identity-canon` is a reference project for future identity-related systems and implementation repositories.
-
-It should provide:
-
-1. a researched corpus of relevant standards, concepts, and terminology;
-2. a canonical vocabulary suitable for humans and agents;
-3. a conceptual model for user, organization, community, and identity management;
-4. a basis for later schemas, APIs, CLI tools, UI workflows, and adapter implementations;
-5. a shared language for connecting IAM, social graph, enterprise directory, community, family, and authorization concepts.
-
-The repository should serve as a stable conceptual anchor before implementation-specific decisions are made.
-
-## Intended Users
-
-The primary users of this repository are:
-
-* system architects designing multi-tenant identity and user-management systems;
-* developers implementing user, organization, tenant, and community management components;
-* security and IAM engineers integrating systems such as Keycloak, Keycape, LLDAP, Authelia, privacyIDEA, OpenBao, SCIM, OIDC, SAML, LDAP, OpenFGA, Cedar, or related tools;
-* product designers creating CLI and UI workflows for managing users, organizations, communities, and relationships;
-* AI agents that need a precise terminology reference when generating schemas, documentation, workflows, or implementation plans.
-
-## Scope
-
-`identity-canon` covers research, terminology, and conceptual modeling.
-
-In scope:
-
-* literature and standards research;
-* terminology analysis;
-* canonical concept definitions;
-* comparison of overlapping terms across IAM, directory services, social graphs, enterprise systems, and authorization models;
-* conceptual diagrams and model descriptions;
-* model constraints and design principles;
-* synonymity and entity-resolution concepts;
-* scope, tenant, organization, community, family, and group distinctions;
-* relationship semantics such as membership, affiliation, representation, delegation, following, ownership, and trust;
-* recommendations for future implementation repositories.
-
-Out of scope:
-
-* implementation code;
-* production APIs;
-* database migrations;
-* UI components;
-* CLI commands;
-* adapter implementations;
-* direct integration with Keycloak, LDAP, SCIM, OIDC, SAML, OpenFGA, or other systems;
-* operational identity lifecycle tooling.
-
-Implementation repositories may later consume the results of `identity-canon`, but this repository remains implementation-neutral.
-
-## Design Principles
-
-### 1. Do not start with “user”
-
-The term `user` is overloaded. The canonical model should avoid using `user` as the root concept. Instead, it should distinguish actors, natural persons, accounts, identities, profiles, personas, credentials, and principals.
-
-### 2. Separate social, legal, operational, and authorization semantics
-
-An organization may be a legal entity, a tenant, a community, a billing customer, an employer, a vendor, or an authorization scope — but these meanings must not be collapsed into one concept.
-
-### 3. Model relationships explicitly
-
-Membership, affiliation, following, ownership, representation, delegation, administration, and trust should be modeled as distinct relationship types, not hidden inside groups or roles.
-
-### 4. Treat synonymity as an assertion, not a destructive merge
-
-Weak and strong synonymity should be represented as scoped, evidenced assertions between identifiers, accounts, identities, or actors. Identity linking should preserve source, confidence, scope, evidence, and revocation state.
-
-### 5. Keep concepts orthogonal
-
-The model should minimize conceptual overlap. If two terms are similar, the repository should explain the distinction or deliberately collapse them with clear justification.
-
-### 6. Remain implementation-neutral
-
-The canonical model should be compatible with common IAM, directory, social graph, and authorization systems, but should not mirror any single product’s terminology too closely.
-
-## Research Areas
-
-The repository should collect and analyze knowledge from at least the following areas:
-
-* SCIM, LDAP, and directory schemas;
-* OpenID Connect, SAML, WebAuthn, and federation models;
-* NIST digital identity guidelines and identity assurance terminology;
-* Keycloak, ZITADEL, Ory, Authelia, LLDAP, and related IAM systems;
-* ActivityPub, FOAF, WebID, Solid, and social graph models;
-* Google Zanzibar, OpenFGA, Cedar, Cerbos, and relationship-based authorization;
-* W3C DID and Verifiable Credentials;
-* entity resolution, identity matching, and synonymity;
-* GDPR-relevant concepts such as pseudonymization, data minimization, and identity linkage.
-
-## Expected Outputs
-
-The repository should eventually contain:
-
-* a curated research corpus;
-* a glossary of canonical identity-management terms;
-* a terminology conflict map;
-* a conceptual entity and relationship model;
-* synonymity and identity-linking model notes;
-* comparison notes against major standards and tools;
-* model design principles;
-* candidate schema sketches;
-* recommendations for downstream implementation projects.
-
-## Downstream Relationship
-
-`identity-canon` may later inform projects such as:
-
-* `user-engine` — operational user and account management;
-* `user-accounts` — user-facing account and preference UI;
-* `user-manager` — administrative user-management UI;
-* `identity-connect` — adapters to IAM and directory systems;
-* `actor-graph` — relationship and synonymity graph engine;
-* `access-control` or related authorization projects;
-* tenant, organization, community, and family management tooling.
-
-These projects should treat `identity-canon` as a conceptual reference, not as an implementation dependency unless a later explicit schema package is extracted.
-
-## Non-Goals
-
-`identity-canon` is not intended to become:
-
-* a replacement for Keycloak, LDAP, SCIM, OIDC, SAML, or OpenFGA;
-* a complete authorization policy language;
-* a production identity provider;
-* a database product;
-* a UI framework;
-* a CLI implementation;
-* a social network implementation.
-
-Its value lies in making the terminology and conceptual structure clear enough that such systems can later be designed and integrated coherently.
-
-## Guiding Question
-
-The guiding question of `identity-canon` is:
-
-> What is the smallest clear set of orthogonal concepts needed to model persons, accounts, identities, organizations, tenants, communities, families, agents, and their relationships across enterprise IAM, social systems, and multi-tenant platforms?
-
-## Status
-
-This repository begins as a research and terminology project. Its early work should prioritize clarity, comparison, and conceptual grounding over premature schema or implementation design.
-
+CommerceCanon provides semantics and research. Runtime services, APIs, CLI tools,
+application integrations, and speculative expansion require separate demand and
+work records. Ecosystem policy remains in Custodian canon.
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -1,54 +1,32 @@
-# SCOPE
+# Scope
 
-## One-liner
+CommerceCanon owns counterparty and commercial-relationship semantics under
+CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon.
 
-Orthogonal vocabulary and canonical model for identity-related concepts.
+## In scope
 
-## Core Idea
+- Preserve the existing research corpus, scenarios, terminology, Git history,
+  and finished IDENTITY-WP workplans as provenance.
+- Implement the commerce assignments in the federation ownership ledger.
+- Establish the canon layout, kernel boundary, and reciprocal interface cards.
+- Separate commercial records from login accounts and model commercial binding
+  explicitly, carrying forward design principles P14 and P15.
+- Grow through named consumer demand; record implementation in local workplans.
 
-`identity-canon` is a research and terminology repository. It defines an
-implementation-neutral vocabulary and conceptual model for identity, accounts,
-actors, organizations, tenants, communities, families, agents, relationships,
-and synonymity across IAM, directory, federation, social graph, authorization,
-decentralized identity, and entity-resolution domains.
+## Out of scope
 
-## In Scope
+- Re-own identity, organization, access-control, governance, or general evidence
+  concepts; redefine Adjudication Outcome in CommerceCanon.
+- Implement runtime identity or payment services, production APIs, or a CLI.
+- Author Family beyond the separately owned seed or speculative new commercial
+  concepts. Consumer adoption is separately owned.
 
-- Maintain research notes, source summaries, terminology inventories,
-  conflict maps, canonical glossary entries, conceptual model notes, scenario
-  tests, open questions, downstream recommendations, and State Hub workplans.
-- Compare overlapping terms across standards, product documentation, social
-  graph models, authorization systems, and privacy/entity-resolution research.
-- Keep canonical definitions separate from external product mappings.
-- Record decisions, progress, and workplan status through State Hub.
-- Verify changes with markdown review, `git diff --check`, and ADR-001
-  consistency checks.
+## Migration status
 
-## Out of Scope
+The repository rename preserves history. The old mixed glossary remains a
+migration input until CFED-WP-0001-T04/T05/T06/T07 establish the destination
+layout, models, and provenance distribution. Rename completion does not imply
+those publication gates have passed.
 
-- Implement identity providers, account-management services, provisioning
-  adapters, authorization engines, UI components, CLI commands, databases, or
-  production APIs.
-- Own unrelated adjacent systems or operational identity lifecycle tooling.
-- Make irreversible operational decisions without human approval.
-- Treat draft canon artifacts as finalized schemas before source-note backfill
-  and scenario review.
-
-## Current State
-
-- Status: active research scaffold.
-- The repository is currently documentation-only. It has no package manifest,
-  build system, runtime app, or executable test suite.
-- `IDENTITY-WP-0002` seeded the first terminology, canon, model, scenario,
-  open-question, and downstream recommendation artifacts. The next research
-  pass should backfill individual source notes and revise the draft canon from
-  evidence.
-
-## Getting Oriented
-
-- Start with: INTENT.md
-- Research proposal: ResearchProposal.md
-- Corpus index: research/CorpusIndex.md
-- Draft canon: canon/CanonicalGlossary.md and model/ConceptualModel.md
-- Agent instructions: AGENTS.md
-- Workplans: workplans/
+See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use
+COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact.
--- a/.repo-classification.yaml
+++ b/.repo-classification.yaml
@@ -1,17 +1,16 @@
 repo_classification:
   standard: Repo Classification Standard
   version: '1.0'
-  classified_at: '2026-06-22'
-  classified_by: human
+  classified_at: '2026-09-05'
+  classified_by: codex
   category: research
-  domain: infotech
+  domain: financials
   secondary_domains:
   - government
+  - infotech
   capability_tags:
-  - identity
-  - access-control
+  - canon
   - terminology
-  - canon
   - governance
   business_stake:
   - technology
@@ -22,4 +21,8 @@
   - intention
   - control
   - adaptation
-  notes: Identity canon; standard §13.3 — human confirmed.
+  notes: >-
+    CommerceCanon continues identity-canon history under CUST-ADR-006 accepted
+    2026-08-17 and CFED-WP-0001-T03. Financials is primary for counterparty and
+    commercial semantics; government and infotech capture its regulatory and
+    imported technical boundaries. Research category is retained during migration.
--- /dev/null
+++ b/history/2026-09-05-commerce-rename-preparation.md
@@ -0,0 +1,16 @@
+# CommerceCanon rename preparation — 2026-09-05
+
+CUST-ADR-006 and CFED-WP-0001 authorize renaming identity-canon in place to
+commerce-canon. State Hub repository UUID is
+8c82baea-bb40-435d-ac42-ec7a7c20dbb8; verified Forgejo repository ID is 46.
+The three finished IDENTITY-WP workplans remain unchanged. New plans after
+cutover use COMMERCE-WP; the pre-cutover IDENTITY-WP-0004 retains its ID.
+
+Preparation baseline: 43c5c21a7a7e273241d9c7622db4e926ac9aadfa. This is a
+preparation record, not evidence that the rename completed. Record the final
+operation ID, cutover date/head, continuity verification, registered-host
+outcomes, and metadata commit in the rename workplan at execution.
+
+Identity and evidence content move to InfoTechCanon through the ownership ledger;
+commercial content stays here. Research and historical references remain
+provenance. Runtime implementation and downstream adoption are separately owned.