Mark flex-auth drain-plan row 23 on target

FLEX-WP-0011-T03: runtime already lives on railiance01; coulombcore has
no flex-auth namespace. Wave 7.3 is only an identity-endpoint follow-up.

canon/architecture/adr-006-canon-federation-concept-ownership.md

@@ -0,0 +1,184 @@
+---
+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`

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** | coulombcore | railiance01 | Policy registry follows identity | `flex-auth` | 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** |
 | 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 registry points at new identity endpoints | Credential lanes re-pointed |
+| 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.4 | CCR/applier paths verified | No production secret reads from coulombcore OpenBao |
 
 **Gate:** `CUST-WP-0054-T09` cannot start until Wave 7 completes.