diff --git a/canon/architecture/adr-006-canon-federation-concept-ownership.md b/canon/architecture/adr-006-canon-federation-concept-ownership.md index 733e030..ac0c9ff 100644 --- a/canon/architecture/adr-006-canon-federation-concept-ownership.md +++ b/canon/architecture/adr-006-canon-federation-concept-ownership.md @@ -114,10 +114,13 @@ than identity-owned definitions. `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` · +`Performance Evidence` · `Registry Identifier` · `Proxy Commercial Identifier` · convenience terms `Reputation`, `Customer Account` +*Owned by the evidence model (see Resolution 3):* +`Evidence` · `Evidence Source` · `Adjudication Outcome` + Identifier subtypes demonstrate the intended pattern: `itc-ident` owns `Identifier`; `commerce-canon` owns `Registry Identifier` and `Proxy Commercial Identifier` as specializations of it. @@ -133,26 +136,112 @@ the canon does not push. organizational architecture, human-gated — not commercial vocabulary. If it ever moves, it becomes an InfoTechCanon organization standard, not a CommerceCanon one. -## Open questions +## Resolutions -These are unresolved collisions that must be settled before the affected -concepts move. They are deliberately listed rather than silently decided. +The six collisions listed at draft time, resolved 2026-08-17. Two were settled +by evidence already present in the models rather than by argument. -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`. +**R1 — `Scope`: owned by `itc-ident`.** There is no head-on collision: +`itc-access` owns `ResourceScope` (`:717`, "the boundary within which access +applies"), a narrower concept, not a general `Scope`. `itc-ident` owns the +general concept, keeping it with `Tenant` and `Realm` — `Tenant` is defined as +"an administrative or isolation scope", so separating it from its genus would +split a definition from the concept it depends on. `itc-access` keeps +`ResourceScope` as a refinement. + +If `landscape` or `information-space` later need general scoping, promote +`Scope` to the kernel **on that demand signal**, not pre-emptively. + +**R2 — `Assurance Level`: owned by `itc-ident`, distinct from governance +assurance.** A false collision. `itc-gov` owns `AssuranceCase` (`:1178`, a +structured argument that a claim is justified) and `AssuranceConclusion` +(`:1184`). identity's `Assurance Level` is NIST SP 800-63-4 IAL/AAL/FAL — +graded confidence metadata on credentials, bindings, and federation assertions. +They share an English word and nothing else. Both models carry a disambiguation +note, because the word will keep causing this. + +Design principle P12 ("Distinguish Assurance Dimensions") carries over: IAL, +AAL, and FAL must not be collapsed into a single "trust level" on an account. + +**R3 — `Evidence` and `Evidence Source` are a general pair, owned together, and +not by commerce.** They are not competing definitions of one concept: + +- **Evidence Source** — an addressable information container: a document, file, + or other artifact identifiable by URI. +- **Evidence** — a distinct information item, textual or descriptive, drawn from + a source: a quotation, an extracted value, a specific assertion. + +Both may carry commentary. Which evidence is captured from a source depends on +the interest being served. + +Worked example: an invoice PDF is an Evidence Source; the amount, the issuer, +and the due date are separate Evidence items within it. The common electronic- +invoicing pattern of an XML embedding inside a signed PDF is exactly this +structure — evidence pre-extracted and bound to its source so the extraction is +itself tamper-evident. + +The pair is domain-neutral (it extends to criminal, regulatory, and scientific +evidence). Commerce, identity, and governance all **use** it; none owns it. +Consequently `itc-gov` no longer owns `Evidence`; it imports it. + +**R4 — `Relationship Tuple`: owned by `itc-access`.** Already modelled there +(`:549`, under `PolicyEvaluationEntity` beside `AuthorizationRequest`, +`AuthorizationDecision`, `DecisionReason`, `EvaluationContext`). identity-canon's +own entry agrees: "Relationship tuples are not canonical identity roots. They +project from actors, accounts, memberships, and delegations into authorization +domains." `itc-ident` must not define it. + +**R5 — `Adjudication Outcome`: follows R3, owned with the evidence pair.** Not +`itc-access` `AuthorizationDecision` (a PDP allow/deny, `:907`) and not `itc-gov` +`Decision` (a governance choice point). The concept is general rather than +commercial: an arbitration award, court judgment, or regulatory consent order is +evidence in employment, licensing, or compliance disputes as much as in +commercial ones. Commerce is a consumer, not the owner. + +Structurally it is **Evidence** — the outcome asserted — sourced from an +Evidence Source such as the judgment document. + +The `assurance_tier` dimension splits accordingly: the evidence model owns a +general evidence-strength dimension; `commerce-canon` owns the +`Counterparty Assurance Gradient` as its named four-tier application of it. + +**R6 — `Community` and `Household` extend `itc-org`; `Family` is a separate +concept area.** identity-canon defines "Family Or Household" as one entry. That +conflation is rejected. + +`Community` and `Household` are collective actors and slot under `itc-org`'s +existing `CollectiveActor` (`:363`, beside `Person`, `HumanActor`, +`NonHumanActor`), honouring P4 ("Model Collective Actors Without Collapsing +Them"). + +`Family` does not. Family carries substantial structure — kinship, guardianship, +dependency, care, and legal, biological, and social parenthood — which changes +over time and is subject to interpretation. Modelling it as one more collective +actor is the specific mistake most family-oriented software makes, and it is why +such software generally models families badly. It gets its own concept area. + +Scope discipline applies: the family area is **seeded, not authored**. Record the +concept, the privacy sensitivity already flagged in identity-canon ("may have +legal implications outside the canon's scope"), and the open modelling +questions. Do not build it out inside `CFED-WP-0001`; it grows on demand signal +like any other canon content. + +## Open question + +**Where the evidence pair lives.** R3 and R5 establish *what* is owned together +and that commerce does not own it. The remaining choice is the home: + +1. **A dedicated evidence model** (`itc-evid`) owning `Evidence`, + `Evidence Source`, `Adjudication Outcome`, and the evidence-strength + dimension, imported by `itc-gov`, `itc-ident`, and `commerce-canon`. + Three named consumers already exist, which is a genuine demand signal. + Signals correctly that evidence is not a governance sub-topic. +2. **`itc-gov` keeps both**, as the incumbent owner of `Evidence`. Cheapest, and + preserves the locality of the Policy-Control-Evidence chain pattern + (`:1391`) — but forces identity and commerce to import "governance" to + describe an invoice line item, which mis-signals. + +Recommendation: option 1. ## Consequences