Scaffold prj-canon-federation per project-repository-flavor v0.1

GOAL.md (8 success gates + retirement conditions), SCOPE.md (authority boundary, participating repos), README.md, .repo-classification.yaml (category: project), genesis record, and CFED-WP-0001 foundation workplan (T01-T10). Governed by ADR-006 (the-custodian, status: proposed). No canon content moves before T01 accepts the boundary. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 02:39:37 +02:00 · 2026-08-16 02:39:37 +02:00 · 45e7e6d352
commit 45e7e6d352
parent a518497123
7 changed files with 517 additions and 1 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,5 @@
+# state-hub: track .claude/rules
+# Claude Code local state (track shared rules; ignore machine-specific files)
+.claude/*
+!.claude/rules/
+!.claude/rules/*.md
--- a/.repo-classification.yaml
+++ b/.repo-classification.yaml
@ -0,0 +1,29 @@
+repo_classification:
+  standard: Repo Classification Standard
+  version: "1.0"
+  classified_at: "2026-08-16"
+  classified_by: human
+  category: project
+  domain: infotech
+  secondary_domains:
+    - financials
+    - government
+  capability_tags:
+    - canon
+    - terminology
+    - governance
+    - identity
+    - documentation
+  business_stake:
+    - technology
+    - intelligence
+    - legal
+  business_mechanics:
+    - intention
+    - coordination
+    - adaptation
+  notes: >-
+    Temporary prj-flavor repository coordinating the identity-canon split:
+    identity to info-tech-canon as itc-ident, commercial content retained in
+    the same repository renamed to commerce-canon. Governed by ADR-006.
+    Archive when GOAL.md retirement gates are met.
--- a/GOAL.md
+++ b/GOAL.md
@ -0,0 +1,106 @@
+---
+repo: prj-canon-federation
+repo_flavor: project
+project_status: draft
+started: "2026-08-16"
+reviewed: "2026-08-16"
+---
+
+# Project goal
+
+## Outcome
+
+Establish a federated canon architecture in which every canonical concept has
+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;
+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;
+3. land identity as an InfoTechCanon model (`itc-ident`), importing rather than
+   redefining `itc-org` and `itc-access` concepts, filling the gap
+   `InfoTechCanonAccessControlModel.md:214` explicitly declines;
+4. bring `commerce-canon` up to the `InfoTechCanonRepositoryLayoutStandard`
+   structure (`canon.yaml`, `infospace/` with kernel/models/standards,
+   `assimilation/`, `mappings/`, `profiles/`);
+5. distribute the identity-canon research corpus as provenance into whichever
+   canon inherits the concepts it supports;
+6. publish cross-canon interface cards so the three canons reference each other
+   explicitly; and
+7. leave no dangling `identity-canon` references anywhere in the fleet.
+
+## Invariants
+
+- **One owner per concept.** No concept is defined by two canons. Downstream
+  canons import; they never redefine.
+- **Custodian canon stays normative.** Ecosystem governance (constitution,
+  values, standards, ADRs) remains in `the-custodian/canon/`; the domain canons
+  hold semantics, not ecosystem policy.
+- **Rename, do not re-found.** `identity-canon` keeps its git history, hub
+  registration, `.repo-classification.yaml` lineage, and finished workplans.
+  Nothing is archived or deleted.
+- **Canon changes are review-gated.** Content moves only after `ADR-006` is
+  `accepted`; each canon's own review gate still applies to its own content.
+- **This repo hosts no canon content.** It coordinates. Concepts live in
+  `info-tech-canon` and `commerce-canon`; decisions promote to Custodian canon.
+- **CommerceCanon grows by demand signal.** New content enters through a demand
+  signal with named consumer evidence, as InfoTechCanon already does. No
+  speculative authoring.
+- **No content is lost in transit.** Every concept present in
+  `identity-canon/canon/CanonicalGlossary.md` at project start is accounted for
+  at project end — moved, imported, or explicitly retired with rationale.
+
+## Success gates
+
+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.
+
+**G2 — Ownership ledger complete.** A machine-readable ledger maps every concept
+from the project-start glossary to exactly one owning canon and model. A
+validation pass reports zero concepts with zero owners and zero with two.
+
+**G3 — Rename landed.** `commerce-canon` exists as the renamed repository: forge
+remote, local path, hub repo slug, `.repo-classification.yaml`, and agent
+instructions all updated; git history continuous across the rename.
+
+**G4 — Identity model published.** `itc-ident` exists at
+`info-tech-canon/infospace/models/identity/`, is registered in `canon.yaml`,
+appears in the kernel map, and defines no concept owned by `itc-org` or
+`itc-access`.
+
+**G5 — Commerce canon conforms.** `commerce-canon` satisfies
+`InfoTechCanonRepositoryLayoutStandard`, carries `canon.yaml`, and holds the
+counterparty/commercial model with declared ownership.
+
+**G6 — Corpus preserved.** The `research/`, `terminology/`, and `scenarios/`
+material is present as provenance in the canon that inherited the concepts it
+supports, reachable from that canon's `assimilation/`.
+
+**G7 — Canons cross-reference.** Each canon publishes an interface card naming
+what it imports from and exports to the others. The zero-cross-reference
+condition that motivated this project no longer holds.
+
+**G8 — No dangling references.** A fleet sweep finds no live reference to
+`identity-canon` outside deliberate historical provenance.
+
+## Project retirement
+
+This repository may be archived when:
+
+1. all eight success gates have accepted evidence;
+2. residuals are live work records owned outside this repository (per
+   `work-record-types_v0.1.md` § Residuals) — in particular any deferred
+   consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`, or
+   `qonto-assistant`, which are explicitly *not* gates of this project;
+3. durable decisions are promoted to permanent homes — `ADR-006` in Custodian
+   canon, ownership boundaries in each canon's own kernel documents;
+4. the completion record is written to `history/`; and
+5. a final consistency and link check passes.
+
+Ongoing canon evolution is explicitly **not** a retirement blocker. This project
+ends when the federation exists and is correct, not when the canons are finished.
--- a/README.md
+++ b/README.md
@ -1,3 +1,18 @@
 # prj-canon-federation

-Cross-repo workplan to fold identity from identity-canon to infotech-canon and then renaming it to commerce-canon and build out our commercial canonical knowledge model from there.
+Temporary project repository coordinating the split of `identity-canon` into an
+InfoTechCanon identity model and a renamed `commerce-canon`, so that every
+canonical concept in the ecosystem has exactly one owner.
+
+The project is governed by [GOAL.md](GOAL.md). Its background, boundaries, and
+first delivery plan are recorded in
+[history/2026-08-16-genesis.md](history/2026-08-16-genesis.md),
+[SCOPE.md](SCOPE.md), and
+[CFED-WP-0001](workplans/CFED-WP-0001-foundation.md).
+
+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).
+
+This repository holds no canon content. It is designed to be retired when the
+goal and retirement gates in `GOAL.md` are satisfied.
--- a/SCOPE.md
+++ b/SCOPE.md
@ -0,0 +1,51 @@
+# Scope
+
+## Project authority
+
+This repository owns the cross-repository goal, concept-ownership boundary,
+sequencing, dependency map, migration ledger, risks, acceptance gates, and
+consolidated evidence for the canon federation effort.
+
+It does not own canon content. Concepts live in the canons themselves.
+
+## Participating repositories
+
+- `the-custodian` — `ADR-006`; durable decisions and standards
+- `info-tech-canon` — receives the identity model (`itc-ident`)
+- `identity-canon` → `commerce-canon` — renamed in place; retains commercial content
+- `state-hub` — repo slug rename, registration, agent-instruction regeneration
+
+Downstream consumers (`fin-hub`, `target-revenue`, `adaptive-pricing`,
+`qonto-assistant`) are **not** participants. They may pull from CommerceCanon
+later via demand signal; their adoption is not a gate of this project.
+
+## In scope
+
+- Concept-ownership boundary across Custodian canon, InfoTechCanon, CommerceCanon.
+- Resolution of the six ownership collisions listed in `ADR-006`.
+- The `identity-canon` → `commerce-canon` rename and all fleet references to it.
+- Landing `itc-ident` in InfoTechCanon with imports, not redefinitions.
+- Bringing CommerceCanon to `InfoTechCanonRepositoryLayoutStandard` structure.
+- Distributing the research corpus as provenance.
+- Cross-canon interface cards.
+
+## Out of scope
+
+- Hosting canon content in this repository.
+- Authoring new commercial concepts beyond what already exists in the glossary.
+  CommerceCanon grows by demand signal after the federation is in place.
+- Building CommerceCanon's service surface (CLI/JSON/API). InfoTechCanon has one;
+  whether CommerceCanon needs one is a later, evidence-driven decision.
+- Moving the Federated Organization Standard out of Custodian canon.
+- Extending `itc-org` with social collectives (`Community`, `Family Or
+  Household`) beyond recording the recommendation — that is an InfoTechCanon
+  workplan if adopted.
+- Consumer adoption of either canon.
+- Retiring or deleting any repository.
+
+## Work-record rule
+
+This project records milestones, dependencies, gates, decisions, and cross-repo
+acceptance. Each participating repository owns its own implementation workplan
+and evidence. Project records link those workplans by stable identifier rather
+than copying their task lists.
--- a/history/2026-08-16-genesis.md
+++ b/history/2026-08-16-genesis.md
@ -0,0 +1,83 @@
+# Genesis — 2026-08-16
+
+## Why this project exists
+
+The ecosystem was running two independent canons in the same market domain
+(`infotech`) with **no cross-reference in either direction**:
+
+- `info-tech-canon` — InfoTechCanon v0.6.0, `service-baseline`. Kernel, 12
+  models, 3 standards, declared per-model concept ownership, an orthogonality
+  rule ("standards can import but not redefine each other"), and a live
+  CLI/JSON/API surface on `infospace-bench`.
+- `identity-canon` — documentation-only research repo. Three `IDENTITY-WP-*`
+  workplans, all `finished`; no substantive work since the commercial-identity
+  research pass. ~60 concepts in `canon/CanonicalGlossary.md`.
+
+Three findings drove the decision.
+
+**Concept-ownership collision.** `InfoTechCanonOrganizationModel:55` owns
+`Actor, Person, Organization, Group, Role, Membership, ...`;
+`InfoTechCanonAccessControlModel:106` owns `Subject, Principal, ...`.
+identity-canon independently defined all of them. Precisely what InfoTechCanon's
+orthogonality rule exists to prevent.
+
+**An unowned gap.** `InfoTechCanonAccessControlModel:214` explicitly pushes
+identity provisioning, authentication, identity proofing, and account lifecycle
+out of scope, and `:41` does the same for generic organization modelling. So
+`Account`, `Identity Record`, `Identifier`, `Credential`, `Claim`, `Persona`,
+`Tenant`, `Realm`, `Synonymity Assertion` belonged to no model at all.
+
+**Commercial semantics accumulating in technical canon.** About a third of
+identity-canon's glossary is counterparty/commercial modelling, not identity —
+hence its `government` secondary domain. Independently,
+`info-tech-canon/demand/CapabilityProvisionEconomics.md` (accepted 2026-08-15)
+records procurement and economics demand arriving in `ITC-CAP` from consumer
+`resource-control`, domain `financials`. Two unrelated donors pushing commercial
+semantics into a technical canon is a domain boundary, not a coincidence.
+InfoTechCanon's own Purpose/Demand extension names this `ScopePressure`.
+
+## What was decided
+
+`ADR-006` (Custodian canon, status `proposed` at genesis): three federated
+canons — Custodian (ecosystem governance), InfoTech (information-processing
+semantics), Commerce (counterparty and commercial semantics) — importing but
+never redefining each other.
+
+Two shaping choices are worth recording, because both were revisions of an
+earlier plan:
+
+**Rename in place, don't found-and-archive.** The first proposal was to create a
+new `commerce-canon` repo and archive `identity-canon`. Renaming instead keeps
+git history, hub registration, `.repo-classification.yaml` lineage, and the
+three finished workplans attached to the commercial content that *stays*. Only
+identity emigrates. One repo changes name, one gains a model, nothing is
+archived.
+
+**Name it for commerce, not for "business terms".** The working name was
+`business-terms-canon`. "Terms" advertises a glossary, and an open-ended
+glossary is the failure mode — it invites every business-flavoured word in the
+ecosystem to land there with no ownership discipline. The real content is
+counterparty and commercial-relationship semantics with a KYC/AML/procurement
+driver, so the canon is named for that.
+
+## What the boundary rests on
+
+Two of the collisions were resolved by identity-canon's *own* design principles
+rather than by new argument: P1 ("Use Actor As The Participation Root") requires
+importing `itc-org`'s `Actor`; P6 ("Keep Authorization Projections Separate")
+already treats `Authenticated Subject` / `Authorization Principal` as
+projections rather than identity-owned definitions. The boundary largely wrote
+itself from principles already agreed inside the research repo.
+
+Six collisions were **not** resolved at genesis and are listed as open questions
+in `ADR-006` — `Scope`, `Assurance Level`, `Evidence Source`, `Relationship
+Tuple`, `Adjudication Outcome`, and the placement of `Community` / `Family Or
+Household`. Resolving them is the first task of `CFED-WP-0001`.
+
+## Risk being managed
+
+CommerceCanon could repeat identity-canon's failure mode: dormant, zero
+consumers, drifting. Two mitigations are built into the design — it launches
+holding real research-backed content rather than as an empty scaffold, and it
+grows only by demand signal with named consumer evidence, the mechanism
+InfoTechCanon already runs.
--- a/workplans/CFED-WP-0001-foundation.md
+++ b/workplans/CFED-WP-0001-foundation.md
@ -0,0 +1,227 @@
+---
+id: CFED-WP-0001
+type: workplan
+title: "Canon federation foundation: boundary, rename, and model placement"
+domain: infotech
+repo: prj-canon-federation
+status: ready
+owner: codex
+topic_slug: canon-federation
+created: "2026-08-16"
+updated: "2026-08-16"
+---
+
+# Canon federation foundation: boundary, rename, and model placement
+
+## Goal
+
+Establish the concept-ownership boundary, then execute the `identity-canon`
+split: identity to InfoTechCanon as `itc-ident`, commercial content retained in
+the same repository renamed to `commerce-canon`. Every concept ends with exactly
+one owner.
+
+Governed by `ADR-006` in the Custodian canon. No content moves before T01.
+
+## Resolve the boundary and accept ADR-006
+
+```task
+id: CFED-WP-0001-T01
+status: todo
+priority: high
+```
+
+Resolve the six open ownership questions in `ADR-006` and move it to `accepted`.
+This is a human review gate — every later task depends on it.
+
+1. `Scope` — `itc-ident` or `itc-access`? identity-canon P3 makes it
+   first-class; `itc-access` uses "access scope" throughout.
+2. `Assurance Level` vs `itc-gov` `Assurance` — specialization or distinct
+   concept? `Counterparty Assurance Gradient` builds on whichever wins.
+3. `Evidence Source` vs `itc-gov` `Evidence` — likely an `itc-gov`
+   specialization rather than identity-owned.
+4. `Relationship Tuple` — reads as a Zanzibar/OpenFGA-style authorization
+   primitive, so plausibly `itc-access` rather than `itc-ident`.
+5. `Adjudication Outcome` — three candidate owners: `itc-access`
+   `AuthorizationDecision`, `itc-gov` `Decision`, or commerce.
+6. `Community` / `Family Or Household` — absent from `itc-org`, which covers
+   enterprise structures only. Recommendation is to extend `itc-org` rather than
+   place them in `itc-ident`; confirm or overrule.
+
+Record each resolution with rationale in `ADR-006`, then set its status to
+`accepted`.
+
+## Build the concept-ownership ledger
+
+```task
+id: CFED-WP-0001-T02
+status: wait
+priority: high
+```
+
+Produce a machine-readable ledger under `ledger/` mapping every concept in
+`identity-canon/canon/CanonicalGlossary.md` (as of project start) to exactly one
+owning canon and model, with disposition: `import` (defined upstream, referenced
+here), `own` (moves and stays owned), or `retire` (dropped, with rationale).
+
+Include a validation pass that reports concepts with zero owners and concepts
+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.
+
+## Rename identity-canon to commerce-canon
+
+```task
+id: CFED-WP-0001-T03
+status: wait
+priority: high
+```
+
+Rename the repository in place, preserving git history:
+
+- forge repo rename on Forgejo (`coulomb/identity-canon` → `coulomb/commerce-canon`);
+- local directory and every git remote;
+- State Hub repo slug and registered local path (`make register-path`);
+- `.repo-classification.yaml` — slug, `domain` (revisit `infotech` → likely
+  `financials` with `government` secondary), capability tags;
+- regenerate agent instructions (`make update-agent-instructions`);
+- `GOAL.md`/`INTENT.md`, `SCOPE.md`, `README.md`, `AGENTS.md` prose;
+- workplan prefix decision: keep finished `IDENTITY-WP-*` files unchanged as
+  provenance, use a commerce prefix for new plans.
+
+Add a migration note to `history/` in the renamed repo per the `prj-` standard's
+slug-rename rule.
+
+## Scaffold commerce-canon to the canon layout standard
+
+```task
+id: CFED-WP-0001-T04
+status: wait
+priority: medium
+```
+
+Bring the renamed repository up to `InfoTechCanonRepositoryLayoutStandard`:
+`canon.yaml` (repository, title, status, version, classification, kernel/models/
+standards registries) and an `infospace/` tree with `kernel/`, `models/`,
+`standards/`, `assimilation/`, `mappings/`, `concepts/`, `profiles/`,
+`patterns/`, `validation/`.
+
+Write the CommerceCanon kernel document, including the ownership boundary
+against `itc-org`, `itc-gov`, and `itc-ident` — specifically `Organization`,
+`Ownership`, `Obligation`, `Decision`, `Evidence`, and `Assurance`, which are
+already owned upstream.
+
+Do **not** build a service surface. Whether CommerceCanon needs CLI/JSON/API is
+a later evidence-driven decision (`SCOPE.md`, out of scope).
+
+## Land the identity model in InfoTechCanon
+
+```task
+id: CFED-WP-0001-T05
+status: wait
+priority: high
+```
+
+Create `info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md`
+(`itc-ident`) from the ledger:
+
+- owned concepts per `ADR-006` decision 4 plus T01 resolutions;
+- imports declared explicitly — `Actor`, `Person`, `Agent`, `Organization`,
+  `Group`, `Role`, `Membership` from `itc-org`; `Subject`, `Principal` from
+  `itc-access`;
+- carry over identity-canon's design principles P1–P13 where they survive the
+  boundary, dropping those that only made sense in a standalone canon;
+- register in `canon.yaml` under `models:` and add to the kernel map;
+- update `InfoTechCanonAccessControlModel:214` so the identity boundary now
+  points at `itc-ident` instead of declaring the area unowned.
+
+Verification for gate **G4**: `itc-ident` defines no concept owned by `itc-org`
+or `itc-access`.
+
+## Land the counterparty model in CommerceCanon
+
+```task
+id: CFED-WP-0001-T06
+status: wait
+priority: high
+```
+
+Create the counterparty/commercial model in `commerce-canon` from the ledger's
+`own` entries — `Legal Entity`, `Legal Person`, `Beneficial Owner` and its
+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`,
+`Registry Identifier`, `Proxy Commercial Identifier`.
+
+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.
+
+Carry over design principles P14 ("Separate Commercial Records From Accounts")
+and P15 ("Model Commercial Binding Explicitly"), which are commerce-side.
+
+## Distribute the research corpus as provenance
+
+```task
+id: CFED-WP-0001-T07
+status: wait
+priority: medium
+```
+
+Route `research/` (8 subject areas + `CorpusIndex.md`), `terminology/`
+(`TerminologyInventory.md`, `TerminologyConflictMap.md`), and `scenarios/
+ScenarioTests.md` into the `assimilation/` tree of whichever canon inherited the
+concepts each supports. Split where a corpus area serves both.
+
+Preserve provenance — this is research that already ran; it is not re-derived.
+Record the disposition so gate **G6** is checkable.
+
+## Publish cross-canon interface cards
+
+```task
+id: CFED-WP-0001-T08
+status: wait
+priority: medium
+```
+
+Each canon publishes a Canon Interface Card naming what it imports from and
+exports to the others, per `InfoTechCanonCore`'s interface-card mechanism.
+Add the reciprocal references so the zero-cross-reference condition that
+motivated this project no longer holds (gate **G7**).
+
+Include Custodian canon in the map — it governs both domain canons and holds
+`ADR-006`, but owns no domain semantics.
+
+## Sweep fleet references
+
+```task
+id: CFED-WP-0001-T09
+status: wait
+priority: medium
+```
+
+Find and fix every live reference to `identity-canon` across the fleet: repo
+docs, hub records, MCP registrations, `.custodian-brief.md` files, capability
+registries, and `reuse-surface` entries. Deliberate historical provenance
+(genesis notes, completion records, finished workplans) stays.
+
+Gate **G8** is a clean sweep.
+
+## Record open residuals
+
+```task
+id: CFED-WP-0001-T10
+status: wait
+priority: low
+```
+
+Before this workplan is set to `finished`, every actionable leftover becomes a
+live work record outside this repository, per `work-record-types_v0.1.md`
+§ Residuals. Expected residuals:
+
+- `itc-org` extension for social collectives (`Community`, `Family Or
+  Household`), if T01 confirms the recommendation — an InfoTechCanon workplan;
+- 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.