docs(canon): resolve ADR-006 ownership questions R1-R6

R1 Scope -> itc-ident (itc-access keeps narrower ResourceScope).
R2 Assurance Level -> itc-ident, distinct from governance AssuranceCase.
R3 Evidence + Evidence Source are a general pair (container vs extracted
   assertion), owned together, not by commerce; itc-gov no longer owns
   Evidence.
R4 Relationship Tuple -> itc-access (already modelled there).
R5 Adjudication Outcome follows R3; general, not commerce-owned.
   assurance_tier splits: general strength dimension vs commerce's named
   Counterparty Assurance Gradient.
R6 Community + Household extend itc-org CollectiveActor; Family rejected as
   a collective actor and given its own seeded concept area.

One open question remains: the home for the evidence pair (dedicated
itc-evid model vs itc-gov incumbency). Recommendation: dedicated model.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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