diff --git a/.custodian-brief.md b/.custodian-brief.md new file mode 100644 index 0000000..27f6fa8 --- /dev/null +++ b/.custodian-brief.md @@ -0,0 +1,27 @@ + +# Custodian Brief - prj-canon-federation + +**Project:** prj-canon-federation +**Domain:** infotech +**State Hub:** http://127.0.0.1:8000 +**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a` + +## Open Workplans + +### Bootstrap State Hub integration + +Workplan file: `workplans/PRJ-WP-0001-statehub-bootstrap.md` + +Open tasks: +- T01 - Review generated integration files +- T02 - Verify local developer workflow +- T03 - Seed first real workplan + +## Session Start + +1. Read `GOAL.md`, `SCOPE.md`, and `AGENTS.md` (prj- flavor: `GOAL.md`, no `INTENT.md`). +2. Check inbox: `GET /messages/?to_agent=prj-canon-federation&unread_only=true`. +3. Scan `workplans/`. +4. Update task statuses in workplan files as work progresses. + +Last generated: 2026-08-16 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e4e0199 --- /dev/null +++ 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 diff --git a/.repo-classification.yaml b/.repo-classification.yaml new file mode 100644 index 0000000..3205797 --- /dev/null +++ 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. diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..2f55397 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,199 @@ +# prj-canon-federation — Agent Instructions + +## Repo Identity + +**Purpose:** 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. + +**Domain:** infotech +**Repo slug:** prj-canon-federation +**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a` +**Workplan prefix:** `PRJ-WP-` + +--- + +## State Hub Integration + +The Custodian State Hub tracks work across all domains. Codex uses HTTP REST and +the `statehub` CLI by default. MCP is opt-in because the current Codex MCP bridge +adds severe call latency; the full administrative MCP surface remains available +to clients that need it. + +| Context | URL | +|---------|-----| +| Local workstation | `http://127.0.0.1:8000` | +| Remote via tunnel | `http://127.0.0.1:18000` | +| Optional local edge relay | http://127.0.0.1:18080 | + +When an operator has enabled the edge relay, set API_BASE to the relay URL. +Queueable writes return an explicit queued receipt if the central hub is +unreachable. Treat that as pending local evidence, then ask the operator to run +statehub outbox status/replay after connectivity returns. + +Codex workspace-write sandboxes need network access enabled to reach the host's +loopback listener. Bootstrap this once with `make -C ~/state-hub configure-codex` +and restart Codex. The canonical REST health endpoint is `/state/health`, not +`/health`. If a sandboxed loopback probe fails, retry it with escalated execution +before declaring State Hub unavailable; a managed Codex permission profile may +still enforce isolated networking. Experimental MCP can be enabled explicitly +with `make -C ~/state-hub configure-codex WITH_MCP=1`. + +### Orient at session start + +```bash +# Offline brief — works without hub connection +cat .custodian-brief.md + +# Active workplans for this domain +curl -s "http://127.0.0.1:8000/workplans/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \ + | python3 -m json.tool + +# Check inbox +curl -s "http://127.0.0.1:8000/messages/?to_agent=prj-canon-federation&unread_only=true" \ + | python3 -m json.tool +``` + +Mark a message read: +```bash +curl -s -X PATCH "http://127.0.0.1:8000/messages//read" \ + -H "Content-Type: application/json" -d '{}' +``` + +### Log progress (required at session close) + +```bash +curl -s -X POST http://127.0.0.1:8000/progress/ \ + -H "Content-Type: application/json" \ + -d '{ + "summary": "what was done", + "event_type": "note", + "author": "codex", + "workplan_id": "", + "task_id": "" + }' +``` + +Omit `workplan_id` / `task_id` when not applicable. + +### Update task status + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"status": "progress"}' +# values: wait | todo | progress | done | cancel +``` + +### Flag a task for human review + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"needs_human": true, "intervention_note": "reason"}' +``` + +--- + +## Session Protocol + +**Start:** +1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) +2. Check inbox: `GET /messages/?to_agent=prj-canon-federation&unread_only=true`; mark read +3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks +4. Check human-needed tasks: `GET /tasks/?needs_human=true` + +**During work:** +- Update task statuses in workplan files as tasks progress +- Record significant decisions via `POST /decisions/` + +**Close:** +1. Update workplan file task statuses to reflect progress +2. If finishing a workplan: hand off **residuals** as live work records first + (intake with `origin: residual` + `origin_ref: `, or a next workplan / + decision / engagement). Do not park leftovers only in prose or `SCOPE.md`. + Canon: `the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals. +3. Log: `POST /progress/` with a summary of what changed (name handoff ids) +4. After workplan file changes, run: + ```bash + statehub fix-consistency + ``` + Coding agents should run this directly; ask the operator only if the CLI or + State Hub API is unavailable. This syncs task status from files into the hub DB. + +--- + +{CREDENTIAL_ROUTING} + + + + +--- + +## Workplan Convention (ADR-001) + +Work items originate as files in this repo — not in the hub. The hub is a +read/cache/index layer that rebuilds from files. + +**File location:** `workplans/PRJ-WP-NNNN-.md` + +**Archived location:** finished workplans may move to +`workplans/archived/YYMMDD-PRJ-WP-NNNN-.md`. The `YYMMDD` prefix is +the completion/archive date; the frontmatter `id` does not change. + +**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use +`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use +this only for low-risk work completed directly; create a normal workplan for +anything needing analysis, design, approval, dependencies, or multiple phases. + +**Frontmatter:** + +```yaml +--- +id: PRJ-WP-NNNN +type: workplan +title: "..." +domain: infotech +repo: prj-canon-federation +status: proposed | ready | active | blocked | backlog | finished | archived +owner: codex +topic_slug: ... +created: "YYYY-MM-DD" +updated: "YYYY-MM-DD" +state_hub_workstream_id: "" # fix-consistency — do not edit (legacy field name; workplan UUID) +--- +``` + +Use `proposed` for a new draft, `ready` after review against current repo +state, and `finished` after implementation. `stalled` and `needs_review` are +derived health labels, not frontmatter statuses. + +**Terminology:** workplan is the fleet term; `workstream` appears only in legacy +API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see +`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`. + +**Task block format** (one per `##` section): + +``` +## Task Title + +` ` `task +id: PRJ-WP-NNNN-T01 +status: wait | todo | progress | done | cancel +priority: high | medium | low +state_hub_task_id: "" # written by fix-consistency — do not edit +` ` ` + +Task description text. +``` + +Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work. + +**Residuals when finishing:** actionable leftovers become live work records +before `status: finished` — usually an intake (`origin: residual`, +`origin_ref: PRJ-WP-NNNN`) or a spawned workplan. Residual is a *role*, +not a kind. Fleet list lives on State Hub, not in `SCOPE.md`. + +To create a new workplan: +1. Write the file following the format above +2. Run `statehub fix-consistency` locally; ask the operator only if the CLI or + State Hub API is unavailable. diff --git a/GOAL.md b/GOAL.md new file mode 100644 index 0000000..d9a3af2 --- /dev/null +++ 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. diff --git a/README.md b/README.md index 236fbd4..0b87fbf 100644 --- 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. \ No newline at end of file +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. diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..b5ef6ad --- /dev/null +++ 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. diff --git a/history/2026-08-16-genesis.md b/history/2026-08-16-genesis.md new file mode 100644 index 0000000..799caf3 --- /dev/null +++ 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. diff --git a/workplans/CFED-WP-0001-foundation.md b/workplans/CFED-WP-0001-foundation.md new file mode 100644 index 0000000..bd545f7 --- /dev/null +++ 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.