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>
This commit is contained in:
parent
a518497123
commit
45e7e6d352
7 changed files with 517 additions and 1 deletions
227
workplans/CFED-WP-0001-foundation.md
Normal file
227
workplans/CFED-WP-0001-foundation.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue