107 lines
4.9 KiB
Markdown
107 lines
4.9 KiB
Markdown
|
|
---
|
||
|
|
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.
|