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

Record ownership ledger and completed CommerceCanon rename

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 20:22:12 +02:00
parent 135b5a1720
commit 745d74abd9
21 changed files with 2934 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.gitattributes vendored Normal file
View file

@ -0,0 +1,2 @@
# Unified patches use one-space context markers for empty source lines.
docs/evidence/*.patch whitespace=-blank-at-eol

10
GOAL.md
View file

@ -1,9 +1,9 @@
---
repo: prj-canon-federation
repo_flavor: project
project_status: draft
project_status: active
started: "2026-08-16"
reviewed: "2026-08-16"
reviewed: "2026-09-05"
---
# Project goal
@ -15,8 +15,8 @@ exactly one owner, and no two canons define the same concept.
The project will:
1. accept `ADR-006` (canon federation and concept ownership) and resolve its six
open ownership collisions;
1. implement accepted `ADR-006` (canon federation and concept ownership),
including its seven recorded ownership resolutions;
2. rename `identity-canon` to `commerce-canon` in place, retaining git history,
State Hub registration, and finished `IDENTITY-WP-*` workplans as provenance
for the commercial content that stays;
@ -58,7 +58,7 @@ The project will:
Each gate needs accepted evidence before the project may move to `completed`.
**G1 — Boundary accepted.** `ADR-006` status is `accepted` in Custodian canon,
with all six open questions resolved and recorded.
with all seven ownership resolutions recorded (accepted 2026-08-17).
**G2 — Ownership ledger complete.** A machine-readable ledger maps every concept
from the project-start glossary to exactly one owning canon and model. A

10
README.md
View file

@ -12,7 +12,15 @@ first delivery plan are recorded in
The governing decision is
[ADR-006](../the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md)
in the Custodian canon (status: `proposed` — content moves only once accepted).
in the Custodian canon (accepted 2026-08-17; destination canon review gates still apply).
This repository holds no canon content. It is designed to be retired when the
goal and retirement gates in `GOAL.md` are satisfied.
The [ownership ledger](ledger/README.md) records the complete source inventory,
accepted migration assignments, validation commands, and publication prerequisites.
The repository rename is complete: [CommerceCanon](../commerce-canon/README.md)
retains the donor history. The ownership ledger is complete; destination layout,
model publication, research distribution and the fleet reference sweep remain
tracked by CFED-WP-0001.

6
WORK-RECORDS.md
View file

@ -10,9 +10,9 @@
| --- | --- | --- | --- | --- |
| workplan | CFED-WP-0001 | active | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T01 | done | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T02 | wait | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T03 | wait | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T04 | wait | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T02 | done | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T03 | done | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T04 | todo | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T05 | wait | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T06 | wait | — | workplans/CFED-WP-0001-foundation.md |
| task | CFED-WP-0001-T07 | wait | — | workplans/CFED-WP-0001-foundation.md |

352
docs/evidence/2026-09-05-commerce-metadata.patch Normal file
View file

@ -0,0 +1,352 @@
--- 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.

5
docs/evidence/2026-09-05-finished-plan-hashes.json Normal file
View file

@ -0,0 +1,5 @@
{
"workplans/IDENTITY-WP-0001-statehub-bootstrap.md": "425db8bb33f4966a5f21d02480cc32553cf5603d9f903575c706a65e888ae8dc",
"workplans/IDENTITY-WP-0002-research-proposal-follow-up.md": "ea8f18a0f67281f0ac68f69629fe0de9b79e296b955b2988f86da4fe0794c951",
"workplans/IDENTITY-WP-0003-corpus-backfill-model-refinement.md": "910c7a248d1bfa4ff14c0eb5f45b182c76663bc726f57b6a826bfcd08433cae9"
}

27
docs/evidence/2026-09-05-forge-identity.json Normal file
View file

@ -0,0 +1,27 @@
{
"id": "883c98d1-0baf-49b8-ace5-858afbb985fb",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"provider": "forgejo",
"forge_instance": "https://forgejo.coulomb.social",
"forge_owner": "coulomb",
"forge_repository_id": 46,
"verification_state": "verified",
"verified_at": "2026-09-05T08:53:38.747963Z",
"verified_by": "codex CFED-WP-0001-T03",
"verification_evidence": {
"forge_snapshot": {
"name": "identity-canon",
"owner": "coulomb",
"html_url": "https://forgejo.coulomb.social/coulomb/identity-canon",
"clone_url": "https://forgejo.coulomb.social/coulomb/identity-canon.git",
"full_name": "coulomb/identity-canon",
"head_commit": "43c5c21a7a7e273241d9c7622db4e926ac9aadfa",
"repository_id": 46,
"default_branch": "main",
"projection_readable": true,
"projection_entry_count": 3,
"projection_source_present": true
},
"verified_repo_slug": "identity-canon"
}
}

7
docs/evidence/2026-09-05-forge-rename.json Normal file
View file

@ -0,0 +1,7 @@
{
"forge_repository_id": 46,
"name": "commerce-canon",
"html_url": "https://forgejo.coulomb.social/coulomb/commerce-canon",
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"method": "operator credential via warden child-only exec"
}

31
docs/evidence/2026-09-05-ownership-ledger.md Normal file
View file

@ -0,0 +1,31 @@
# CFED-WP-0001-T02 ownership-ledger evidence
Date: 2026-09-05. Authority: CUST-ADR-006 accepted-1, accepted 2026-08-17.
The [ledger](../../ledger/concept-ownership.json) covers all 60 source headings
at donor commit `4bb474970b73d500da03b6482e84e6c256146b79`. The source inventory
was checked against the original Git blob, including SHA-256 and heading lines.
Validation command:
```bash
python3 tools/validate_ownership.py --source-repo /home/worsch/identity-canon
```
[Machine-readable result](2026-09-05-ownership-validation.json): 60 mapped source
entries, 61 destination entries, two additional ADR-required concepts; 12 imports,
47 own dispositions, one split, no retirements. Zero unowned concepts, zero
multiply owned concepts, no validation errors. Source blob verified.
`python3 -m unittest discover -s tools -p 'test_*.py'` passed seven tests covering
the valid inventory, missing/duplicate source mappings, conflicting and missing
owners, a lost split destination, and accidental convenience-term promotion.
G2's migration-assignment validation is supplied. This is not acceptance of
published canon definitions: T05 still must resolve the existing itc-org
Delegation overlap; T06 must adopt the assertion/source distinction and import
Adjudication Outcome; T11 must transfer Evidence ownership from governance.
Those requirements are recorded in the live workplan and ledger notes.
Planning text now reflects ADR acceptance, all seven resolutions, and the
evidence ownership correction. The historical genesis record is unchanged.

16
docs/evidence/2026-09-05-ownership-validation.json Normal file
View file

@ -0,0 +1,16 @@
{
"source_entries": 60,
"mapped_entries": 60,
"source_targets": 61,
"additional_required_concepts": 2,
"dispositions": {
"import": 12,
"own": 47,
"split": 1
},
"unowned_concepts": 0,
"multiply_owned_concepts": 0,
"errors": [],
"source_blob_verified": true,
"valid": true
}

437
docs/evidence/2026-09-05-rename-completed.json Normal file
View file

@ -0,0 +1,437 @@
{
"id": "615e7b44-d84e-4feb-92c5-1708feaf1e65",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"old_slug": "identity-canon",
"new_slug": "commerce-canon",
"phase": "completed",
"completed_at": "2026-09-05T17:31:50.437724Z",
"expected_forge_repository_id": 46,
"expected_source_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"expected_default_branch": "main",
"error_code": null,
"phases": {
"completed": {
"at": "2026-09-05T17:31:50.437724+00:00",
"verification": {
"baseline_checksum": "46c147f9937ea63219cf0d74d2829bd2c35d599ae3d0ef66594b440a6d902439",
"checks": [
{
"actual": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"expected": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"name": "managed_repository_exists",
"ok": true
},
{
"actual": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"expected": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"name": "managed_repository_uuid",
"ok": true
},
{
"actual": true,
"expected": true,
"name": "forge_readable",
"ok": true
},
{
"actual": "commerce-canon",
"expected": "commerce-canon",
"name": "forge_coordinate",
"ok": true
},
{
"actual": 46,
"expected": 46,
"name": "forge_repository_id",
"ok": true
},
{
"actual": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"expected": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"name": "source_commit",
"ok": true
},
{
"actual": "main",
"expected": "main",
"name": "default_branch",
"ok": true
},
{
"actual": true,
"expected": true,
"name": "projection_readable",
"ok": true
},
{
"actual": "commerce-canon",
"expected": "commerce-canon",
"name": "canonical_route",
"ok": true
},
{
"actual": {
"changed": {},
"missing": {}
},
"expected": {
"changed": {},
"missing": {}
},
"name": "relationship_continuity",
"ok": true
},
{
"actual": {
"active_dispatch": 5,
"aliases": 2,
"capabilities": 0,
"decisions": 1,
"interface_changes": 0,
"messages": 0,
"progress_events": 5,
"repository": 1,
"sbom_entries": 0,
"sbom_snapshots": 0,
"services": 0,
"tasks": 19,
"token_events": 0,
"workplan_bindings": 3,
"workplans": 4
},
"expected": {
"active_dispatch": 5,
"aliases": 1,
"capabilities": 0,
"decisions": 1,
"interface_changes": 0,
"messages": 0,
"progress_events": 5,
"repository": 1,
"sbom_entries": 0,
"sbom_snapshots": 0,
"services": 0,
"tasks": 19,
"token_events": 0,
"workplan_bindings": 3,
"workplans": 4
},
"name": "record_counts_non_decreasing",
"ok": true
},
{
"actual": {
"cached_input_tokens": 0,
"raw_total_tokens": 0,
"reasoning_output_tokens": 0,
"tokens_in": 0,
"tokens_out": 0
},
"expected": {
"cached_input_tokens": 0,
"raw_total_tokens": 0,
"reasoning_output_tokens": 0,
"tokens_in": 0,
"tokens_out": 0
},
"name": "token_totals_non_decreasing",
"ok": true
},
{
"actual": {
"commerce-canon": "canonical",
"identity-canon": "alias"
},
"expected": {
"commerce-canon": "canonical",
"identity-canon": "alias"
},
"name": "slug_routes",
"ok": true
}
],
"current_checksum": "4f983651de5469f518d8b918d12e44dc0e6f4bacf58efb69b11717412d5bcd90",
"ok": true,
"operation_id": "615e7b44-d84e-4feb-92c5-1708feaf1e65",
"phase": "consumers-verified",
"relationship_checksums": {
"baseline": {
"active_dispatch": "a08a7355745c855b74f379c87edb27697499b7ddf1ee3ace08ba51eb5dbf3a03",
"capabilities": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"decisions": "1766da93d8ce8389896d2936fc7fe56913cf82620958f3d8edd9d882d0fd2292",
"interface_changes": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"messages": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"progress_events": "dcf8aed05854b2c0d681e5993bbcfc16a20a6dee49c990e3712b242b50ced171",
"repository": "4f8504b4d3efcb83233404cdc871c5ec4e35875140b41b9699cbcc44dfa5ad56",
"sbom_entries": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"sbom_snapshots": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"services": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"tasks": "29d04686d8e0f532801e6651ee5c72a1976d68614dbbedf04a6c057c9c2c3455",
"token_events": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"workplan_bindings": "6b2ed8c70b49db5f511545862d7f86902f8bb0e48ed25950080f8899a77bcd94",
"workplans": "a04f56a264c3a9e4e8c12dc84d1af294263d032a78c7560e9ca891a3997af0c6"
},
"preserved": {
"active_dispatch": "a08a7355745c855b74f379c87edb27697499b7ddf1ee3ace08ba51eb5dbf3a03",
"capabilities": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"decisions": "1766da93d8ce8389896d2936fc7fe56913cf82620958f3d8edd9d882d0fd2292",
"interface_changes": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"messages": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"progress_events": "dcf8aed05854b2c0d681e5993bbcfc16a20a6dee49c990e3712b242b50ced171",
"repository": "4f8504b4d3efcb83233404cdc871c5ec4e35875140b41b9699cbcc44dfa5ad56",
"sbom_entries": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"sbom_snapshots": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"services": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"tasks": "29d04686d8e0f532801e6651ee5c72a1976d68614dbbedf04a6c057c9c2c3455",
"token_events": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"workplan_bindings": "6b2ed8c70b49db5f511545862d7f86902f8bb0e48ed25950080f8899a77bcd94",
"workplans": "a04f56a264c3a9e4e8c12dc84d1af294263d032a78c7560e9ca891a3997af0c6"
}
},
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8"
}
},
"consumers-verified": {
"at": "2026-09-05T17:31:47.330907+00:00",
"checks": {
"canonical_clone_exact_head": true,
"finished_workplan_bytes_preserved": true,
"local_canonical_path_and_remote": true,
"old_and_new_slugs_one_uuid": true,
"remote_canonical_checkout": true
},
"operator_evidence": {
"forge_repository_id": 46,
"fresh_clone": true,
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"verification_clone": "/tmp/cfed-commerce-verification-20260905"
},
"verification": {
"baseline_checksum": "46c147f9937ea63219cf0d74d2829bd2c35d599ae3d0ef66594b440a6d902439",
"checks": [
{
"actual": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"expected": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"name": "managed_repository_exists",
"ok": true
},
{
"actual": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"expected": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"name": "managed_repository_uuid",
"ok": true
},
{
"actual": true,
"expected": true,
"name": "forge_readable",
"ok": true
},
{
"actual": "commerce-canon",
"expected": "commerce-canon",
"name": "forge_coordinate",
"ok": true
},
{
"actual": 46,
"expected": 46,
"name": "forge_repository_id",
"ok": true
},
{
"actual": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"expected": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"name": "source_commit",
"ok": true
},
{
"actual": "main",
"expected": "main",
"name": "default_branch",
"ok": true
},
{
"actual": true,
"expected": true,
"name": "projection_readable",
"ok": true
},
{
"actual": "commerce-canon",
"expected": "commerce-canon",
"name": "canonical_route",
"ok": true
},
{
"actual": {
"changed": {},
"missing": {}
},
"expected": {
"changed": {},
"missing": {}
},
"name": "relationship_continuity",
"ok": true
},
{
"actual": {
"active_dispatch": 5,
"aliases": 2,
"capabilities": 0,
"decisions": 1,
"interface_changes": 0,
"messages": 0,
"progress_events": 5,
"repository": 1,
"sbom_entries": 0,
"sbom_snapshots": 0,
"services": 0,
"tasks": 19,
"token_events": 0,
"workplan_bindings": 3,
"workplans": 4
},
"expected": {
"active_dispatch": 5,
"aliases": 1,
"capabilities": 0,
"decisions": 1,
"interface_changes": 0,
"messages": 0,
"progress_events": 5,
"repository": 1,
"sbom_entries": 0,
"sbom_snapshots": 0,
"services": 0,
"tasks": 19,
"token_events": 0,
"workplan_bindings": 3,
"workplans": 4
},
"name": "record_counts_non_decreasing",
"ok": true
},
{
"actual": {
"cached_input_tokens": 0,
"raw_total_tokens": 0,
"reasoning_output_tokens": 0,
"tokens_in": 0,
"tokens_out": 0
},
"expected": {
"cached_input_tokens": 0,
"raw_total_tokens": 0,
"reasoning_output_tokens": 0,
"tokens_in": 0,
"tokens_out": 0
},
"name": "token_totals_non_decreasing",
"ok": true
},
{
"actual": {
"commerce-canon": "canonical",
"identity-canon": "alias"
},
"expected": {
"commerce-canon": "canonical",
"identity-canon": "alias"
},
"name": "slug_routes",
"ok": true
}
],
"current_checksum": "4f983651de5469f518d8b918d12e44dc0e6f4bacf58efb69b11717412d5bcd90",
"ok": true,
"operation_id": "615e7b44-d84e-4feb-92c5-1708feaf1e65",
"phase": "source-synced",
"relationship_checksums": {
"baseline": {
"active_dispatch": "a08a7355745c855b74f379c87edb27697499b7ddf1ee3ace08ba51eb5dbf3a03",
"capabilities": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"decisions": "1766da93d8ce8389896d2936fc7fe56913cf82620958f3d8edd9d882d0fd2292",
"interface_changes": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"messages": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"progress_events": "dcf8aed05854b2c0d681e5993bbcfc16a20a6dee49c990e3712b242b50ced171",
"repository": "4f8504b4d3efcb83233404cdc871c5ec4e35875140b41b9699cbcc44dfa5ad56",
"sbom_entries": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"sbom_snapshots": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"services": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"tasks": "29d04686d8e0f532801e6651ee5c72a1976d68614dbbedf04a6c057c9c2c3455",
"token_events": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"workplan_bindings": "6b2ed8c70b49db5f511545862d7f86902f8bb0e48ed25950080f8899a77bcd94",
"workplans": "a04f56a264c3a9e4e8c12dc84d1af294263d032a78c7560e9ca891a3997af0c6"
},
"preserved": {
"active_dispatch": "a08a7355745c855b74f379c87edb27697499b7ddf1ee3ace08ba51eb5dbf3a03",
"capabilities": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"decisions": "1766da93d8ce8389896d2936fc7fe56913cf82620958f3d8edd9d882d0fd2292",
"interface_changes": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"messages": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"progress_events": "dcf8aed05854b2c0d681e5993bbcfc16a20a6dee49c990e3712b242b50ced171",
"repository": "4f8504b4d3efcb83233404cdc871c5ec4e35875140b41b9699cbcc44dfa5ad56",
"sbom_entries": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"sbom_snapshots": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"services": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"tasks": "29d04686d8e0f532801e6651ee5c72a1976d68614dbbedf04a6c057c9c2c3455",
"token_events": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
"workplan_bindings": "6b2ed8c70b49db5f511545862d7f86902f8bb0e48ed25950080f8899a77bcd94",
"workplans": "a04f56a264c3a9e4e8c12dc84d1af294263d032a78c7560e9ca891a3997af0c6"
}
},
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8"
}
},
"forge-renamed": {
"at": "2026-09-05T17:14:03.417341+00:00",
"forge": {
"clone_url": "https://forgejo.coulomb.social/coulomb/commerce-canon.git",
"default_branch": "main",
"full_name": "coulomb/commerce-canon",
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"html_url": "https://forgejo.coulomb.social/coulomb/commerce-canon",
"name": "commerce-canon",
"owner": "coulomb",
"projection_entry_count": 4,
"projection_readable": true,
"projection_source_present": true,
"repository_id": 46
},
"resumed": true
},
"preflighted": {
"at": "2026-09-05T16:31:49.660581+00:00",
"resumed": false
},
"source-synced": {
"at": "2026-09-05T17:27:28.425300+00:00",
"forge": {
"clone_url": "https://forgejo.coulomb.social/coulomb/commerce-canon.git",
"default_branch": "main",
"full_name": "coulomb/commerce-canon",
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"html_url": "https://forgejo.coulomb.social/coulomb/commerce-canon",
"name": "commerce-canon",
"owner": "coulomb",
"projection_entry_count": 4,
"projection_readable": true,
"projection_source_present": true,
"repository_id": 46
},
"operator_evidence": {
"forge_repository_id": 46,
"fresh_clone": true,
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"verification_clone": "/tmp/cfed-commerce-verification-20260905"
}
},
"statehub-rebound": {
"at": "2026-09-05T17:14:18.123008+00:00",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"resumed": false
}
}
}

16
docs/evidence/2026-09-05-rename-cutover.json Normal file
View file

@ -0,0 +1,16 @@
{
"operation_id": "615e7b44-d84e-4feb-92c5-1708feaf1e65",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"head_commit": "40d5792fafbb2de778eabb56cfeaf00aecd058e1",
"forge_repository_id": 46,
"safe_to_apply": true,
"warnings": [
{
"code": "active_work_present",
"message": "Active work must be quiesced or explicitly coordinated during cutover",
"task_count": 4,
"workplan_count": 1
}
],
"preflighted_at": "2026-09-05T16:31:20.898757Z"
}

29
docs/evidence/2026-09-05-rename-preflight-verified.json Normal file
View file

@ -0,0 +1,29 @@
{
"schema_version": "state-hub.repository-rename-preflight.v1",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"old_slug": "identity-canon",
"new_slug": "commerce-canon",
"preflighted_at": "2026-09-05T08:55:52.773629Z",
"safe_to_apply": false,
"blockers": [
{
"code": "preflight_signing_unavailable",
"message": "Repository rename preflight signing is not configured"
}
],
"warnings": [],
"report_checksum": "cbca53d8686d55e5fe356262237ce3faa3d4ff6168be9395b79b8e96fef40644",
"forge": {
"clone_url": "https://forgejo.coulomb.social/coulomb/identity-canon.git",
"default_branch": "main",
"full_name": "coulomb/identity-canon",
"head_commit": "43c5c21a7a7e273241d9c7622db4e926ac9aadfa",
"html_url": "https://forgejo.coulomb.social/coulomb/identity-canon",
"name": "identity-canon",
"owner": "coulomb",
"projection_entry_count": 3,
"projection_readable": true,
"projection_source_present": true,
"repository_id": 46
}
}

26
docs/evidence/2026-09-05-rename-preflight.json Normal file
View file

@ -0,0 +1,26 @@
{
"schema_version": "state-hub.repository-rename-preflight.v1",
"repo_id": "8c82baea-bb40-435d-ac42-ec7a7c20dbb8",
"old_slug": "identity-canon",
"new_slug": "commerce-canon",
"preflighted_at": "2026-09-05T08:50:40.484145Z",
"safe_to_apply": false,
"blockers": [
{
"code": "preflight_signing_unavailable",
"message": "Repository rename preflight signing is not configured"
},
{
"code": "forge_identity_unverified",
"message": "Repository Forge identity is not verified"
}
],
"warnings": [],
"report_checksum": "6cc2012ae940c2349f49c19a537212f1ab40e6333622585ec08f49f0297c16fb",
"registered_paths": {
"239.62.205.92.host.secureserver.net": "/home/tegwick/identity-canon",
"bnt-lap001": "/home/worsch/identity-canon"
},
"local_head": "43c5c21a7a7e273241d9c7622db4e926ac9aadfa",
"existing_platform_handoff": "cd52ba10-de41-46ce-aa8b-9b44050da8f7"
}

61
docs/evidence/2026-09-05-rename-preparation.md Normal file
View file

@ -0,0 +1,61 @@
# CFED-WP-0001-T03 rename preparation
The donor checkout was clean at `43c5c21a7a7e273241d9c7622db4e926ac9aadfa`.
Forgejo's default branch is main and its verified head matches. Repository ID
46 is now bound through the supported identity-verification API to State Hub
UUID `8c82baea-bb40-435d-ac42-ec7a7c20dbb8`. See the
[identity receipt](2026-09-05-forge-identity.json).
The [initial preflight](2026-09-05-rename-preflight.json) reported missing
signing configuration and unverified Forge identity. The identity blocker was
resolved; signing remains a deployment prerequisite. The secret must be supplied
as `REPOSITORY_RENAME_PREFLIGHT_SECRET` by the platform credential/deployment
owner. Existing platform handoff: `cd52ba10-de41-46ce-aa8b-9b44050da8f7`, recorded
in STATE-WP-0085-T09. No credential values are included in this evidence.
The [refreshed preflight](2026-09-05-rename-preflight-verified.json), captured
08:55:52 UTC, confirms the sole blocker is `preflight_signing_unavailable`;
there are no warnings and Forge identity/head are verified.
Both repository consistency runs passed with zero automation errors and zero
assessment failures. IDENTITY-WP-0004 and its five tasks are now indexed; project
T03 is synchronized as waiting on the documented signing prerequisite. Remaining
classification advisories concern existing canon/terminology capability tags.
The repository-owned plan is
[IDENTITY-WP-0004](../../../commerce-canon/workplans/IDENTITY-WP-0004-commerce-rename.md).
It records existing user authorization, the technical gate, exact identity,
phased execution, rollback limits, external verification, and retirement evidence.
The raw generated plan was reviewed and replaced with repo-specific instructions:
unrelated flex-auth runtime examples were removed and new-plan prefix handling
was reconciled with CFED-WP-0001.
The [metadata patch](2026-09-05-commerce-metadata.patch) updates README, INTENT,
SCOPE, classification and a historical preparation record. It passes:
```bash
git -C /home/worsch/identity-canon apply --check \
/home/worsch/prj-canon-federation/docs/evidence/2026-09-05-commerce-metadata.patch
```
Apply it only after the actual rebind. The existing three finished plans and
canonical/research content are untouched. Regenerate instructions after path
registration, then preserve a COMMERCE-WP override in the extension section;
the current generator otherwise infers IDENTITY-WP from historical plan counts.
Both registered host paths need an evidenced disposition:
`bnt-lap001:/home/worsch/identity-canon` and
`239.62.205.92.host.secureserver.net:/home/tegwick/identity-canon`.
The remote checkout has not been inspected or moved. CFED-WP-0001-T09 owns the
fleet sweep; the local rename plan cannot claim external owner changes complete.
No rename operation has started. No forge/local path, canonical slug, finished
workplan, or canon content was changed. The new preparation workplan is the only
manually added donor source file. A new head and preflight will be required after
preparatory work is committed and synchronized.
Continuation: signing was provisioned and the rename completed later on
2026-09-05. See [completed operation evidence](2026-09-05-rename-completed.json)
and the T03 completion record in CFED-WP-0001. The earlier blockers above are
historical preparation evidence.

68
ledger/README.md Normal file
View file

@ -0,0 +1,68 @@
# Concept-ownership migration ledger
`concept-ownership.json` assigns every heading in the project-start donor
glossary to its intended destination under CUST-ADR-006 accepted-1. This is
migration metadata, not a new home for canonical definitions.
`source-inventory.json` pins the donor commit, path, SHA-256, exact headings,
and source line numbers. The baseline is the last repository commit before
2026-08-17 UTC; the glossary itself last changed on 2026-06-21. No definitions
are copied into this repository. Git history remains the provenance source
after the rename.
## Reading the assignments
- `own`: a source concept moves to and is owned by the named destination.
- `import`: an upstream owner supplies the concept; migration consumers refer
to it rather than copying its definition. Community requires the T12 extension.
- `split`: one source entry becomes separately owned destinations. Family Or
Household becomes Household in itc-org and a separate Family seed.
- `retire`: no destination, with an explicit rationale. None are currently retired.
The four convenience terms retain that status. Their owners steward resolution
guidance; the ledger does not promote them to canonical roots.
The registry's `counterparty` and `family-area` values are migration locators,
not newly approved model identifiers. Destination repositories choose their
permanent identifiers through their own review processes. The general evidence
strength label is similarly provisional. `additional_required_concepts` records
the Evidence and strength requirements from ADR-006 that are not source headings.
## Validation
Run from this repository:
```bash
python3 tools/validate_ownership.py
python3 tools/validate_ownership.py --source-repo ../identity-canon
python3 -m unittest discover -s tools -p 'test_*.py'
```
After rename, pass `../commerce-canon` instead. The second command checks the
inventory against the pinned Git blob, independent of current working-tree edits.
The first can check assignments offline without the donor checkout.
Validation requires complete source coverage, one mapping per source heading,
valid disposition cardinality, registered owners, and no destination concept
assigned to different owners. It preserves convenience-term status and validates
the Family/Household split structurally. It does not establish semantic
equivalence from different names or inspect published canon definitions.
## Publication prerequisites
T05 must reconcile `Delegation Relationship` with existing itc-org section 10.18
`Delegation`. ADR-006 assigns actor-linking delegation to identity, but the
existing organization model already defines bounded delegation of authority.
Changing the label alone does not resolve the overlap. Preserve the accepted
assignment until the canon review resolves the boundary; if ownership must
change, amend the governing decision before publication.
T06 must rewrite the old Evidence Source subtype language in Reputation Signal,
Performance Evidence, and Beneficial Ownership Exemption against the new
assertion/source distinction. Commerce imports Adjudication Outcome from
itc-evid. T11 must remove Evidence ownership from itc-gov.
These are implementation requirements in the existing live workplan, not
untracked residuals. The ledger check supplies G2 validation evidence; accepted
project completion and proof of zero duplicate published definitions remain
separate review gates.

1339
ledger/concept-ownership.json Normal file
View file

File diff suppressed because it is too large Load diff

250
ledger/source-inventory.json Normal file
View file

@ -0,0 +1,250 @@
{
"repository_at_baseline": "identity-canon",
"baseline_date": "2026-08-16",
"commit": "4bb474970b73d500da03b6482e84e6c256146b79",
"path": "canon/CanonicalGlossary.md",
"sha256": "d5ca4392d2f89ba3e9580960b98003bb94b290dca9931456bb30c5a5fec5c70f",
"selection": "Last repository commit before 2026-08-17T00:00:00Z; glossary last changed 2026-06-21.",
"entries": [
{
"heading": "Actor",
"line": 7
},
{
"heading": "Natural Person",
"line": 18
},
{
"heading": "Artificial Agent",
"line": 26
},
{
"heading": "Collective Actor",
"line": 33
},
{
"heading": "Account",
"line": 40
},
{
"heading": "Service Account",
"line": 50
},
{
"heading": "Identity Record",
"line": 55
},
{
"heading": "Identifier",
"line": 63
},
{
"heading": "Registry Identifier",
"line": 70
},
{
"heading": "Proxy Commercial Identifier",
"line": 89
},
{
"heading": "Scoped Identifier",
"line": 97
},
{
"heading": "Credential",
"line": 102
},
{
"heading": "Claim",
"line": 115
},
{
"heading": "Authenticated Subject",
"line": 120
},
{
"heading": "Authorization Principal",
"line": 127
},
{
"heading": "Profile",
"line": 132
},
{
"heading": "Persona",
"line": 138
},
{
"heading": "Scope",
"line": 143
},
{
"heading": "Tenant",
"line": 151
},
{
"heading": "Realm",
"line": 159
},
{
"heading": "Organization",
"line": 168
},
{
"heading": "Legal Entity",
"line": 176
},
{
"heading": "Legal Person",
"line": 180
},
{
"heading": "Beneficial Owner",
"line": 189
},
{
"heading": "Beneficial Ownership Relationship",
"line": 201
},
{
"heading": "Beneficial Ownership Exemption",
"line": 222
},
{
"heading": "Customer",
"line": 231
},
{
"heading": "Vendor",
"line": 240
},
{
"heading": "Commercial Relationship",
"line": 247
},
{
"heading": "Commercial Commitment",
"line": 255
},
{
"heading": "Payment Instrument Reference",
"line": 279
},
{
"heading": "Payment Mandate",
"line": 291
},
{
"heading": "Pipeline Pursuit",
"line": 301
},
{
"heading": "Commercial Record",
"line": 316
},
{
"heading": "Community",
"line": 328
},
{
"heading": "Family Or Household",
"line": 333
},
{
"heading": "Group",
"line": 341
},
{
"heading": "Role",
"line": 348
},
{
"heading": "Relationship",
"line": 356
},
{
"heading": "Membership Relationship",
"line": 364
},
{
"heading": "Affiliation Relationship",
"line": 369
},
{
"heading": "Following Relationship",
"line": 374
},
{
"heading": "Representation Relationship",
"line": 379
},
{
"heading": "Delegation Relationship",
"line": 384
},
{
"heading": "Administration Relationship",
"line": 388
},
{
"heading": "Trust Relationship",
"line": 393
},
{
"heading": "Synonymity Assertion",
"line": 403
},
{
"heading": "Evidence Source",
"line": 420
},
{
"heading": "Counterparty Assurance Gradient",
"line": 428
},
{
"heading": "Reputation Signal",
"line": 444
},
{
"heading": "Performance Evidence",
"line": 456
},
{
"heading": "Adjudication Outcome",
"line": 467
},
{
"heading": "Non-Canonical Convenience Term: Reputation",
"line": 480
},
{
"heading": "Lifecycle State",
"line": 486
},
{
"heading": "Assurance Level",
"line": 497
},
{
"heading": "Relationship Tuple",
"line": 511
},
{
"heading": "Pseudonymous Identifier",
"line": 519
},
{
"heading": "Non-Canonical Convenience Term: User",
"line": 525
},
{
"heading": "Non-Canonical Convenience Term: Subscriber",
"line": 531
},
{
"heading": "Non-Canonical Convenience Term: Customer Account",
"line": 538
}
]
}

54
tools/test_validate_ownership.py Normal file
View file

@ -0,0 +1,54 @@
"""Exercise migration-loss and ownership-conflict failure modes."""
import copy
import json
from pathlib import Path
import unittest
from validate_ownership import validate
class OwnershipValidationTests(unittest.TestCase):
def setUp(self):
root = Path(__file__).resolve().parents[1] / 'ledger'
self.ledger = json.loads((root / 'concept-ownership.json').read_text())
self.inventory = json.loads((root / 'source-inventory.json').read_text())
def errors(self):
return validate(self.ledger, self.inventory)['errors']
def test_complete_inventory(self):
self.assertEqual(self.errors(), [])
def test_lost_source_entry(self):
self.ledger['entries'].pop()
self.assertTrue(self.errors())
def test_duplicate_mapping(self):
self.ledger['entries'].append(copy.deepcopy(self.ledger['entries'][0]))
self.assertTrue(self.errors())
def test_conflicting_owner_across_entries(self):
target = self.ledger['entries'][1]['targets'][0]
target['concept'] = 'Actor'
target['owner']['model'] = 'itc-ident'
result = validate(self.ledger, self.inventory)
self.assertEqual(result['multiply_owned_concepts'], 1)
self.assertTrue(result['errors'])
def test_missing_owner(self):
self.ledger['entries'][0]['targets'][0].pop('owner')
self.assertTrue(self.errors())
def test_lost_half_of_split(self):
entry = next(e for e in self.ledger['entries'] if e['disposition'] == 'split')
entry['targets'].pop()
self.assertTrue(self.errors())
def test_convenience_term_promotion(self):
self.ledger['entries'][-1]['targets'][0]['kind'] = 'concept'
self.assertTrue(self.errors())
if __name__ == '__main__':
unittest.main()

117
tools/validate_ownership.py Normal file
View file

@ -0,0 +1,117 @@
#!/usr/bin/env python3
"""Validate migration assignments, optionally against the pinned donor Git blob."""
import argparse
from collections import Counter, defaultdict
import hashlib
import json
from pathlib import Path
import subprocess
import sys
def validate(ledger, inventory):
errors = []
expected = [entry['heading'] for entry in inventory['entries']]
entries = ledger['entries']
counts = Counter(entry['source_heading'] for entry in entries)
if len(set(expected)) != len(expected):
errors.append('Duplicate source inventory headings')
for heading in expected:
if counts[heading] != 1:
errors.append(f'{heading}: expected one mapping, found {counts[heading]}')
for heading in counts.keys() - set(expected):
errors.append(f'Unknown source heading: {heading}')
owners = defaultdict(set)
unowned = sum(counts[heading] == 0 for heading in expected)
target_count = 0
for entry in entries:
heading = entry['source_heading']
disposition = entry['disposition']
targets = entry['targets']
if disposition not in {'own', 'import', 'split', 'retire'}:
errors.append(f'{heading}: invalid disposition')
if disposition in {'own', 'import'} and len(targets) != 1:
errors.append(f'{heading}: own/import requires exactly one target')
if disposition == 'split' and len(targets) < 2:
errors.append(f'{heading}: split requires at least two targets')
if disposition == 'retire' and (targets or not entry.get('migration_note')):
errors.append(f'{heading}: retirement requires rationale and no targets')
if not targets and disposition != 'retire':
unowned += 1
if not entry.get('authority') or not entry.get('implementation_tasks'):
errors.append(f'{heading}: missing authority or implementation task')
if heading.startswith('Non-Canonical Convenience Term: ') and any(
target.get('kind') != 'convenience_term' for target in targets
):
errors.append(f'{heading}: convenience term promoted to canonical concept')
names = [target['concept'] for target in targets]
if len(set(names)) != len(names):
errors.append(f'{heading}: duplicate split targets')
target_count += len(targets)
all_targets = [target for entry in entries for target in entry['targets']]
all_targets += ledger.get('additional_required_concepts', [])
for target in all_targets:
name = target['concept']
owner = target.get('owner', {})
canon, model = owner.get('canon'), owner.get('model')
if not canon or not model:
unowned += 1
errors.append(f'{name}: missing owner')
continue
registration = ledger['model_registry'].get(model)
if not registration or registration['canon'] != canon:
errors.append(f'{name}: owner not in model registry')
owners[name].add((canon, model))
multiple = sorted(name for name, assigned in owners.items() if len(assigned) > 1)
for name in multiple:
errors.append(f'{name}: multiple owners {sorted(owners[name])}')
return {
'source_entries': len(expected),
'mapped_entries': len(entries),
'source_targets': target_count,
'additional_required_concepts': len(ledger.get('additional_required_concepts', [])),
'dispositions': dict(sorted(Counter(e['disposition'] for e in entries).items())),
'unowned_concepts': unowned,
'multiply_owned_concepts': len(multiple),
'errors': errors,
}
def main():
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument('--ledger', type=Path, default=Path(__file__).resolve().parents[1] / 'ledger/concept-ownership.json')
parser.add_argument('--source-repo', type=Path, help='Donor checkout, under either old or new name')
args = parser.parse_args()
try:
ledger = json.loads(args.ledger.read_text())
inventory = json.loads((args.ledger.parent / ledger['source_inventory']).read_text())
result = validate(ledger, inventory)
result['source_blob_verified'] = False
if args.source_repo:
raw = subprocess.check_output([
'git', '-C', str(args.source_repo), 'show',
f"{inventory['commit']}:{inventory['path']}",
])
headings = [
{'heading': line[3:], 'line': number}
for number, line in enumerate(raw.decode().splitlines(), 1)
if line.startswith('## ')
]
if hashlib.sha256(raw).hexdigest() != inventory['sha256']:
result['errors'].append('Source blob SHA-256 mismatch')
elif headings != inventory['entries']:
result['errors'].append('Inventory differs from pinned source headings')
else:
result['source_blob_verified'] = True
result['valid'] = not result['errors']
except (OSError, ValueError, KeyError, TypeError, subprocess.CalledProcessError) as exc:
result = {'valid': False, 'errors': [str(exc)]}
print(json.dumps(result, indent=2))
return 0 if result['valid'] else 1
if __name__ == '__main__':
sys.exit(main())

85
workplans/CFED-WP-0001-foundation.md
View file

@ -8,7 +8,7 @@ status: active
owner: codex
topic_slug: canon-federation
created: "2026-08-16"
updated: "2026-08-16"
updated: "2026-09-05"
state_hub_workstream_id: "1c5615fc-03b7-5648-ba58-e828b8c0cb0f"
---
@ -85,7 +85,7 @@ residual to scope; `Family` seeded but explicitly not authored.
```task
id: CFED-WP-0001-T02
status: wait
status: done
priority: high
state_hub_task_id: "9c5ba080-e304-52cd-86d5-749a5a642387"
```
@ -105,11 +105,18 @@ with two. Zero of both is gate **G2**.
This ledger is the migration's source of truth — T05 and T06 execute from it
rather than from prose.
**Result (2026-09-05):** [Ledger](../ledger/README.md) complete: all 60
project-start source entries mapped to 61 destinations (one Family/Household
split), plus two ADR-required evidence concepts. Pinned donor-blob verification
and ownership validation pass: zero unowned and zero multiply owned
destinations. [Evidence](../docs/evidence/2026-09-05-ownership-ledger.md) records
verification and publication limits. T03 is ready to execute (`todo`).
## Rename identity-canon to commerce-canon
```task
id: CFED-WP-0001-T03
status: wait
status: done
priority: high
state_hub_task_id: "57092ca3-e1a8-5469-83be-d0338a78c150"
```
@ -129,11 +136,32 @@ Rename the repository in place, preserving git history:
Add a migration note to `history/` in the renamed repo per the `prj-` standard's
slug-rename rule.
**2026-09-05 preparation:** Local and Forge head match at
`43c5c21a7a7e273241d9c7622db4e926ac9aadfa`; Forge repository ID 46 is now
verified through State Hub on existing UUID
`8c82baea-bb40-435d-ac42-ec7a7c20dbb8`. Repository-owned implementation plan:
[IDENTITY-WP-0004](../../commerce-canon/workplans/IDENTITY-WP-0004-commerce-rename.md).
The [metadata patch](../docs/evidence/2026-09-05-commerce-metadata.patch) passes
`git apply --check` and is reserved for post-rebind application. It retains the
research classification category, assigns financials primary with government
and infotech secondary, and preserves all finished plans. New post-rename plans
will use COMMERCE-WP; the pre-cutover rename plan keeps its existing ID.
**Preparation blocker (resolved later on 2026-09-05):** deployed State Hub has no `REPOSITORY_RENAME_PREFLIGHT_SECRET`;
preflight returns `preflight_signing_unavailable`. Existing platform handoff
`cd52ba10-de41-46ce-aa8b-9b44050da8f7` (STATE-WP-0085-T09, also blocking
FLEX-WP-0020) owns this provisioning dependency. The user already authorized
proceeding; repeated rename permission is not the blocker. No operation journal,
forge rename, local path move, or metadata patch application has occurred.
The second registered host also requires a verified checkout disposition before
completion. See [preparation evidence](../docs/evidence/2026-09-05-rename-preparation.md).
## Scaffold commerce-canon to the canon layout standard
```task
id: CFED-WP-0001-T04
status: wait
status: todo
priority: medium
state_hub_task_id: "1be7aa81-4fc8-5a5a-8451-e288e660a326"
```
@ -174,6 +202,11 @@ Create `info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md`
- update `InfoTechCanonAccessControlModel:214` so the identity boundary now
points at `itc-ident` instead of declaring the area unowned.
**Publication prerequisite (2026-09-05):** reconcile actor-linking
`Delegation Relationship` assigned here by ADR-006 with existing itc-org section
10.18 `Delegation`. Do not duplicate the same semantics under a different name.
Resolve through destination canon review; amend ADR-006 if ownership changes.
Verification for gate **G4**: `itc-ident` defines no concept owned by `itc-org`
or `itc-access`.
@ -191,9 +224,15 @@ Create the counterparty/commercial model in `commerce-canon` from the ledger's
relationship/exemption concepts, `Customer`, `Vendor`, `Commercial
Relationship`, `Commercial Commitment`, `Payment Instrument Reference`, `Payment
Mandate`, `Pipeline Pursuit`, `Commercial Record`, `Counterparty Assurance
Gradient`, `Reputation Signal`, `Performance Evidence`, `Adjudication Outcome`,
Gradient`, `Reputation Signal`, `Performance Evidence`,
`Registry Identifier`, `Proxy Commercial Identifier`.
Import `Adjudication Outcome`, `Evidence`, and `Evidence Source` from
`itc-evid` per R3/R5/R7. Rewrite the old Evidence Source subtype wording in
Reputation Signal, Performance Evidence, and Beneficial Ownership Exemption
to distinguish assertions from their sources. T11 must establish the shared
evidence model before these imports can be verified.
Model identifier subtypes as the worked example of the import pattern:
`itc-ident` owns `Identifier`; CommerceCanon owns `Registry Identifier` and
`Proxy Commercial Identifier` as specializations of it.
@ -341,3 +380,39 @@ live work record outside this repository, per `work-record-types_v0.1.md`
- CommerceCanon service-surface decision, if demand appears;
- consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`,
`qonto-assistant` — demand-signal driven, explicitly not a gate here.
## T03 cutover continuation — 2026-09-05
Signing is provisioned (RPF-WP-0035-T04 done). The donor preparation is committed
and pushed at `40d5792fafbb2de778eabb56cfeaf00aecd058e1`. Operation
`615e7b44-d84e-4feb-92c5-1708feaf1e65` started with a passing fresh preflight.
The operator credential route performed the exact Forge rename; repository 46
is now `commerce-canon` at that same head. State Hub had no Forge write token,
so the runbook's operator-side rename/reconcile path was used with contained
OIDC and automatic session revocation.
State Hub reconciliation exposed a 307 redirect handling defect before rebind.
[STATE-WP-0089](../../state-hub/workplans/STATE-WP-0089-rename-redirect-recovery.md)
owns the fix, regression tests, image promotion and journal recovery. No direct
DB change, replacement journal, or weakening of immutable identity checks is
allowed. Both checkouts remain at the old path until rebind is verified.
## T03 completed — 2026-09-05
[Rename evidence](../docs/evidence/2026-09-05-rename-completed.json) records the
completed operation on the same Forge ID 46 and State Hub UUID. Both registered
checkouts are now commerce-canon with canonical remotes; the old State Hub slug
is a protected alias. Metadata, financials classification and agent instructions
are published at commerce-canon commit `c7002cf`. Three finished historical plans
remain byte-for-byte unchanged and the ledger still verifies its pinned source.
STATE-WP-0089 fixed and proved redirect recovery: 46 tests pass; deployed image
main-fe6b8d9, Helm revision 60; same journal resumed and completed. No direct DB
repair or replacement identity was used.
Live remaining work: REUSE-WP-0021 owns federation source/roster/cache updates;
T09 retains fleet-wide reference and projection acceptance. T04 is now todo.
The rename gate is complete; the canon layout, model moves and G8 fleet sweep
are not claimed complete by this result.