diff --git a/canon/architecture/adr-006-canon-federation-concept-ownership.md b/canon/architecture/adr-006-canon-federation-concept-ownership.md deleted file mode 100644 index 733e030..0000000 --- a/canon/architecture/adr-006-canon-federation-concept-ownership.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -id: ADR-006 -type: architecture-decision-record -title: "Canon Federation and Concept Ownership Across InfoTech and Commerce" -status: proposed -decided_by: Bernd Worsch -date: "2026-08-16" -tags: ["architecture", "canon", "concept-ownership", "info-tech-canon", "commerce-canon", "identity", "orthogonality"] ---- - -# ADR-006: Canon Federation and Concept Ownership Across InfoTech and Commerce - -## Status - -Proposed. Canon changes are review-gated; this ADR is the review artifact for -the identity/commerce split and must be accepted before content moves. - -## Context - -The ecosystem currently runs two independent canons in the same market domain -(`infotech`), with **no cross-reference in either direction**: - -- `info-tech-canon` — InfoTechCanon, v0.6.0, status `service-baseline`. Kernel + - 12 models + 3 standards, with declared concept ownership per model, an - orthogonality rule ("standards can import but not redefine each other"), and a - live CLI/JSON/API surface built on `infospace-bench`. -- `identity-canon` — documentation-only research repo, category `research`. Three - `IDENTITY-WP-*` workplans, all `finished`; no active work since the - commercial-identity research pass. ~60 concepts in - `canon/CanonicalGlossary.md`. - -Two problems follow. - -**Concept-ownership collision.** `InfoTechCanonOrganizationModel` (`:55`) -declares ownership of `Actor, Person, Organization, OrganizationalUnit, Team, -Group, Role, Position, Membership, Assignment, Responsibility, Authority, -Accountability`. `InfoTechCanonAccessControlModel` (`:106`) declares `Subject, -Principal, AccessRole, Permission, ...`. identity-canon independently defines -`Actor, Natural Person, Collective Actor, Organization, Group, Role, Membership -Relationship, Authenticated Subject, Authorization Principal`. Two canons claim -the same concepts — exactly what InfoTechCanon's orthogonality rule exists to -prevent. - -**An unowned gap.** `InfoTechCanonAccessControlModel` (`:214`, "Boundary with -Identity and Authentication") explicitly pushes identity provisioning, -authentication factors, 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, Assurance Level` belong to no model at all. - -**Business semantics are accumulating in the wrong places.** Roughly a third of -identity-canon's glossary is not identity but counterparty/commercial modelling -(`Legal Entity, Beneficial Owner, Customer, Vendor, Commercial Commitment, -Payment Mandate, Pipeline Pursuit, Counterparty Assurance Gradient, ...`) — -hence the repo's `government` secondary domain. Independently, -`info-tech-canon/demand/CapabilityProvisionEconomics.md` (status `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 technical canon is a domain boundary, not a -coincidence. InfoTechCanon's own Purpose/Demand extension names this -`ScopePressure`. - -## Decision - -**1. Three canons, federated by declared ownership.** - -| Canon | Owns | Repo | -|---|---|---| -| Custodian canon | ecosystem-normative governance: constitution, values, standards, ADRs, charters | `the-custodian/canon/` | -| InfoTechCanon | semantics of information-processing systems | `info-tech-canon` | -| CommerceCanon | counterparty and commercial-relationship semantics | `commerce-canon` | - -Canons import but do not redefine each other's concepts, applying InfoTechCanon's -existing orthogonality rule one level up. - -**2. `identity-canon` is renamed to `commerce-canon`, in place.** Git history, -State Hub registration, `.repo-classification.yaml`, and the finished -`IDENTITY-WP-*` workplans are retained as provenance for the commercial content -that stays. Identity content emigrates; nothing is archived. Structure follows -`info-tech-canon` (`canon.yaml`, `infospace/` with kernel/models/standards, -`assimilation/`, `mappings/`, `profiles/`) per -`InfoTechCanonRepositoryLayoutStandard`. - -**3. Identity becomes an InfoTechCanon model**, at -`infospace/models/identity/InfoTechCanonIdentityModel.md` (`itc-ident`), -importing rather than redefining upstream concepts. This fills the gap -`InfoTechCanonAccessControlModel:214` leaves open. - -**4. Concept ownership is assigned as follows.** - -*Imported by `itc-ident`, owned by `itc-org`:* -`Actor` · `Natural Person` → `Person` · `Artificial Agent` → `Agent` · -`Organization` · `Group` · `Role` · `Membership Relationship` → `Membership` - -*Imported by `itc-ident`, owned by `itc-access`:* -`Authenticated Subject` → `Subject` · `Authorization Principal` → `Principal` - -This follows identity-canon's own design principles: P1 makes `Actor` the -participation root (owned upstream by `itc-org`), and P6 "Keep Authorization -Projections Separate" already treats subject/principal as projections rather -than identity-owned definitions. - -*Owned by `itc-ident` (new):* -`Account` · `Service Account` · `Identity Record` · `Identifier` · -`Scoped Identifier` · `Pseudonymous Identifier` · `Credential` · `Claim` · -`Profile` · `Persona` · `Tenant` · `Realm` · `Synonymity Assertion` · -`Lifecycle State` · the actor-linking relationship taxonomy -(`Relationship`, `Affiliation`, `Following`, `Representation`, `Delegation`, -`Administration`, `Trust`) · convenience terms `User`, `Subscriber` - -*Owned by `commerce-canon`:* -`Legal Entity` · `Legal Person` · `Beneficial Owner` · -`Beneficial Ownership Relationship` · `Beneficial Ownership Exemption` · -`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` · convenience terms `Reputation`, -`Customer Account` - -Identifier subtypes demonstrate the intended pattern: `itc-ident` owns -`Identifier`; `commerce-canon` owns `Registry Identifier` and `Proxy Commercial -Identifier` as specializations of it. - -**5. CommerceCanon grows by demand signal, not speculative authoring.** New -content enters through the mechanism InfoTechCanon already runs — a demand -signal with named consumer evidence (see `demand/`). Plausible future consumers -(`fin-hub`, `target-revenue`, `adaptive-pricing`, `qonto-assistant`) must pull; -the canon does not push. - -**6. The Federated Organization Standard stays in Custodian canon.** -`canon/standards/federated-organization-standard_v1.0.md` is ecosystem-normative -organizational architecture, human-gated — not commercial vocabulary. If it ever -moves, it becomes an InfoTechCanon organization standard, not a CommerceCanon one. - -## Open questions - -These are unresolved collisions that must be settled before the affected -concepts move. They are deliberately listed rather than silently decided. - -1. **`Scope`.** identity-canon P3 makes it first-class; `itc-access` uses "access - scope" throughout. Does `itc-ident` own `Scope` with `itc-access` importing, - or the reverse? -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 an identity-owned concept. -4. **`Relationship Tuple`.** A Zanzibar/OpenFGA-style authorization primitive — - plausibly `itc-access`, not `itc-ident`. -5. **`Adjudication Outcome` vs `itc-access` `AuthorizationDecision` and `itc-gov` - `Decision`.** Three candidate owners. -6. **`Community`, `Family Or Household`.** Social collectives absent from - `itc-org`, which covers enterprise structures (`Team`, `Group`, - `OrganizationalUnit`). Recommend extending `itc-org` rather than placing them - in `itc-ident`. - -## Consequences - -**Positive.** Every concept gains exactly one owner. The identity gap that -`itc-access` explicitly declines is filled. Commercial semantics get a home -before they accrete further into technical canon. A dormant research repo with -no inbound references becomes a canon with declared consumers. A second canon -tests whether `InfoTechCanonRepositoryLayoutStandard` is a real standard or -merely InfoTechCanon's own shape described back to itself. - -**Negative.** This is a concept-ownership reconciliation, not a file move: the -first ~15 glossary entries must be rewritten as imports. Three canons cost more -coordination than one. The `identity-canon` name disappears from tooling, -bookmarks, and any external reference. - -**Risks.** CommerceCanon could repeat identity-canon's failure mode — dormant, -zero consumers, drifting — if it launches as a scaffold. Mitigated by decision 2 -(it opens holding real, research-backed content) and decision 5 (growth requires -consumer evidence). - -## References - -- ADR-001 — workplans originate as repo files; hub is a read model -- ADR-005 — cross-repo workplans live in dedicated project repos -- `info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md:55` -- `info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md:106`, `:214` -- `info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md:107` -- `info-tech-canon/demand/CapabilityProvisionEconomics.md` -- `identity-canon/canon/CanonicalGlossary.md`, `canon/DesignPrinciples.md` diff --git a/docs/coulombcore-drain-placement-plan.md b/docs/coulombcore-drain-placement-plan.md index 436e5be..a6eaa2f 100644 --- a/docs/coulombcore-drain-placement-plan.md +++ b/docs/coulombcore-drain-placement-plan.md @@ -54,7 +54,7 @@ Wave 8 coulombcore phoenix → railiance02 ─── CUST-WP-0054-T09 | 20 | **Authelia** | coulombcore | railiance01 | Identity front door | `key-cape` / `railiance-platform` | 7 | grandfathered | | 21 | **privacyIDEA** | coulombcore | railiance01 | MFA backend | `key-cape` | 7 | grandfathered | | 22 | **lldap** | coulombcore | railiance01 | LDAP directory | `key-cape` / `railiance-platform` | 7 | grandfathered | -| 23 | **flex-auth** | railiance01 `flex-auth` ns | railiance01 (retain) | Host drain complete 2026-08-16 (`FLEX-WP-0011-T03`): runtime already on railiance01; coulombcore has no `flex-auth` namespace or Deployments. Identity-endpoint follow-up stays with Wave 7 if KeyCape/OpenBao move. | `FLEX-WP-0011` | — | **on target** | +| 23 | **flex-auth** | coulombcore | railiance01 | Policy registry follows identity | `flex-auth` | 7 | grandfathered | | 24 | **Fleet mesh transit tunnels** | railiance01 systemd → coulombcore ClusterIPs | railiance01-local services | Retire when Waves 2+4 complete (hub + issue-core local) | `CUST-WP-0054-T02` | 2–4 | **interim active** | | 25 | **CNPG operator** | coulombcore (boundary note) | railiance01 | Platform operator moves with Wave 2+ workloads | `railiance-platform` | 2–7 | grandfathered | | 26 | **coulombcore host identity** | coulombcore | railiance02 | Machine phoenix after Wave 7 | `CUST-WP-0054-T09`, `CUST-WP-0054-T08` | 8 | wait | @@ -146,7 +146,7 @@ Each uses staged-promotion unless listed under **Documented exceptions**. | --- | --- | --- | | 7.1 | OpenBao staged-promotion to railiance01 | Unseal automation (`NET-WP-0020`) proven | | 7.2 | KeyCape / Authelia / privacyIDEA / lldap migration | OIDC login smoke on railiance01 | -| 7.3 | flex-auth identity-endpoint re-point after OpenBao/KeyCape move | Host drain is done (row 23 **on target**, 2026-08-16). Remaining work is only if Wave 7 identity issuers change; there is no coulombcore flex-auth left to migrate. | +| 7.3 | flex-auth registry points at new identity endpoints | Credential lanes re-pointed | | 7.4 | CCR/applier paths verified | No production secret reads from coulombcore OpenBao | **Gate:** `CUST-WP-0054-T09` cannot start until Wave 7 completes.