coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md
codex 56044d63ab docs(canon): ADR-006 canon federation and concept ownership (proposed) 
Proposes three federated canons (Custodian, InfoTech, Commerce) with
declared concept ownership. Renames identity-canon to commerce-canon in
place; identity content emigrates to a new InfoTechCanon model.

Assigns all ~60 identity-canon glossary concepts to exactly one owner and
lists six unresolved collisions as open questions rather than deciding
them silently.

Status is proposed — canon changes are review-gated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 02:30:42 +02:00

9.3 KiB
Raw Blame History

id type title status decided_by date tags
ADR-006 architecture-decision-record Canon Federation and Concept Ownership Across InfoTech and Commerce proposed Bernd Worsch 2026-08-16
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