coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Distribute frozen federation corpus by concept destination
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
tegwick 2026-09-06 00:44:37 +02:00
parent 3e3191549a
commit 372f671eef
81 changed files with 14146 additions and 99 deletions
Download patch file Download diff file Expand all files Collapse all files

7
CHANGELOG.md
View file

@ -344,3 +344,10 @@ relationships, 0 consistency cycles, coverage 1.0, redundancy 0.0).
Seed kernel: kernel documents, eleven domain models, three standards, the
infospace scaffold, service surface (CLI / JSON / API), generated views and
agent briefs. See `workplans/` ITC-WP-0001 through ITC-WP-0012 for the history.
## 0.11.1 — 2026-09-06
Change: register observed canon-federation research provenance and generated
reading indexes (INFO-WP-0024 / CFED T07). Rationale: preserve source context and
make destination evidence traceable. No concept or identifier changes; no source
claims promoted. Supersedes no frozen input. Review on a revised source intake.

4
WORK-RECORDS.md
View file

@ -14,6 +14,7 @@
| workplan | INFO-WP-0021 | finished | — | workplans/INFO-WP-0021-identity-model.md |
| workplan | INFO-WP-0022 | finished | — | workplans/INFO-WP-0022-social-collectives.md |
| workplan | INFO-WP-0023 | finished | — | workplans/INFO-WP-0023-family-seed.md |
| workplan | INFO-WP-0024 | finished | — | workplans/INFO-WP-0024-corpus-provenance.md |
| workplan | ITC-WP-0001 | finished | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md |
| workplan | ITC-WP-0002 | finished | — | workplans/ITC-WP-0002-service-surface-cli-json-api.md |
| workplan | ITC-WP-0003 | finished | — | workplans/ITC-WP-0003-validation-indexes-and-generated-views.md |
@ -52,6 +53,9 @@
| task | INFO-WP-0022-T03 | done | — | workplans/INFO-WP-0022-social-collectives.md |
| task | INFO-WP-0023-T01 | done | — | workplans/INFO-WP-0023-family-seed.md |
| task | INFO-WP-0023-T02 | done | — | workplans/INFO-WP-0023-family-seed.md |
| task | INFO-WP-0024-T01 | done | — | workplans/INFO-WP-0024-corpus-provenance.md |
| task | INFO-WP-0024-T02 | done | — | workplans/INFO-WP-0024-corpus-provenance.md |
| task | INFO-WP-0024-T03 | done | — | workplans/INFO-WP-0024-corpus-provenance.md |
| task | ITC-WP-0001-T01 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md |
| task | ITC-WP-0001-T02 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md |
| task | ITC-WP-0001-T03 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md |

7
canon.yaml
View file

@ -1,7 +1,7 @@
repository: info-tech-canon
title: InfoTechCanon
status: service-baseline
version: 0.11.0
version: 0.11.1
description: >
An evolving, markdown-first canon for building interoperable, adaptable,
and extensible information-processing systems.
@ -192,6 +192,11 @@ assimilation:
practice: infospace/assimilation/intake-and-assimilation-practice.md
intake_dir: incoming/
records:
- id: assimilation/canon-federation
source: Completed identity-canon research corpus
disposition: observe
status: closed
path: infospace/assimilation/canon-federation/
- id: assimilation/it-capability-canon
source: Information Technology Capability Canon (ITCC) v0.1
disposition: adapt

4
infospace/agent/global-agent-brief.md
View file

@ -5,8 +5,8 @@
This brief summarizes the current canon service surface for agents.
- Infospace slug: `canon`
- Artifact count: 79
- Retrieval index items: 79
- Artifact count: 80
- Retrieval index items: 80
- Primary confidence command: `make validate`
- Refresh generated indexes and views with: `make index`
- Refresh agent briefs and interface templates with: `make agent-briefs`

43
infospace/agent/retrieval-index.json
View file

@ -60,8 +60,49 @@
}
],
"infospace": "canon",
"item_count": 79,
"item_count": 80,
"items": [
{
"canonical_path": "assimilation/canon-federation/ASSIMILATION.md",
"id": "assimilation/canon-federation",
"imports": [
"concept-area/family",
"model/access-control",
"model/evidence",
"model/identity",
"model/organization"
],
"kind": "assimilation",
"owned_concepts": [
"Canon federation research provenance"
],
"relationships": [
{
"target": "model/identity",
"type": "uses"
},
{
"target": "model/evidence",
"type": "uses"
},
{
"target": "model/organization",
"type": "uses"
},
{
"target": "model/access-control",
"type": "uses"
},
{
"target": "concept-area/family",
"type": "uses"
}
],
"source_path": "infospace/assimilation/canon-federation/source/research/CorpusIndex.md",
"summary": "Canon artifact: Canon federation research provenance.",
"title": "Canon federation research provenance",
"warnings": []
},
{
"canonical_path": "assimilation/emission-cadence/ASSIMILATION.md",
"id": "assimilation/emission-cadence",

12
infospace/agent/retrieval-index.md
View file

@ -4,7 +4,7 @@
Schema: `info-tech-canon.retrieval-index.v1`
Infospace: `canon`
Items: **79**
Items: **80**
## Common Distinctions
@ -17,6 +17,16 @@ Items: **79**
## Items
### Canon federation research provenance
- ID: `assimilation/canon-federation`
- Kind: `assimilation`
- Canonical path: `assimilation/canon-federation/ASSIMILATION.md`
- Source path: `infospace/assimilation/canon-federation/source/research/CorpusIndex.md`
- Summary: Canon artifact: Canon federation research provenance.
- Imports and anchors: `concept-area/family`, `model/access-control`, `model/evidence`, `model/identity`, `model/organization`
- Owned concepts: `Canon federation research provenance`
### Assimilation — EmissionCadenceDeclaration handover
- ID: `assimilation/emission-cadence`

28
infospace/agent/retrieval-index.yaml
View file

@ -1,7 +1,33 @@
schema: info-tech-canon.retrieval-index.v1
infospace: canon
item_count: 79
item_count: 80
items:
- id: assimilation/canon-federation
kind: assimilation
title: Canon federation research provenance
canonical_path: assimilation/canon-federation/ASSIMILATION.md
source_path: infospace/assimilation/canon-federation/source/research/CorpusIndex.md
summary: 'Canon artifact: Canon federation research provenance.'
owned_concepts:
- Canon federation research provenance
imports:
- concept-area/family
- model/access-control
- model/evidence
- model/identity
- model/organization
relationships:
- type: uses
target: model/identity
- type: uses
target: model/evidence
- type: uses
target: model/organization
- type: uses
target: model/access-control
- type: uses
target: concept-area/family
warnings: []
- id: assimilation/emission-cadence
kind: assimilation
title: "Assimilation \u2014 EmissionCadenceDeclaration handover"

19
infospace/artifacts/index.yaml
View file

@ -1,4 +1,23 @@
artifacts:
- id: assimilation/canon-federation
path: assimilation/canon-federation/ASSIMILATION.md
kind: assimilation
title: Canon federation research provenance
provenance:
source_path: infospace/assimilation/canon-federation/source/research/CorpusIndex.md
placement: observed
placement_workplan: INFO-WP-0024
relationships:
- type: uses
target: model/identity
- type: uses
target: model/evidence
- type: uses
target: model/organization
- type: uses
target: model/access-control
- type: uses
target: concept-area/family
- id: concept-area/family
path: concepts/family/FamilySeed.md
kind: concept-area-seed

40
infospace/assimilation/canon-federation/ASSIMILATION.md Normal file
View file

@ -0,0 +1,40 @@
# Canon federation research provenance
Status: closed provenance distribution. Disposition: observe. Native workplan:
INFO-WP-0024; project task CFED-WP-0001-T07. These are historical research inputs,
not newly adopted definitions or evidence that external sources are current.
## Context and decision
Accepted ADR-006 assigns concept destinations and the user authorized continuing
the migration. T07 routes already-completed research; it does not rerun research
or open a new domain-concept adoption decision. Preserve immutable source copies
and route shared material through model-specific indexes and exact fragments.
Source repository: commerce-canon, commit `8a07292dd78d094151f165d3ac1dfc7512114308`.
Options considered: moving originals would break historical references; rewriting
old assertions would destroy provenance; copying without destination indexes would
hide the split. The chosen layout retains originals and copies frozen snapshots,
with SHA-256 records and destination-specific reading views.
## Scope and consequences
45 source files are present here, including their complete context.
[distribution.json](distribution.json) records source paths, hashes, applicable
models and exact fragment line ranges. [source-summary](source-summary.md) lists
the corpus areas. [comparison-matrix](comparison-matrix.md) applies the existing
ownership ledger. [mappings.yaml](mappings.yaml) records the authoritative donor
term destinations; it is a migration mapping, not a new external-vocabulary model.
Views under views/ partition the shared terminology rows, conflict sections and
scenario sections by destination interest. Each fragment is verbatim, with its
source locator and a warning that current canon takes precedence. Model indexes
link full source notes without removing context. A shared source copy does not
create a second concept owner. Source files are never runtime normative artifacts.
## Review trigger
A revised external source is a new intake; do not edit these snapshots. Any new
concept or behavior proposed from the corpus requires its own review. Historical
open questions remain historical; current unresolved work is linked in
[open-questions.md](open-questions.md). No new domain definition is adopted here.

10
infospace/assimilation/canon-federation/README.md Normal file
View file

@ -0,0 +1,10 @@
# Research provenance entry point
Read [ASSIMILATION.md](ASSIMILATION.md) before using historical sources.
- [itc-ident](views/itc-ident.md)
- [itc-org](views/itc-org.md)
- [itc-access](views/itc-access.md)
- [itc-gov](views/itc-gov.md)
- [itc-evid](views/itc-evid.md)
- [family-area](views/family-area.md)

61
infospace/assimilation/canon-federation/assimilation.yaml Normal file
View file

@ -0,0 +1,61 @@
id: assimilation/canon-federation
title: Canon federation research provenance
source: identity-canon historical research corpus via commerce-canon
source_version: 8a07292dd78d094151f165d3ac1dfc7512114308
source_type: completed-internal-research
source_files:
- source/research/CorpusIndex.md
- source/research/README.md
- source/research/ResearchSeed.md
- source/research/authentication-federation/nist-800-63-4.md
- source/research/authentication-federation/oidc-core-subject-identifiers.md
- source/research/authentication-federation/saml-nameid-federation.md
- source/research/authentication-federation/shared-signals-caep-risc.md
- source/research/authorization-relationships/cedar-principal-action-resource-context.md
- source/research/authorization-relationships/cerbos-abac-derived-roles.md
- source/research/authorization-relationships/openfga-modeling.md
- source/research/authorization-relationships/zanzibar-rebac.md
- source/research/commercial-identity/beneficial-ownership-kyc-boi.md
- source/research/commercial-identity/commercial-identity-nuance-settlement.md
- source/research/commercial-identity/commercial-identity-synthesis.md
- source/research/commercial-identity/commercial-trust-binding-theory.md
- source/research/commercial-identity/crm-pipeline-commitment-threshold.md
- source/research/commercial-identity/duns-commercial-credit-identity.md
- source/research/commercial-identity/eidas-eudi-legal-person-wallet.md
- source/research/commercial-identity/kyc-aml-commercial-identity-binding.md
- source/research/commercial-identity/legal-person-agency-contract.md
- source/research/commercial-identity/lei-gleif-legal-entity-identifier.md
- source/research/commercial-identity/payment-credential-pci-boundary.md
- source/research/commercial-identity/registry-identifier-subtypes.md
- source/research/commercial-identity/reputation-assurance-gradient.md
- source/research/commercial-identity/salesforce-crm-commercial-record.md
- source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md
- source/research/commercial-subscription/stripe-customer-billing.md
- source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md
- source/research/entity-resolution-privacy/gdpr-pseudonymization.md
- source/research/entity-resolution-privacy/synonymity-assertions.md
- source/research/identity-provisioning/keycloak-organizations.md
- source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md
- source/research/identity-provisioning/ory-kratos-keto.md
- source/research/identity-provisioning/scim-rfc7643-rfc7644.md
- source/research/identity-provisioning/zitadel-organizations-projects.md
- source/research/social-community-graphs/activitypub-actors-followers.md
- source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md
- source/research/social-community-graphs/schema-org-person-organization-membership.md
- source/research/social-community-graphs/webid-solid-profile.md
- source/research/verifiable-claims/did-core.md
- source/research/verifiable-claims/openid4vc.md
- source/research/verifiable-claims/vc-data-model-2.md
- source/scenarios/ScenarioTests.md
- source/terminology/TerminologyConflictMap.md
- source/terminology/TerminologyInventory.md
status: closed
disposition: observe
impacts:
- itc-ident
- itc-org
- itc-access
- itc-gov
- itc-evid
- family-area
workplan: INFO-WP-0024

67
infospace/assimilation/canon-federation/comparison-matrix.md Normal file
View file

@ -0,0 +1,67 @@
# Comparison with current canon
Existing approved migration assignments are reused; historical wording is not
promoted by being copied. Family remains seeded only.
| Donor concept | Current destination | Classification |
| --- | --- | --- |
| Actor | itc-org: Actor | covered_differently |
| Natural Person | itc-org: Person | covered_differently |
| Artificial Agent | itc-org: Agent | covered_differently |
| Collective Actor | itc-org: CollectiveActor | covered_differently |
| Account | itc-ident: Account | already_covered |
| Service Account | itc-ident: Service Account | already_covered |
| Identity Record | itc-ident: Identity Record | already_covered |
| Identifier | itc-ident: Identifier | already_covered |
| Registry Identifier | counterparty: Registry Identifier | already_covered |
| Proxy Commercial Identifier | counterparty: Proxy Commercial Identifier | already_covered |
| Scoped Identifier | itc-ident: Scoped Identifier | already_covered |
| Credential | itc-ident: Credential | already_covered |
| Claim | itc-ident: Claim | already_covered |
| Authenticated Subject | itc-access: Subject | covered_differently |
| Authorization Principal | itc-access: Principal | covered_differently |
| Profile | itc-ident: Profile | already_covered |
| Persona | itc-ident: Persona | already_covered |
| Scope | itc-ident: Scope | already_covered |
| Tenant | itc-ident: Tenant | already_covered |
| Realm | itc-ident: Realm | already_covered |
| Organization | itc-org: Organization | covered_differently |
| Legal Entity | counterparty: Legal Entity | already_covered |
| Legal Person | counterparty: Legal Person | already_covered |
| Beneficial Owner | counterparty: Beneficial Owner | already_covered |
| Beneficial Ownership Relationship | counterparty: Beneficial Ownership Relationship | already_covered |
| Beneficial Ownership Exemption | counterparty: Beneficial Ownership Exemption | covered_differently |
| Customer | counterparty: Customer | already_covered |
| Vendor | counterparty: Vendor | already_covered |
| Commercial Relationship | counterparty: Commercial Relationship | already_covered |
| Commercial Commitment | counterparty: Commercial Commitment | already_covered |
| Payment Instrument Reference | counterparty: Payment Instrument Reference | already_covered |
| Payment Mandate | counterparty: Payment Mandate | already_covered |
| Pipeline Pursuit | counterparty: Pipeline Pursuit | already_covered |
| Commercial Record | counterparty: Commercial Record | already_covered |
| Community | itc-org: Community | covered_differently |
| Family Or Household | itc-org: Household; family-area: Family | covered_differently |
| Group | itc-org: Group | covered_differently |
| Role | itc-org: Role | covered_differently |
| Relationship | itc-ident: Relationship | already_covered |
| Membership Relationship | itc-org: Membership | covered_differently |
| Affiliation Relationship | itc-ident: Affiliation Relationship | already_covered |
| Following Relationship | itc-ident: Following Relationship | already_covered |
| Representation Relationship | itc-ident: Representation Relationship | already_covered |
| Delegation Relationship | itc-ident: Delegation Relationship | covered_differently |
| Administration Relationship | itc-ident: Administration Relationship | already_covered |
| Trust Relationship | itc-ident: Trust Relationship | already_covered |
| Synonymity Assertion | itc-ident: Synonymity Assertion | already_covered |
| Evidence Source | itc-evid: Evidence Source | covered_differently |
| Counterparty Assurance Gradient | counterparty: Counterparty Assurance Gradient | already_covered |
| Reputation Signal | counterparty: Reputation Signal | covered_differently |
| Performance Evidence | counterparty: Performance Evidence | covered_differently |
| Adjudication Outcome | itc-evid: Adjudication Outcome | covered_differently |
| Non-Canonical Convenience Term: Reputation | counterparty: Reputation | already_covered |
| Lifecycle State | itc-ident: Lifecycle State | already_covered |
| Assurance Level | itc-ident: Assurance Level | already_covered |
| Relationship Tuple | itc-access: Relationship Tuple | covered_differently |
| Pseudonymous Identifier | itc-ident: Pseudonymous Identifier | already_covered |
| Non-Canonical Convenience Term: User | itc-ident: User | already_covered |
| Non-Canonical Convenience Term: Subscriber | itc-ident: Subscriber | already_covered |
| Non-Canonical Convenience Term: Customer Account | counterparty: Customer Account | already_covered |

3247
infospace/assimilation/canon-federation/distribution.json Normal file
View file

File diff suppressed because it is too large Load diff

429
infospace/assimilation/canon-federation/extracted-concepts.yaml Normal file
View file

@ -0,0 +1,429 @@
extraction_basis: Existing donor glossary and federation ledger; research product
terms remain candidate mappings in frozen sources.
source_revision: 4bb474970b73d500da03b6482e84e6c256146b79
entries:
- source_term: Actor
destinations:
- concept: Actor
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Natural Person
destinations:
- concept: Person
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Artificial Agent
destinations:
- concept: Agent
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Collective Actor
destinations:
- concept: CollectiveActor
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Account
destinations:
- concept: Account
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Service Account
destinations:
- concept: Service Account
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Identity Record
destinations:
- concept: Identity Record
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Identifier
destinations:
- concept: Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Registry Identifier
destinations:
- concept: Registry Identifier
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Proxy Commercial Identifier
destinations:
- concept: Proxy Commercial Identifier
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Scoped Identifier
destinations:
- concept: Scoped Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Credential
destinations:
- concept: Credential
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Claim
destinations:
- concept: Claim
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Authenticated Subject
destinations:
- concept: Subject
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Authorization Principal
destinations:
- concept: Principal
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Profile
destinations:
- concept: Profile
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Persona
destinations:
- concept: Persona
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Scope
destinations:
- concept: Scope
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Tenant
destinations:
- concept: Tenant
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Realm
destinations:
- concept: Realm
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Organization
destinations:
- concept: Organization
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Legal Entity
destinations:
- concept: Legal Entity
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Legal Person
destinations:
- concept: Legal Person
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Owner
destinations:
- concept: Beneficial Owner
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Ownership Relationship
destinations:
- concept: Beneficial Ownership Relationship
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Ownership Exemption
destinations:
- concept: Beneficial Ownership Exemption
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Customer
destinations:
- concept: Customer
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Vendor
destinations:
- concept: Vendor
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Relationship
destinations:
- concept: Commercial Relationship
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Commitment
destinations:
- concept: Commercial Commitment
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Payment Instrument Reference
destinations:
- concept: Payment Instrument Reference
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Payment Mandate
destinations:
- concept: Payment Mandate
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Pipeline Pursuit
destinations:
- concept: Pipeline Pursuit
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Record
destinations:
- concept: Commercial Record
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Community
destinations:
- concept: Community
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Family Or Household
destinations:
- concept: Household
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- concept: Family
kind: seed
owner:
canon: info-tech-canon
model: family-area
- source_term: Group
destinations:
- concept: Group
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Role
destinations:
- concept: Role
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Relationship
destinations:
- concept: Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Membership Relationship
destinations:
- concept: Membership
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Affiliation Relationship
destinations:
- concept: Affiliation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Following Relationship
destinations:
- concept: Following Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Representation Relationship
destinations:
- concept: Representation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Delegation Relationship
destinations:
- concept: Delegation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Administration Relationship
destinations:
- concept: Administration Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Trust Relationship
destinations:
- concept: Trust Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Synonymity Assertion
destinations:
- concept: Synonymity Assertion
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Evidence Source
destinations:
- concept: Evidence Source
kind: concept
owner:
canon: info-tech-canon
model: itc-evid
- source_term: Counterparty Assurance Gradient
destinations:
- concept: Counterparty Assurance Gradient
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Reputation Signal
destinations:
- concept: Reputation Signal
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Performance Evidence
destinations:
- concept: Performance Evidence
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Adjudication Outcome
destinations:
- concept: Adjudication Outcome
kind: concept
owner:
canon: info-tech-canon
model: itc-evid
- source_term: 'Non-Canonical Convenience Term: Reputation'
destinations:
- concept: Reputation
kind: convenience_term
owner:
canon: commerce-canon
model: counterparty
- source_term: Lifecycle State
destinations:
- concept: Lifecycle State
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Assurance Level
destinations:
- concept: Assurance Level
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Relationship Tuple
destinations:
- concept: Relationship Tuple
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Pseudonymous Identifier
destinations:
- concept: Pseudonymous Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: User'
destinations:
- concept: User
kind: convenience_term
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: Subscriber'
destinations:
- concept: Subscriber
kind: convenience_term
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: Customer Account'
destinations:
- concept: Customer Account
kind: convenience_term
owner:
canon: commerce-canon
model: counterparty

488
infospace/assimilation/canon-federation/mappings.yaml Normal file
View file

@ -0,0 +1,488 @@
authority: CUST-ADR-006 accepted-1 (2026-08-17)
status: provenance-mapping
entries:
- source_term: Actor
disposition: import
targets:
- concept: Actor
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Natural Person
disposition: import
targets:
- concept: Person
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Artificial Agent
disposition: import
targets:
- concept: Agent
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Collective Actor
disposition: import
targets:
- concept: CollectiveActor
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Account
disposition: own
targets:
- concept: Account
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Service Account
disposition: own
targets:
- concept: Service Account
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Identity Record
disposition: own
targets:
- concept: Identity Record
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Identifier
disposition: own
targets:
- concept: Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Registry Identifier
disposition: own
targets:
- concept: Registry Identifier
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Proxy Commercial Identifier
disposition: own
targets:
- concept: Proxy Commercial Identifier
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Scoped Identifier
disposition: own
targets:
- concept: Scoped Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Credential
disposition: own
targets:
- concept: Credential
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Claim
disposition: own
targets:
- concept: Claim
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Authenticated Subject
disposition: import
targets:
- concept: Subject
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Authorization Principal
disposition: import
targets:
- concept: Principal
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Profile
disposition: own
targets:
- concept: Profile
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Persona
disposition: own
targets:
- concept: Persona
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Scope
disposition: own
targets:
- concept: Scope
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Tenant
disposition: own
targets:
- concept: Tenant
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Realm
disposition: own
targets:
- concept: Realm
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Organization
disposition: import
targets:
- concept: Organization
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Legal Entity
disposition: own
targets:
- concept: Legal Entity
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Legal Person
disposition: own
targets:
- concept: Legal Person
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Owner
disposition: own
targets:
- concept: Beneficial Owner
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Ownership Relationship
disposition: own
targets:
- concept: Beneficial Ownership Relationship
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Beneficial Ownership Exemption
disposition: own
targets:
- concept: Beneficial Ownership Exemption
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Customer
disposition: own
targets:
- concept: Customer
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Vendor
disposition: own
targets:
- concept: Vendor
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Relationship
disposition: own
targets:
- concept: Commercial Relationship
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Commitment
disposition: own
targets:
- concept: Commercial Commitment
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Payment Instrument Reference
disposition: own
targets:
- concept: Payment Instrument Reference
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Payment Mandate
disposition: own
targets:
- concept: Payment Mandate
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Pipeline Pursuit
disposition: own
targets:
- concept: Pipeline Pursuit
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Commercial Record
disposition: own
targets:
- concept: Commercial Record
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Community
disposition: import
targets:
- concept: Community
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Family Or Household
disposition: split
targets:
- concept: Household
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- concept: Family
kind: seed
owner:
canon: info-tech-canon
model: family-area
- source_term: Group
disposition: import
targets:
- concept: Group
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Role
disposition: import
targets:
- concept: Role
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Relationship
disposition: own
targets:
- concept: Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Membership Relationship
disposition: import
targets:
- concept: Membership
kind: concept
owner:
canon: info-tech-canon
model: itc-org
- source_term: Affiliation Relationship
disposition: own
targets:
- concept: Affiliation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Following Relationship
disposition: own
targets:
- concept: Following Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Representation Relationship
disposition: own
targets:
- concept: Representation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Delegation Relationship
disposition: own
targets:
- concept: Delegation Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Administration Relationship
disposition: own
targets:
- concept: Administration Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Trust Relationship
disposition: own
targets:
- concept: Trust Relationship
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Synonymity Assertion
disposition: own
targets:
- concept: Synonymity Assertion
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Evidence Source
disposition: own
targets:
- concept: Evidence Source
kind: concept
owner:
canon: info-tech-canon
model: itc-evid
- source_term: Counterparty Assurance Gradient
disposition: own
targets:
- concept: Counterparty Assurance Gradient
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Reputation Signal
disposition: own
targets:
- concept: Reputation Signal
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Performance Evidence
disposition: own
targets:
- concept: Performance Evidence
kind: concept
owner:
canon: commerce-canon
model: counterparty
- source_term: Adjudication Outcome
disposition: own
targets:
- concept: Adjudication Outcome
kind: concept
owner:
canon: info-tech-canon
model: itc-evid
- source_term: 'Non-Canonical Convenience Term: Reputation'
disposition: own
targets:
- concept: Reputation
kind: convenience_term
owner:
canon: commerce-canon
model: counterparty
- source_term: Lifecycle State
disposition: own
targets:
- concept: Lifecycle State
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Assurance Level
disposition: own
targets:
- concept: Assurance Level
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: Relationship Tuple
disposition: import
targets:
- concept: Relationship Tuple
kind: concept
owner:
canon: info-tech-canon
model: itc-access
- source_term: Pseudonymous Identifier
disposition: own
targets:
- concept: Pseudonymous Identifier
kind: concept
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: User'
disposition: own
targets:
- concept: User
kind: convenience_term
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: Subscriber'
disposition: own
targets:
- concept: Subscriber
kind: convenience_term
owner:
canon: info-tech-canon
model: itc-ident
- source_term: 'Non-Canonical Convenience Term: Customer Account'
disposition: own
targets:
- concept: Customer Account
kind: convenience_term
owner:
canon: commerce-canon
model: counterparty

13
infospace/assimilation/canon-federation/open-questions.md Normal file
View file

@ -0,0 +1,13 @@
# Current versus historical questions
Frozen source review queues describe their original state, not new live tasks.
Known superseded assertions include Family as a collective actor (ADR R6),
Evidence Source used for assertions and adjudication (R3/R5/R7), generic Role or
Subject redefinitions, and pipeline status treated as commercial binding.
The current models and migration ledger govern those cases. Historical scenario
claims of universal satisfiability are not a current conformance result.
Live continuation: CFED-WP-0001-T08 owns reciprocal cards, current navigation and
reviewed import revisions; T09 owns fleet references; T10 owns residual handoffs.
Family model authoring and consumer adoption require named demand and are not
created as speculative implementation work by this distribution.

6
infospace/assimilation/canon-federation/proposed-changes.md Normal file
View file

@ -0,0 +1,6 @@
# Canon changes
None in this provenance-distribution task. T05/T06/T11/T12/T13 established the
current draft destinations. Historical candidates such as Identifier Binding,
Account Link or Family-as-collective are not promoted by retaining their source
notes. Read the destination definitions and accepted ADR-006 before reuse.

13
infospace/assimilation/canon-federation/source-summary.md Normal file
View file

@ -0,0 +1,13 @@
# Source summary
Frozen completed research, not revalidated external specifications.
- authentication-federation: 4 files.
- authorization-relationships: 4 files.
- commercial-identity: 14 files.
- commercial-subscription: 2 files.
- entity-resolution-privacy: 3 files.
- identity-provisioning: 5 files.
- shared-context: 6 files.
- social-community-graphs: 4 files.
- verifiable-claims: 3 files.

105
infospace/assimilation/canon-federation/source/research/CorpusIndex.md Normal file
View file

@ -0,0 +1,105 @@
# CorpusIndex.md
# identity-canon Research Corpus Index
This index tracks the research corpus for `identity-canon`.
The repository is focused on research and terminology. The corpus should collect source notes, terminology extracts, conflict observations, and modeling implications from standards, product documentation, semantic vocabularies, authorization systems, decentralized identity work, and entity-resolution/privacy research.
## Source Stack
### identity-provisioning
- `scim-rfc7643-rfc7644.md`
- `ldap-rfc4519-inetorgperson-rfc2798.md`
- `keycloak-organizations.md`
- `zitadel-organizations-projects.md`
- `ory-kratos-keto.md`
### authentication-federation
- `oidc-core-subject-identifiers.md`
- `saml-nameid-federation.md`
- `nist-800-63-4.md`
- `shared-signals-caep-risc.md`
### social-community-graphs
- `activitypub-actors-followers.md`
- `foaf-agent-person-group-onlineaccount.md`
- `webid-solid-profile.md`
- `schema-org-person-organization-membership.md`
### authorization-relationships
- `zanzibar-rebac.md`
- `openfga-modeling.md`
- `cedar-principal-action-resource-context.md`
- `cerbos-abac-derived-roles.md`
### verifiable-claims
- `did-core.md`
- `vc-data-model-2.md`
- `openid4vc.md`
### entity-resolution-privacy
- `deterministic-vs-probabilistic-matching.md`
- `synonymity-assertions.md`
- `gdpr-pseudonymization.md`
### commercial-subscription
- `b2b-saas-subscriber-tenancy.md`
- `stripe-customer-billing.md`
### commercial-identity
- `commercial-identity-synthesis.md`
- `commercial-trust-binding-theory.md`
- `legal-person-agency-contract.md`
- `lei-gleif-legal-entity-identifier.md`
- `duns-commercial-credit-identity.md`
- `kyc-aml-commercial-identity-binding.md`
- `eidas-eudi-legal-person-wallet.md`
- `salesforce-crm-commercial-record.md`
- `beneficial-ownership-kyc-boi.md`
- `registry-identifier-subtypes.md`
- `reputation-assurance-gradient.md`
- `payment-credential-pci-boundary.md`
- `crm-pipeline-commitment-threshold.md`
- `commercial-identity-nuance-settlement.md`
## Source Note Template
Each source note should capture:
- source name;
- source type;
- domain;
- key concepts;
- relevant terminology;
- assumptions;
- modeling implications;
- conflicts with other sources;
- usefulness for identity-canon;
- candidate canonical mappings;
- open questions.
## Derived Canon Artifacts
The first proposal follow-up pass created these draft artifacts from the
proposal and seeded corpus topics:
- `terminology/TerminologyInventory.md`
- `terminology/TerminologyConflictMap.md`
- `canon/DesignPrinciples.md`
- `canon/CanonicalGlossary.md`
- `model/ConceptualModel.md`
- `scenarios/ScenarioTests.md`
- `OpenQuestions.md`
- `DownstreamRecommendations.md`
These files are candidate canon surfaces. Treat them as hypotheses to test
while backfilling the individual source notes.

10
infospace/assimilation/canon-federation/source/research/README.md Normal file
View file

@ -0,0 +1,10 @@
# research
This directory contains the research corpus for `identity-canon`.
Start with:
- `ResearchSeed.md` for the initial research framing and seeded terminology;
- `CorpusIndex.md` for the source stack and source note structure.
Each subdirectory corresponds to one research domain.

549
infospace/assimilation/canon-federation/source/research/ResearchSeed.md Normal file
View file

@ -0,0 +1,549 @@
# ResearchSeed.md
# identity-canon Research Seed
This file captures the initial research seeding information for `identity-canon`.
The research goal is to distill a canonical terminology and conceptual data model for identity, user, organization, community, tenant, and relationship management in complex systems that are multi-tenant, multi-vendor, multi-community, and multi-user capable.
The model should support enterprises with sub-organizations, social communities, social-media follower graphs, single users, family entities, spontaneous interest groups, bots, service accounts, AI agents, and weak/strong synonymity between identity records.
## Initial Framing
The project should not start from a simple `user` table or from a classic `users + groups + roles` IAM schema.
A more robust canonical core is a graph of:
- actors;
- identities;
- accounts;
- identifiers;
- profiles;
- personas;
- scopes;
- tenants;
- organizations;
- communities;
- families/households;
- memberships;
- relationships;
- credentials;
- claims;
- evidence;
- synonymity assertions.
Classic IAM systems, social networks, enterprise directories, family accounts, communities, vendors, customers, and spontaneous groups can then be modeled as specializations or patterns over that graph.
## Important Research Domains
## 1. Identity Provisioning and Directory Models
Important sources:
- SCIM 2.0: RFC 7643 and RFC 7644;
- LDAP and inetOrgPerson: RFC 4519 and RFC 2798;
- Keycloak Organizations;
- ZITADEL organizations and projects;
- Ory Kratos and Keto.
Research focus:
- provisioning semantics;
- users and groups;
- organization/member terminology;
- directory assumptions;
- account lifecycle;
- separation between identity management and authorization.
SCIM is especially important as a provisioning baseline because it defines platform-neutral schemas and protocol operations for user and group resources.
LDAP and inetOrgPerson remain important because lightweight IAM stacks and enterprise systems still inherit LDAP-style person, organizational unit, and group terminology.
Keycloak and ZITADEL provide live multi-tenant IAM product vocabularies. Ory is useful because it separates identity management from authorization.
## 2. Authentication and Federation
Important sources:
- OpenID Connect Core;
- SAML 2.0;
- NIST SP 800-63-4;
- OpenID Shared Signals, CAEP, and RISC.
Research focus:
- issuer and subject concepts;
- pairwise and public subject identifiers;
- authentication assurance;
- federation assurance;
- assertions and claims;
- risk and security event streams;
- account linking and pseudonymous identifiers.
OIDC is central because externally issued subject identifiers and pairwise identifiers directly affect synonymity and account-linking semantics.
SAML remains important for enterprise federation and assertion semantics.
NIST identity guidance is useful for separating identity proofing, authentication assurance, federation assurance, and lifecycle management.
Shared Signals, CAEP, and RISC suggest that canonical identity models should also anticipate dynamic security and lifecycle events.
## 3. Social Graph and Community Models
Important sources:
- ActivityPub;
- FOAF;
- WebID;
- Solid profiles;
- Schema.org Person and Organization.
Research focus:
- actors;
- followers/following;
- public profiles;
- handles;
- accounts on federated servers;
- communities;
- groups;
- social relationships;
- semantic vocabularies for persons and organizations.
ActivityPub is especially relevant because it treats users as server-side actors with inboxes and outboxes. A person may have several actors across servers, which maps well to contextual identities and personas.
FOAF and Schema.org are useful because they distinguish persons, agents, organizations, groups, accounts, and membership-like properties.
WebID/Solid are useful for user-controlled profiles and decentralized identity-style profile discovery.
## 4. Authorization and Relationship Semantics
Important sources:
- Google Zanzibar;
- OpenFGA;
- Cedar;
- AWS Verified Permissions;
- Cerbos.
Research focus:
- relationship-based authorization;
- subject-relation-object tuples;
- principals;
- resources;
- actions;
- context;
- roles vs permissions vs relationships;
- delegated administration.
Zanzibar/OpenFGA-style relationship tuples are especially close to what `identity-canon` needs for memberships, ownership, representation, delegation, family roles, community moderation, vendor/customer relationships, and tenant administration.
Cedar’s principal-action-resource-context distinction is useful for preserving orthogonality between identity, action, resource, and request context.
## 5. Decentralized Identity and Verifiable Claims
Important sources:
- W3C DID Core;
- W3C Verifiable Credentials Data Model 2.0;
- OpenID for Verifiable Credentials.
Research focus:
- decentralized identifiers;
- DID subjects and controllers;
- verification methods;
- claims;
- issuers;
- holders;
- verifiers;
- presentations;
- portable identity claims;
- externally controlled identifiers.
DID and Verifiable Credentials are relevant when identity, membership, authorization, or representation claims are issued outside the platform.
The canonical model should distinguish claims from verified facts and should preserve issuer, evidence, scope, validity, and revocation state.
## 6. Entity Resolution, Synonymity, and Privacy
Important sources:
- deterministic matching;
- probabilistic matching;
- entity resolution and record linkage literature;
- GDPR pseudonymization and anonymization guidance.
Research focus:
- weak identity matches;
- strong identity links;
- scoped identity equivalence;
- operational account linking;
- legal identity links;
- privacy-preserving links;
- source and evidence;
- confidence;
- revocation;
- GDPR implications.
The model should avoid treating identity linkage as a destructive merge. Instead, synonymity should be modeled as an assertion with strength, scope, source, evidence, confidence, validity, and revocation state.
## Terminology Challenge
Many common terms are overloaded:
| Term | Common Meanings | Modeling Risk |
| --- | --- | --- |
| User | Human, account, login principal, profile, customer record, app user | Collapses person, account, and actor |
| Account | Login credential set, billing account, social media handle, tenant account | Collapses authentication and business relationship |
| Organization | Legal entity, tenant, department, team, community, vendor, customer | Collapses legal structure, membership scope, and operational boundary |
| Group | LDAP group, social group, permission group, family, team, community | Collapses social grouping and authorization grouping |
| Role | Job function, permission bundle, relationship label, social role | Collapses semantics, permissions, and responsibility |
| Identity | Real-world personhood, credentialed subject, account identity, profile | Collapses entity, claim, authenticator, and identifier |
| Principal | Human user, service account, agent, organization acting entity | Good for authorization, too narrow for social modeling |
| Tenant | Isolation boundary, customer organization, billing unit, realm | Collapses infrastructure boundary and social/legal actor |
The key design move is to stop using `user` as the root concept.
## Candidate Canonical Vocabulary
## Entity and Actor Layer
### Entity
Anything that can be referred to as a modeled thing: person, organization, family, community, bot, service, account, resource, project, domain, or device.
### Actor
An entity capable of intentional or delegated action in a system. Examples include human persons, organizations acting through representatives, AI agents, service accounts, and community bots.
### Natural Person
A human being. This should not be identical to `user`, because a person can have many accounts, profiles, personas, and relationships.
### Collective Actor
A group-like actor that can act collectively or be represented by members/admins. Subtypes include enterprise, department, family, community, interest group, vendor, customer tenant, and project team.
### Artificial Actor
A bot, service account, automation, coding agent, or autonomous agent.
## Identity and Account Layer
### Identity
A claim-bearing representation of an actor in a context. An actor can have multiple identities.
### Identifier
A value used to refer to an identity or entity: UUID, email address, username, OIDC subject, SAML NameID, DID, domain name, phone number, employee number.
### Account
A system-local operational identity used for login, profile, preferences, sessions, and credentials.
### Profile
A presentation surface of an identity or account. A profile may be public, private, tenant-local, app-local, community-local, or audience-specific.
### Persona
A deliberate contextual identity expression of an actor. Examples include private person, employee persona, admin persona, and pseudonymous community handle.
### Credential
Something used to authenticate or prove a claim: password, passkey, certificate, TOTP seed, recovery factor, verifiable credential, or domain ownership proof.
### Authenticator
The concrete authentication factor or mechanism bound to an account/subscriber.
## Scope and Tenancy Layer
### Scope
A bounded context in which identifiers, memberships, roles, policies, and profile data have meaning.
### Tenant
A scope with operational isolation and delegated administration. A tenant may be backed by an organization, family, community, individual, vendor, or platform unit.
### Realm / Identity Domain
A hard identity boundary with separate users, credentials, clients, policies, and lifecycle.
### Organization
A structured collective actor with governance, membership, and possibly sub-organizations. It may or may not be a legal entity.
### Legal Entity
An organization recognized by a jurisdiction. Not every organization, community, or team is a legal entity.
### Community
A collective actor primarily organized by shared interest, social graph, participation, or moderation rules rather than employment/legal hierarchy.
### Household / Family
A collective actor organized around family/household relationships, guardianship, shared resources, and dependent accounts.
### Spontaneous Group
A lightweight collective actor created ad hoc around temporary interest, event, project, or conversation.
Important distinction: tenant, organization, and community must not be synonyms. A tenant is an operational boundary. An organization, community, or family is a social/legal actor that may own or inhabit a tenant.
## Relationship Layer
### Relationship
A typed edge between entities, actors, accounts, scopes, resources, or other modeled concepts.
### Membership
A relationship where an actor participates in a collective actor or scope.
### Affiliation
A looser relationship indicating association without necessarily implying membership, authority, or access.
### Representation
A relationship where one actor can act on behalf of another.
### Delegation
A scoped, revocable grant of authority from one actor to another.
### Administration
A delegated authority to manage lifecycle, membership, policy, or resources in a scope.
### Ownership
A strong control or responsibility relationship over an entity, resource, or scope. This may require legal, operational, and data-control subtypes.
### Follower Relationship
A directional social relationship expressing subscription or attention, not necessarily trust, membership, or permission.
### Trust Relationship
A relationship where one actor accepts claims, credentials, or decisions from another actor under defined conditions.
## Role and Capability Layer
### Role
A named relationship pattern in a scope. Examples include member, owner, moderator, billing admin, guardian, employee, and vendor admin.
### Capability
An ability to perform an action, usually derived from roles, policies, relationships, credentials, or explicit grants.
### Permission
A concrete allowed action on a resource type or instance.
### Policy
A rule that derives permissions or capabilities from relationships, attributes, credentials, and context.
This prevents the classic collapse of role, group, permission bundle, and job title.
## Synonymity and Identity Resolution Layer
### Strong Synonymity
Two identifiers, accounts, or identities are asserted to refer to the same underlying actor with high confidence and strong evidence.
Examples:
- same verified OIDC subject from the same issuer;
- account explicitly linked after re-authentication;
- verifiable credential bound to the same DID/controller.
### Weak Synonymity
Two records may refer to the same actor based on partial, contextual, or probabilistic evidence.
Examples:
- same email seen in imported CSV and social profile;
- matching name/domain;
- same account handle without explicit proof.
### Scoped Synonymity
Two identifiers are treated as equivalent only within a defined context.
Example:
- a pairwise OIDC subject mapped to a local account for one relying party.
### Operational Link
A system-level account link used for convenience, not necessarily a real-world identity assertion.
### Legal Identity Link
A stronger assertion that may support contracts, billing, employment, guardianship, or compliance.
### Privacy-Preserving Link
A link that enables continuity without exposing global identity.
Examples:
- pairwise identifiers;
- pseudonymous handles;
- tenant-local subjects.
## Synonymity Assertion Fields
A synonymity assertion should carry at least:
```text
source
target
relation_type: same_as | probably_same_as | linked_to | represents | controls | acts_for
strength: weak | medium | strong | authoritative
scope
evidence
issuer/source_system
created_at
valid_from / valid_until
revocation_state
privacy_classification
```
## Initial Conceptual Model Shape
```text
Entity
├─ Actor
│ ├─ NaturalPerson
│ ├─ CollectiveActor
│ │ ├─ Organization
│ │ ├─ LegalEntity
│ │ ├─ Community
│ │ ├─ FamilyOrHousehold
│ │ └─ SpontaneousGroup
│ └─ ArtificialActor
│ ├─ ServiceAccount
│ ├─ Bot
│ └─ Agent
├─ Account
├─ Profile
├─ Credential
├─ Resource
└─ Scope
├─ Tenant
├─ Realm
├─ OrganizationScope
├─ CommunityScope
└─ ApplicationScope
```
## Initial Relationship Model Shape
```text
Relationship
subject_entity_id
relation_type
object_entity_id
scope_id
source
evidence_ref
strength
status
valid_from
valid_until
metadata
```
## Example Statements the Model Should Express
```text
Bernd is member of Binect
Binect is sub-organization of Whynot GmbH
User account A is operated by Bernd
ActivityPub actor @x follows @y
Child account C is represented by guardian G
Vendor tenant V provides application App1
Customer tenant C consumes application App1
Service account S acts for organization O in scope T
OIDC subject sub123 is strongly linked to local account U in relying-party scope R
Email e@example.com is weakly linked to person P based on imported evidence
```
## CLI/UI Implications for Later Work
Although `identity-canon` is not an implementation repository, the model should later support convenient CLI/UI workflows such as:
```text
create-person
create-organization
create-community
create-family
create-spontaneous-group
create-tenant-for-actor
invite-member
link-account
claim-domain
assign-admin
delegate-authority
create-service-account
create-agent
add-follower-edge
assert-synonymity
review-synonymity
revoke-link
export-scim
sync-ldap
provision-keycloak
```
These workflows should remain downstream implementation concerns.
## Working Hypothesis
A strong canonical model can be based on five orthogonal primitives:
```text
Actor who/what can act
Identity how an actor is represented or claimed in a context
Scope where a statement has meaning
Relationship how modeled things are connected
Evidence why a statement is trusted
```
From these, operational IAM concepts can be derived:
```text
User = account/identity used by a natural person in a scope
Tenant = operational scope with delegated administration
Group = collective actor or membership set, depending on context
Role = named relationship/policy pattern in a scope
Org = structured collective actor
Community = participatory collective actor
Family = household/kinship collective actor
```
## Research Direction
The next step is to populate the source-stack notes, extract terminology from each source, and create:
- terminology inventory;
- terminology conflict map;
- canonical glossary;
- concept cards;
- scenario tests;
- conceptual model;
- synonymity model;
- scope model;
- downstream recommendations.

129
infospace/assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md Normal file
View file

@ -0,0 +1,129 @@
# NIST SP 800-63-4
## Source Type
Government guideline. NIST Special Publication 800-63-4, Digital Identity
Guidelines (2025).
## Domain
Identity assurance, authentication assurance, federation assurance, and
identity lifecycle.
## Why This Source Matters
NIST identity guidance separates identity proofing, authentication assurance,
federation assurance, and lifecycle management.
NIST 800-63 provides the most explicit assurance-level vocabulary for
separating how strongly an identity is bound to a person, how strongly
authentication occurred, and how federation preserves or degrades assurance.
## Key Concepts
- **IAL (Identity Assurance Level)**: confidence that a subscriber is who they
claim to be (IAL1–IAL3).
- **AAL (Authenticator Assurance Level)**: confidence in authentication
mechanism strength (AAL1–AAL3).
- **FAL (Federation Assurance Level)**: confidence in federation protocol and
assertion protection (FAL1–FAL3).
- **Subscriber**: party enrolled with a CSP (credential service provider).
- **Credential Service Provider (CSP)**: issues credentials and performs
identity proofing.
- **Relying Party (RP)**: depends on CSP assertions.
- **Identity Provider (IdP) / Asserting Party (AP)**: federates authentication
to RPs.
- **Verifier**: entity confirming claimant possession of authenticator.
- **Binding**: association between subscriber, identity, and authenticator.
- **Identity proofing**: collection and validation of evidence about a person.
- **Authenticator**: something the subscriber possesses/controls for auth.
- **Federation assertion**: signed statement from IdP to RP about
authentication and attributes.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Subscriber | Enrolled party at CSP; not necessarily named "user." |
| CSP | Provider performing proofing and credential issuance. |
| RP | Consumer of identity/authentication assertions. |
| IAL | Identity proofing strength level. |
| AAL | Authentication event strength level. |
| FAL | Federation protocol/assertion protection level. |
| Claimant | Party attempting authentication. |
| Verifier | Confirms authenticator use. |
| Binding | Link between subscriber identity and authenticator. |
| Supervised remote proofing | IAL2+ proofing with human or tech supervision. |
## Modeling Assumptions
- **Identity assurance, authentication, and federation are separable**
dimensions with independent levels.
- **Subscriber is the enrolled entity**, not the legal person directly; binding
connects them.
- **Proofing evidence matters** and should be retained per policy.
- **Federation may preserve or reduce assurance** depending on FAL and
assertion contents.
- **Lifecycle includes enrollment, binding, maintenance, and termination.**
- **Pseudonymous enrollment is allowed** at IAL1 without real-name binding.
- **Agency/customer relationship** is outside the technical model but affects
policy.
## Identity-Canon Implications
- NIST **Subscriber** maps to **Account** or enrolled **Identity Record**
bound to **Natural Person** at higher IAL.
- **IAL** maps to **Assurance Level** on Identity Record / Person binding.
- **AAL** maps to **Assurance Level** on authentication event / Credential use.
- **FAL** maps to **Assurance Level** on **Trust Relationship** or federation
assertion.
- **Binding** maps to **Synonymity Assertion** or **Identifier Binding**
between subscriber, person, and authenticator.
- **Identity proofing evidence** maps to **Evidence Source**.
- Reinforces **P7** (synonymity as assertion) and **P8** (preserve evidence).
- Supports S12 (weak match insufficient for IAL2+), S13 (strong link with
verification), S06 (family/guardian proofing).
## Terminology Conflicts
- **Subscriber vs. User**: NIST subscriber is enrolled party; apps say user.
- **Identity vs. Subscriber**: NIST separates identity proofing from
subscriber record.
- **Credential vs. Authenticator**: NIST distinguishes credential (issued)
from authenticator (possessed); products conflate.
- **IAL vs. Account trust**: assurance on person binding ≠ account permissions.
- **Federation vs. Synonymity**: federation assertion ≠ same-person claim
across systems.
## Candidate Canonical Mappings
| NIST concept | Candidate canonical concept |
| --- | --- |
| Subscriber | Account / enrolled Identity Record |
| CSP / IdP | Issuer Scope + Trust Relationship |
| RP | Relying party Scope |
| IAL | Assurance Level (identity proofing) |
| AAL | Assurance Level (authentication) |
| FAL | Assurance Level (federation) |
| Authenticator | Credential |
| Binding | Identifier Binding / Synonymity Assertion |
| Proofing evidence | Evidence Source |
| Federation assertion | Claim + Credential (signed) |
| Claimant | Actor attempting authentication (projection) |
## Open Questions
- Should IAL/AAL/FAL be a unified Assurance Level vocabulary or three
orthogonal dimensions in canon?
- How should pseudonymous IAL1 subscribers map when no Natural Person binding
exists?
- Does guardian-assisted proofing for minors warrant a distinct Relationship
type with assurance caps?
- Should CSP subscriber ID be a Scoped Identifier under CSP Scope?
## References
- NIST SP 800-63-4 — https://pages.nist.gov/800-63-4/
- NIST SP 800-63A (Enrollment and Identity Proofing) — https://pages.nist.gov/800-63-4/sp800-63A.html
- NIST SP 800-63B (Authentication and Lifecycle) — https://pages.nist.gov/800-63-4/sp800-63B.html
- NIST SP 800-63C (Federation and Assertions) — https://pages.nist.gov/800-63-4/sp800-63C.html

125
infospace/assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md Normal file
View file

@ -0,0 +1,125 @@
# OIDC Core Subject Identifiers
## Source Type
Standard. OpenID Connect Core 1.0 incorporating errata; subject identifier
types defined in Core and the Subject Identifier Types specification.
## Domain
Authentication, federated identity, token claims, and relying-party-scoped
subject identification.
## Why This Source Matters
OpenID Connect subject identifiers, claims, pairwise/public subjects, relying
parties, and issuers.
OIDC is the dominant federation protocol. Its `sub` claim, issuer (`iss`),
pairwise identifier type, and claim model directly shape synonymity,
account-linking, and scoped-identifier semantics in identity-canon.
## Key Concepts
- **Issuer (iss)**: OIDC provider identifier; defines the namespace for
subject identifiers and claims.
- **Subject (sub)**: locally unique identifier for an end-user at the issuer;
stable per issuer and subject type.
- **Claim**: name/value (or structured) assertion about the subject in ID
token or UserInfo response.
- **ID Token**: JWT (or encrypted JWT) asserting authentication event with
`iss`, `sub`, `aud`, `exp`, and optional claims.
- **Relying Party (RP)**: client application consuming tokens from an OP.
- **Pairwise subject identifier**: per-RP (or per-sector) `sub` preventing
cross-RP correlation.
- **Public subject identifier**: same `sub` across RPs at one issuer.
- **Claim Types**: Normal (profile), Aggregated, Distributed.
- **Authentication Context (acr, amr)**: signals about how authentication
was performed.
- **max_age / auth_time**: session freshness requirements.
- **Account linking (implicit)**: RP may maintain local account bound to
`iss` + `sub` pair.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Subject (sub) | Identifier for end-user at issuer; not the human being. |
| Issuer (iss) | URL identifying the OP; scopes subject namespace. |
| End-User | Human participant; OIDC does not model as a separate entity. |
| Relying Party | OAuth client receiving tokens about the subject. |
| Claim | Assertion about subject attributes or authentication event. |
| Pairwise sub | RP-specific subject preventing global correlation. |
| Public sub | Shared subject across RPs at same issuer. |
| ID Token | Signed authentication assertion. |
| UserInfo | Endpoint returning additional claims about subject. |
| aud (audience) | Intended RP client for the token. |
## Modeling Assumptions
- **Subject is issuer-scoped identifier**, not a person or account in the RP
system.
- **Issuer defines the namespace**; `iss` + `sub` is globally unique for
identification purposes.
- **Pairwise identifiers assume RP as scope** for correlation boundaries.
- **Claims are assertions** from the issuer, not verified facts in the RP.
- **End-user is implicit**; OIDC does not provision person records.
- **Account linking is RP-local**; protocol does not standardize cross-system
synonymity.
- **Authentication and attributes are bundled** in token delivery.
## Identity-Canon Implications
- OIDC **sub** maps to **Scoped Identifier** (pairwise) or **Identifier**
(public) within issuer **Realm/Scope**.
- **iss** maps to issuer **Scope** boundary.
- **End-User** maps to **Natural Person** only by RP inference, not by OIDC
entity.
- RP-local binding of `iss`+`sub` to local record maps to **Synonymity
Assertion** or **Identifier Binding**.
- **Claims** map to **Claim** objects with issuer as **Evidence Source**.
- **Pairwise sub** is canonical evidence for **Privacy-Preserving Link** (S14).
- **acr/amr** inform **Assurance Level** on authentication event.
- Strong support for **P2** (subject ≠ account) and **P3** (scope first-class).
## Terminology Conflicts
- **Subject vs. Actor**: OIDC subject is identifier; authorization and social
models use actor as participant.
- **Subject vs. Account**: RP often stores `sub` on a local user account record.
- **End-User vs. User**: OIDC end-user is human; `user` in apps means account.
- **Identity vs. Subject**: developers conflate `sub` with "identity."
- **Pairwise vs. Pseudonym**: pairwise is protocol mechanism; pseudonym is
broader privacy concept.
## Candidate Canonical Mappings
| OIDC concept | Candidate canonical concept |
| --- | --- |
| sub | Identifier or Scoped Identifier |
| iss | Realm / Scope (issuer namespace) |
| End-User | Natural Person (inferred, not represented) |
| Claim | Claim |
| ID Token | Credential / signed assertion |
| Pairwise sub | Scoped Identifier |
| Public sub | Identifier |
| iss + sub pair | Identifier Binding in RP scope |
| acr / amr | Assurance Level metadata |
| RP-local account link | Synonymity Assertion (strong, scoped) |
| aud | Scope (intended consumer) |
## Open Questions
- Should `iss` + `sub` be a compound Identifier type or a Synonymity key
pair linking to local Account?
- How should sector identifier (pairwise variant) map to Scope hierarchy?
- Does OIDC `sub` rotation on issuer policy change warrant Synonymity
Assertion supersession?
- Should distributed/aggregated claims map to Claim with Evidence Source
references to external issuers?
## References
- OpenID Connect Core 1.0 — https://openid.net/specs/openid-connect-core-1_0.html
- OpenID Connect Subject Identifier Types — https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
- OAuth 2.0 (RFC 6749) — https://datatracker.ietf.org/doc/html/rfc6749

128
infospace/assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md Normal file
View file

@ -0,0 +1,128 @@
# SAML NameID Federation
## Source Type
Standard. OASIS SAML 2.0 Core and Profiles for Web Browser SSO; NameID formats
and federation metadata conventions.
## Domain
Enterprise federation, single sign-on, assertion semantics, and cross-domain
identity correlation.
## Why This Source Matters
SAML 2.0 remains central to enterprise federation. NameID formats, assertion
subject statements, attribute statements, and IdP/SP metadata define how
enterprise identities cross organizational boundaries.
## Key Concepts
- **Identity Provider (IdP)**: asserts authentication and attributes about a
subject to service providers.
- **Service Provider (SP)**: consumes assertions and establishes local session.
- **Assertion**: XML security token containing subject, conditions, authn
statements, and attribute statements.
- **Subject / NameID**: identifier for the principal at the IdP; carries
Format attribute defining syntax and semantics.
- **NameID formats**: transient, persistent, emailAddress, X509SubjectName,
kerberos, entity, unspecified, and others.
- **Persistent NameID**: stable, opaque identifier for a principal at an IdP.
- **Transient NameID**: one-time identifier for a single federation session.
- **AttributeStatement**: SAML attributes (mail, eduPersonPrincipalName, group
memberships) about the subject.
- **AuthnStatement**: authentication instant, session index, and context class.
- **AudienceRestriction**: scopes assertion to intended SP entity IDs.
- **Metadata**: XML describing IdP/SP endpoints, certificates, NameID formats,
and supported attributes.
- **Affiliation / discovery**: federations aggregate metadata for trust circles.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Principal | Authenticated entity; identified by NameID in assertion. |
| NameID | Subject identifier chosen by IdP; format determines semantics. |
| Persistent NameID | Long-lived opaque ID stable for principal at IdP. |
| Transient NameID | Ephemeral ID for one session; privacy-preserving. |
| Subject | SAML assertion subject element holding NameID. |
| Attribute | Named property asserted about subject. |
| EntityID | Unique identifier for IdP or SP in metadata. |
| Assertion | Signed statement about authentication and attributes. |
| SessionIndex | Handle for single logout correlation. |
| Audience | Intended SP for assertion consumption. |
## Modeling Assumptions
- **NameID is the primary correlation key** between IdP and SP for account
linking.
- **Format determines persistence and privacy**; persistent enables cross-
session linking, transient prevents it.
- **Principal means authenticated subject**, not a pre-provisioned local user.
- **Attributes are asserted**, not authoritative directory records in the SP.
- **Trust is pairwise** between IdP and SP via metadata exchange.
- **Groups may appear as attributes**, not as first-class relationship tuples.
- **Federation operates across organizational boundaries**; each side
maintains its own namespace.
## Identity-Canon Implications
- SAML **NameID** maps to **Identifier** or **Scoped Identifier** depending
on format (persistent vs. transient).
- **Persistent NameID** supports **Synonymity Assertion** linking SP local
Account to IdP identifier.
- **Transient NameID** maps to session-scoped **Scoped Identifier** with no
cross-session synonymity.
- **Principal** in assertion maps to **Authenticated Subject** projection.
- **AttributeStatement** attributes map to **Claim** objects.
- **EntityID** maps to **Scope** identifier for IdP/SP.
- **AudienceRestriction** maps to Scope boundary for assertion validity.
- **Attribute-based group membership** maps to **Claim** (group attribute) or
Membership hint, not canonical Group unless provisioned.
- Supports S02 (multi-scope accounts), S13 (strong link via persistent NameID).
## Terminology Conflicts
- **Principal vs. Subject**: SAML uses both; principal is authenticated entity,
subject is XML element.
- **Principal vs. Authorization Principal**: SAML principal is auth subject,
not Cedar principal.
- **Persistent vs. Pairwise**: SAML persistent NameID is IdP-wide stable;
OIDC pairwise is RP-specific.
- **NameID vs. emailAddress format**: email as identifier conflates Identifier
with contact attribute.
- **Attribute vs. Claim**: SAML attribute is XML element; canon Claim is
issuer statement — compatible but different syntax.
## Candidate Canonical Mappings
| SAML concept | Candidate canonical concept |
| --- | --- |
| NameID (persistent) | Identifier |
| NameID (transient) | Scoped Identifier (session-bound) |
| NameID (emailAddress) | Identifier (with attribute conflation risk) |
| Principal | Authenticated Subject |
| Subject element | Protocol binding for Authenticated Subject |
| AttributeStatement attribute | Claim |
| EntityID (IdP/SP) | Scope identifier |
| Assertion | Credential / signed assertion |
| Audience | Scope boundary |
| SessionIndex | Session correlation reference (projection) |
| SP local account mapping | Synonymity Assertion |
## Open Questions
- Should persistent NameID map to strong Synonymity by default, or only after
SP verification (S13)?
- How should eduPerson / SCHAC attribute vocabularies map to Profile vs. Claim?
- Does transient NameID session scope warrant a distinct Lifecycle State on the
Scoped Identifier?
- Should federation metadata trust map to **Trust Relationship** with
certificate Evidence Source?
## References
- SAML 2.0 Core — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- SAML 2.0 Profiles — http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
- SAML NameID Format URIs — http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf (§8.3)
- REFEDS entity categories — https://refeds.org/category

125
infospace/assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md Normal file
View file

@ -0,0 +1,125 @@
# Shared Signals, CAEP, and RISC
## Source Type
Standard and profile. OpenID Shared Signals Framework 1.0, CAEP (Continuous
Access Evaluation Profile), and RISC (Risk Incident Sharing and Coordination).
## Domain
Security event sharing, session lifecycle, account state propagation, and
continuous access evaluation across federated systems.
## Why This Source Matters
OpenID Shared Signals, CAEP, and RISC suggest that canonical identity models
should anticipate dynamic security and lifecycle events.
Federation is not static. Shared Signals define how issuers push account
compromise, credential change, session revocation, and user profile update
events to relying parties — requiring lifecycle-aware identity modeling.
## Key Concepts
- **Shared Signals Framework (SSF)**: transport and envelope for delivering
security events between transmitter and receiver.
- **Transmitter**: entity (typically IdP) sending events about subjects.
- **Receiver**: entity (typically RP) consuming events and updating local state.
- **Subject in event**: identifies the affected party, often by `sub` and `iss`
or equivalent.
- **CAEP events**: session-revoked, token-claims-change, credential-change,
assurance-level-change, and related continuous evaluation signals.
- **RISC events**: account-credential-compromise, account-disabled,
account-enabled, identifier-changed, and recovery-related events.
- **SET (Security Event Token)**: JWT-format event payload.
- **Stream configuration**: receiver registers endpoint; transmitter manages
delivery and retry.
- **Verification**: receivers validate SET signatures from transmitter.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Transmitter | Event source (usually OP/IdP). |
| Receiver | Event consumer (usually RP). |
| SET | Security Event Token (JWT). |
| Subject (event) | Identifies affected user at transmitter. |
| Session revoked | Active sessions should be terminated at receiver. |
| Credential change | Password/key rotation; may require re-auth. |
| Account disabled | Subject account suspended at transmitter. |
| Identifier changed | Subject ID or attribute materially changed. |
| Assurance level change | IAL/AAL/FAL or equivalent changed. |
| Stream | Configured event delivery channel. |
## Modeling Assumptions
- **Identity state changes over time** and RPs must react without polling.
- **Subject in events maps to prior federation binding** (`iss`+`sub` or
equivalent).
- **Lifecycle events are issuer-authoritative** for issuer-managed accounts.
- **Receivers maintain local session/account state** that must reconcile with
events.
- **Not all state changes imply synonymity changes**; identifier-changed may
require rebinding.
- **Events are evidence** for downstream state transitions.
## Identity-Canon Implications
- SSF events map to **Evidence Source** events triggering **Lifecycle State**
transitions on Account, Session projection, or Synonymity Assertion.
- **Account disabled/enabled** maps to Lifecycle State change on Account or
Identity Record.
- **Credential change** maps to Credential lifecycle event; may invalidate
sessions.
- **Session revoked** affects session projection, not canonical Account.
- **Identifier changed** may require superseding **Identifier Binding** or
Synonymity Assertion with new target.
- **Assurance level change** maps to updated **Assurance Level** metadata.
- Reinforces **P8** (preserve source/evidence) and invariant that lifecycle
applies to relationships and assertions, not only accounts.
- Supports S02 (multi-account lifecycle), S13 (link revocation), federation
scenarios requiring continuous evaluation.
## Terminology Conflicts
- **Subject**: event subject is issuer identifier; not authorization subject.
- **Account**: event "account disabled" means issuer-side record; RP may have
separate local account.
- **Session vs. Account**: session revocation ≠ account deletion.
- **Identifier changed vs. Synonymity**: identifier migration is not automatic
same-as merge.
- **Continuous access vs. Authorization**: CAEP informs access evaluation but
is not a policy engine.
## Candidate Canonical Mappings
| SSF/CAEP/RISC concept | Candidate canonical concept |
| --- | --- |
| SET event | Evidence Source (event) |
| Transmitter | Issuer Scope |
| Receiver | Relying party Scope |
| Event subject | Identifier reference |
| Account disabled/enabled | Lifecycle State transition |
| Credential change | Credential Lifecycle State |
| Session revoked | Session projection lifecycle |
| Identifier changed | Identifier Binding supersession |
| Assurance level change | Assurance Level update |
| Token claims change | Claim set modification event |
## Open Questions
- Should SET event types be enumerated in canon as standard Evidence Source
categories?
- How should identifier-changed events interact with existing Synonymity
Assertions (supersede vs. revoke vs. chain)?
- Should receivers model event processing state as Relationship between
Receiver Scope and Transmitter Scope?
- Are session projections worth a minimal canonical mention given SSF
prevalence?
## References
- OpenID Shared Signals Framework 1.0 — https://openid.net/specs/openid-sharedsignals-framework-1_0.html
- OpenID CAEP 1.0 — https://openid.net/specs/openid-caep-1_0.html
- OpenID RISC 1.0 — https://openid.net/specs/openid-risc-1_0.html
- RFC 8417: Security Event Token (SET) — https://datatracker.ietf.org/doc/html/rfc8417

114
infospace/assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md Normal file
View file

@ -0,0 +1,114 @@
# Cedar Principal Action Resource Context
## Source Type
Standard and product reference. Cedar policy language (AWS Verified Permissions)
with principal-action-resource-context evaluation model.
## Domain
Fine-grained authorization, policy-based access control, and ABAC/RBAC
hybrid evaluation.
## Why This Source Matters
Cedar's principal-action-resource-context distinction preserves orthogonality
between identity, action, resource, and request context.
## Key Concepts
- **Principal**: entity requesting access; typed entity reference (`User::"alice"`,
`Role::"admin"`).
- **Action**: operation being attempted (`Action::"view"`, `Action::"delete"`).
- **Resource**: entity being accessed (`Document::"report"`).
- **Context**: request-time record with additional attributes (IP, time,
delegated-by).
- **Policy**: Cedar statement allowing or forbidding `(principal, action, resource)`
under conditions.
- **Entity**: typed object in entity store with attributes and parents.
- **Schema**: defines entity types, actions, and attribute shapes.
- **Group / Role entity**: principal may be member of groups; roles as entities.
- **Authorization request**: tuple of principal, action, resource, context
evaluated against policies.
- **Conditional policies**: when-clauses over context and entity attributes.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Principal | Entity requesting access in authorization decision. |
| Action | Verb/operation being authorized. |
| Resource | Target entity of the action. |
| Context | Ephemeral request attributes. |
| Entity | Typed node in entity store with UID and attributes. |
| Policy | Rule governing allow/deny. |
| Schema | Type system for entities and actions. |
| Role | Entity type principals can assume or belong to. |
| Group | Entity type with membership edges. |
| UID | Unique entity identifier string (`Type::"id"`). |
## Modeling Assumptions
- **Authorization is a decision over four orthogonal dimensions** (PARTICIPANT,
ACTION, TARGET, CONTEXT).
- **Principals are entity references**, not full identity records.
- **Entity store is separate** from identity directory; may sync from IAM.
- **Roles and groups are entities**, not free-floating strings.
- **Context carries delegation and environmental facts** at decision time.
- **Policies are declarative** and evaluated without imperative code.
- **No social or legal relationship model** beyond entity parent/group links.
## Identity-Canon Implications
- Cedar **Principal** maps to **Authorization Principal** projection.
- **Resource** maps to **Authorization Resource** projection.
- **Action** maps to **Authorization Action** projection.
- **Context** maps to request **Context** projection (may carry Delegation
evidence).
- **Entity** in store may represent Account, Group, Role, or Organization
projection — not canonical Actor directly.
- Parent/group entity links parallel **Membership** in authz layer.
- Context `delegatedBy` or custom attributes support S11 (AI agent delegation).
- Strong evidence for **P6** and **P2** (principal ≠ actor ≠ account).
## Terminology Conflicts
- **Principal vs. Actor**: Cedar principal is decision participant; actor is
conceptual entity.
- **Principal vs. Subject**: OIDC subject is identifier; Cedar principal is
typed entity UID.
- **Role**: Cedar Role entity vs. IAM role vs. social role.
- **Group**: Cedar group entity vs. LDAP group vs. community.
- **Entity**: Cedar entity vs. canon Entity family (actor layer).
## Candidate Canonical Mappings
| Cedar concept | Candidate canonical concept |
| --- | --- |
| Principal | Authorization Principal |
| Resource | Authorization Resource |
| Action | Authorization Action |
| Context | Request context projection |
| Entity (User) | Authorization Principal (Account projection) |
| Entity (Group) | Group (authz projection) |
| Entity (Role) | Role (authorization projection) |
| Policy | Authorization Policy (downstream artifact) |
| Schema | Authorization schema (downstream) |
| parent relation | Membership/inheritance (authz projection) |
| Context.delegatedBy | Delegation Relationship (context reference) |
## Open Questions
- Should canon define a minimal Context projection schema for delegation and
assurance attributes?
- How should Cedar User entities map to Account vs. Service Account vs.
Artificial Agent?
- Are Cedar Role entities always authorization projections, or can they mirror
canonical Role relationships?
- Should entity UID format be standardized in downstream recommendations?
## References
- Cedar policy language — https://www.cedarpolicy.com/
- Cedar schema format — https://www.cedarpolicy.com/policies/syntax-schema.html
- AWS Verified Permissions — https://docs.aws.amazon.com/verifiedpermissions/

114
infospace/assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md Normal file
View file

@ -0,0 +1,114 @@
# Cerbos ABAC Derived Roles
## Source Type
Product documentation and open-source implementation reference for Cerbos
policy decision point with derived roles and attribute-based conditions.
## Domain
Policy-based authorization, attribute-driven role derivation, and resource-centric
access control.
## Why This Source Matters
Cerbos combines resource policies, principal attributes, and derived roles —
a pattern common in SaaS where permissions depend on both identity attributes
and resource ownership context.
## Key Concepts
- **Principal**: subject of authorization request with `id` and `roles` plus
optional attributes.
- **Resource**: target with `kind`, `id`, and attributes (owner, department,
classification).
- **Action**: operation requested on resource.
- **Policy**: YAML/JSON rules binding roles and conditions to allow/deny/effect.
- **Derived roles**: dynamically computed roles from principal + resource
attributes (e.g., `owner` when `principal.id == resource.attr.owner`).
- **Static roles**: assigned roles on principal at request time.
- **Condition**: CEL expression over principal, resource, and request metadata.
- **Scope**: policy namespace for multi-tenant isolation (`scope` field).
- **AuxData**: JWT claims or external data enriching principal at check time.
- **Effect**: ALLOW, DENY, or conditional variants with rule ordering.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Principal | Requesting party with id, roles, attributes. |
| Resource | Entity with kind, id, and attributes. |
| Derived role | Role computed from attribute matching rules. |
| Static role | Pre-assigned role on principal. |
| Policy | Declarative allow/deny rules. |
| Scope | Tenant or environment partition for policies. |
| Condition | Boolean expression over request context. |
| AuxData | Supplemental principal data (e.g., JWT). |
| kind | Resource type discriminator. |
| attr | Attribute bag on principal or resource. |
## Modeling Assumptions
- **Authorization is resource-centric** with policies attached to resource kinds.
- **Roles can be derived at evaluation time** from attribute equality or
relationships encoded in attributes.
- **Principal attributes may come from JWT** or external identity system.
- **Ownership is often modeled as resource attribute**, not explicit relationship.
- **Scope provides tenant isolation** for policy sets.
- **No graph traversal** for permissions; derivation is attribute-based.
- **Identity system supplies principal id and roles**; Cerbos does not store
identity records.
## Identity-Canon Implications
- Cerbos **Principal** maps to **Authorization Principal** projection.
- **Resource** maps to **Authorization Resource** projection.
- **Derived role** (e.g., owner) should trace to canonical **Ownership
Relationship** or **Membership** when possible, not only attribute equality.
- Encoding `resource.attr.owner = principal.id` collapses relationship into
attribute — canon should prefer explicit Relationship with authz projection.
- **Scope** maps to **Scope** / **Tenant** for policy partition.
- **AuxData JWT claims** map to **Claim** inputs to authorization projection.
- Supports S05 (admin roles), S10 (service principal attributes), but risks
hiding relationships in attributes (tension with **P5**).
## Terminology Conflicts
- **Principal vs. User**: Cerbos principal id often equals user id from app DB.
- **Owner**: derived role "owner" vs. Ownership Relationship vs. resource
attribute.
- **Role**: derived role vs. static IAM role vs. canonical Role relationship.
- **Scope vs. Tenant**: Cerbos scope is policy namespace; may not equal tenant.
- **Attributes vs. Profile**: principal attributes overlap with profile fields.
## Candidate Canonical Mappings
| Cerbos concept | Candidate canonical concept |
| --- | --- |
| Principal | Authorization Principal |
| Resource | Authorization Resource |
| Action | Authorization Action |
| Static role | Role (authorization projection) |
| Derived role | Role derived from Relationship (preferred) or attribute rule |
| Policy | Authorization Policy (downstream) |
| Scope | Scope / Tenant (policy partition) |
| Principal attributes | Profile/Claim inputs to projection |
| Resource attributes | Resource metadata + Ownership hints |
| AuxData (JWT) | Claim + Authenticated Subject context |
| Condition | Request context projection |
## Open Questions
- Should canon explicitly discourage encoding Ownership as resource attribute
without a backing Relationship?
- How should derived roles from group membership sync with canonical Membership
edges?
- Does Cerbos scope map 1:1 to Tenant, or also to Application Scope?
- Should JWT AuxData be documented as standard Authenticated Subject →
Principal projection path?
## References
- Cerbos documentation — https://docs.cerbos.dev/
- Cerbos derived roles — https://docs.cerbos.dev/cerbos/latest/policies/derived_roles
- Cerbos scopes — https://docs.cerbos.dev/cerbos/latest/policies/scope_policy

111
infospace/assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md Normal file
View file

@ -0,0 +1,111 @@
# OpenFGA Modeling
## Source Type
Product documentation and open-source implementation reference for OpenFGA
authorization modeling (Zanzibar-inspired).
## Domain
Relationship-based access control modeling, authorization schema design, and
multi-tenant permission systems.
## Why This Source Matters
OpenFGA provides a concrete, documented modeling language for Zanzibar-style
relationship tuples with authorization models, stores, and checks.
## Key Concepts
- **Authorization model**: declarative schema of types, relations, and
permission definitions.
- **Type definition**: object type with relations and optional `define` rules.
- **Relation**: named edge on a type; may allow direct assignment or computed
rules.
- **Define / rewrite rules**: union (`+`), intersection, exclusion, and
inheritance (`from relation`).
- **Tuple**: `user:type#relation@object:type` stored fact.
- **Userset**: indirect reference such as `user:anne#member@group:engineering`.
- **Store**: isolated tuple set with its own model.
- **Check / ListObjects / ListUsers**: query APIs.
- **Contextual tuples**: ephemeral tuples supplied at check time.
- **Conditions**: CEL-based contextual rules on relations (newer versions).
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| User (in tuple) | Subject identifier in `user:` namespace. |
| Object | Entity in `object:` namespace with type. |
| Relation | Named permission edge on a type. |
| Type | Schema class for objects (document, folder, organization). |
| Model | Collection of type definitions. |
| Store | Isolated authorization dataset. |
| define | Computed relation rule. |
| from | Inheritance from related object's relation. |
| contextual tuple | Runtime-only tuple for conditional checks. |
## Modeling Assumptions
- **Model-first design**: relations are declared in schema before tuples are written.
- **User and object IDs are opaque strings**; no embedded identity semantics.
- **Organization/tenant patterns** are modeled as types (e.g., `organization`,
`tenant`) with `member`, `admin` relations.
- **Inheritance chains** (folder contains document) are common modeling pattern.
- **Store isolation** provides multi-tenant authorization separation.
- **Identity management is external**; OpenFGA consumes identifiers.
- **Permissions are computed**, not stored as standalone grants.
## Identity-Canon Implications
- OpenFGA aligns with Zanzibar mappings; adds explicit **authorization model**
as schema artifact (downstream, not canonical).
- Type definitions like `organization#member` parallel **Organization** +
**Membership Relationship** but in authz projection.
- **Store** maps to **Authorization Domain** Scope or tenant-scoped authz partition.
- `user:` prefix in tuples maps to **Authorization Principal** identifier.
- Contextual tuples support request-time **Delegation** context without
persisting relationship.
- Model examples for parent-child org hierarchies support S03, S04, S05.
- Reinforces **P6**: tuples are projections from actors/relationships.
## Terminology Conflicts
- **User**: OpenFGA `user:` is tuple subject prefix, not human or account.
- **Organization type**: authz type ≠ Organization collective actor unless
explicitly linked.
- **Member relation**: authz member ≠ community member without model alignment.
- **Store vs. Tenant**: store is authz isolation; tenant is broader scope.
- **Permission vs. Relation**: permissions are computed from relations; products
often say "permission" for relation name.
## Candidate Canonical Mappings
| OpenFGA concept | Candidate canonical concept |
| --- | --- |
| Tuple | Relationship Tuple (authorization projection) |
| user: (subject) | Authorization Principal |
| object: (entity) | Authorization Resource |
| Relation | Relationship type (authz-implied) |
| Type definition | Authorization schema (downstream) |
| Store | Authorization Domain Scope |
| define/from rules | Authorization derivation (non-canonical) |
| organization#member | Membership Relationship (projection) |
| organization#admin | Administration Relationship (projection) |
| contextual tuple | Delegation context (ephemeral) |
## Open Questions
- Should canon document standard OpenFGA type patterns (org/team/resource) as
downstream recommendations only?
- How should principal identifiers be aligned with Account IDs vs. Authenticated
Subject `sub` values?
- Do conditional (CEL) relations require canonical Context as a first-class
projection?
- Should one Store always map 1:1 to a Tenant Scope?
## References
- OpenFGA documentation — https://openfga.dev/docs
- OpenFGA modeling guide — https://openfga.dev/docs/modeling
- OpenFGA configuration language — https://openfga.dev/docs/configuration-language

111
infospace/assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md Normal file
View file

@ -0,0 +1,111 @@
# Google Zanzibar ReBAC
## Source Type
Architecture pattern and research paper. Google Zanzibar (2019) defines
relationship-based access control at global scale.
## Domain
Relationship-based authorization, permission inheritance, and large-scale
access control graphs.
## Why This Source Matters
Zanzibar/OpenFGA-style relationship tuples are especially close to what
identity-canon needs for memberships, ownership, representation, delegation,
and tenant administration.
Zanzibar is the reference architecture for storing authorization facts as
subject-relation-object tuples with computed permission expansion.
## Key Concepts
- **Relation tuple**: `object#relation@subject` or `object#relation@subject#subject_relation`.
- **Object**: typed entity with namespace and ID (e.g., `document:readme`).
- **Subject**: user, group, or object acting through a relation.
- **Relation**: named edge type on an object type (owner, editor, viewer, member).
- **Userset rewrite**: computed relations via union, intersection, exclusion,
and arrow operators (e.g., parent->owner).
- **Namespace configuration**: schema defining object types, relations, and
rewrite rules.
- **Check API**: evaluate whether subject has relation to object.
- **Expand API**: enumerate subjects with relation to object.
- **zookie**: consistency token for read-after-write semantics.
- **Group as subject**: usersets allow group-like indirection in tuples.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Tuple | Stored authorization fact. |
| Object | Resource or entity being authorized. |
| Subject | Actor or userset granted a relation. |
| Relation | Named permission edge on object type. |
| Userset | Indirect subject reference via relation chain. |
| Namespace | Schema for object types and relations. |
| Check | Boolean permission query. |
| Expand | Enumerate authorized subjects. |
| owner / editor / viewer | Common relation names (deployment-specific). |
| parent relation | Hierarchical inheritance via rewrite rules. |
## Modeling Assumptions
- **Authorization facts are relationships**, not role assignments on users alone.
- **Subjects and objects are typed strings**, not rich identity records.
- **Inheritance is computed** from tuple graph via rewrite rules.
- **Identity provisioning is external**; Zanzibar stores authorization state only.
- **Groups are modeled as objects** with member relations, not as separate IAM groups.
- **Consistency matters** for distributed reads (zookie tokens).
- **No canonical person model**; subject IDs are opaque.
## Identity-Canon Implications
- Zanzibar **tuple** maps to **Relationship Tuple** (authorization projection).
- **Object** maps to **Authorization Resource** projection.
- **Subject** maps to **Authorization Principal** projection.
- **Relation** maps to typed **Relationship** with authorization implication.
- **Namespace** maps to **Authorization Domain** Scope.
- **Userset rewrite** is authorization engine logic, not canonical identity.
- Membership tuples (`group:eng#member@user:alice`) parallel **Membership
Relationship** but live in authz layer.
- Supports S05 (admin delegation), S08 (moderator relations), S10 (service
account acting for org via tuple).
## Terminology Conflicts
- **Subject**: Zanzibar subject is authz participant; OIDC subject is identifier.
- **Object**: Zanzibar object is authz resource; grammar object ≠ domain object.
- **Relation vs. Relationship**: Zanzibar relation is permission edge; canon
Relationship is broader (social, legal, operational).
- **Member**: Zanzibar member relation on group object ≠ social membership.
- **User**: Zanzibar user ID is opaque; no person/account distinction.
## Candidate Canonical Mappings
| Zanzibar concept | Candidate canonical concept |
| --- | --- |
| Relation tuple | Relationship Tuple (authorization projection) |
| Object | Authorization Resource |
| Subject | Authorization Principal |
| Relation name | Relationship type (authz-implied) |
| Namespace config | Authorization Domain Scope |
| Group object + member | Group + Membership (authz projection) |
| Userset rewrite | Authorization engine derivation (non-canonical) |
| zookie | Consistency metadata (operational) |
## Open Questions
- Should canonical Membership Relationship be shared between identity and
authz layers, or always projected into tuples?
- How should representation/delegation map to Zanzibar relations vs. identity-layer
Representation Relationship?
- Should object namespace prefixes map to Scope identifiers?
- When does a social Following relationship warrant an authz tuple vs. remain
identity-only?
## References
- Google Zanzibar paper — https://research.google/pubs/pub48190/
- Zanzibar ACL language (related) — referenced in paper §2
- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs

183
infospace/assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md Normal file
View file

@ -0,0 +1,183 @@
# Beneficial Ownership — CDD, BOI, and KYC Modeling
## Source Type
Regulatory framework synthesis. FinCEN CDD Rule (31 CFR 1010.230), Corporate
Transparency Act / BOI reporting, FATF Recommendation 24, and KYC industry
practice.
## Domain
Beneficial ownership identification for legal entity customers — financial
institution due diligence, government transparency registries, and regulated
commercial onboarding.
## Why This Source Matters
Beneficial ownership is the regulatory answer to "who really controls this
legal entity customer?" It is **not** the same as corporate parent ownership
(LEI Level 2), operational resource ownership (Cerbos), or CRM account hierarchy.
Regulators impose **two independent prongs** (equity and control), trust
look-through rules, nominee prohibitions, and evidence retention — all scoped
to **counterparty risk**, not general graph semantics.
## Key Concepts
### FinCEN CDD Rule (customer due diligence)
- **Legal entity customer**: corporations, LLCs, general partnerships, and
similar entities opening accounts at covered financial institutions.
- **Beneficial owner — ownership prong**: each individual who directly or
indirectly owns **25% or more** of equity interests.
- **Beneficial owner — control prong**: a **single** individual with significant
responsibility to control, manage, or direct the legal entity (e.g., CEO,
CFO, managing member, general partner, president).
- **Collection at account opening**: identify and verify BO identities when a
new account opens (with 2026 exceptive relief allowing reuse after first
account unless risk triggers update).
- **Nominee prohibition**: legal entity must identify **ultimate** beneficial
owners, not nominees or straw men.
- **Trust look-through**: when a trust owns 25%+ equity, identify natural persons
behind the trust (settlor, trustees, beneficiaries as applicable); a legal
entity trustee does **not** satisfy the ownership prong — natural persons must
be identified.
- **Risk-based updates**: ongoing CDD may require BO refresh on triggering
events, not only at opening.
- **CIP alignment**: BO verification procedures must contain CIP-equivalent
elements for individuals but are not identical to the institution's CIP.
### BOI / Corporate Transparency Act (entity reporting)
- **Distinct from CDD**: BOI is a **filing obligation on reporting companies**
to FinCEN's BOI registry, not a financial-institution collection rule.
- **Reporting company beneficial owner**: similar dual-prong concept (substantial
ownership + substantial control) with FinCEN ID for individuals.
- **US regulatory volatility (2025–2026)**: interim final rules and litigation
have substantially narrowed or suspended BOI reporting for many US domestic
entities. **CDD beneficial ownership collection by financial institutions
remains in force** for covered institutions regardless of BOI reporting shifts.
- **Foreign entities**: BOI and transparency expectations remain more relevant
for non-US reporting companies and cross-border KYC.
### FATF Recommendation 24
- Requires countries to ensure adequate, accurate, and up-to-date **beneficial
ownership information** on legal persons, accessible to competent authorities.
- Supports **multi-prong** definitions (ownership threshold + control) and
look-through for complex structures (trusts, nominees, layered ownership).
- Drives national registries and financial-sector CDD alignment globally.
### KYC practice overlay
- Institutions may adopt **lower equity thresholds** for high-risk customers
(e.g., 10%) under AML program risk policies.
- **PEP screening** applies to beneficial owners, not only account signers.
- **Sanctions screening** (OFAC) must cover identified beneficial owners.
- BO evidence retained for years after relationship ends (BSA record retention).
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Beneficial owner | Natural person owning 25%+ or exercising substantial control. |
| Ownership prong | Equity-interest threshold test. |
| Control prong | Significant management/control responsibility test. |
| Legal entity customer | Entity opening a financial account subject to CDD. |
| CDD Rule | FinCEN customer due diligence requirements (2016, amended). |
| BOI / CTA | Corporate Transparency Act beneficial ownership information reporting. |
| FinCEN ID | Individual identifier for BOI filers. |
| Nominee / straw man | Non-ultimate owner; prohibited as BO response under CDD. |
| Look-through | Identifying natural persons behind trusts or intermediary entities. |
## Modeling Assumptions
- **Beneficial ownership is relationship semantics**, not a new actor type.
The natural person remains **Natural Person**; the assertion is regulatory.
- **Ownership prong and control prong are orthogonal** — one person may satisfy
both, and multiple persons may satisfy ownership prong while exactly one
control-prong person is required under US CDD.
- **Beneficial ownership ≠ corporate parent ownership** (LEI Level 2 describes
corporate structure; BO describes natural persons behind a customer entity).
- **Beneficial ownership ≠ Representation** (authorized signers may represent
without being beneficial owners).
- **Lifecycle is risk-triggered**, not merely account-open/close.
- **Regulatory regime is a scope dimension** — US CDD, EU AMLD, FATF R24, and
BOI filing may differ; canon models the relationship, downstream applies law.
## Identity-Canon Implications
### Resolved: dedicated relationship type
**Beneficial Ownership Relationship** is a first-class relationship type — **not**
an Ownership subtype with `beneficial` metadata.
**Rationale:**
| Concern | Why not Ownership subtype |
| --- | --- |
| Semantic collision | Ownership in canon covers records, tenants, resources, corporate parents — not regulated natural-person BO. |
| Dual prongs | Ownership prong (%) and control prong (role) are regulatory-specific; corporate Ownership edges lack this structure. |
| Trust look-through | Requires intermediary entity traversal metadata absent from generic Ownership. |
| Evidence & scope | BO ties to CDD/AML Evidence Source, Commercial Relationship, and jurisdictional scope — distinct lifecycle from LEI parent edges. |
| Projection safety | Prevents Cerbos/Zanzibar "owner" tuples from silently implying KYC beneficial owner compliance. |
**Beneficial Owner** remains a glossary label for the **natural person** who is
the target of a Beneficial Ownership Relationship — not a participation root.
### Recommended relationship fields
- `relationship_type`: `beneficial_ownership`
- `source`: Natural Person
- `target`: Organization / Legal Entity (the legal entity **customer**)
- `scope`: jurisdiction + institution/program (e.g., US CDD, EU AMLD)
- `ownership_prong`: boolean
- `control_prong`: boolean
- `equity_percentage`: optional numeric (when ownership prong)
- `control_basis`: optional enum (e.g., `ceo`, `managing_member`, `general_partner`)
- `intermediary_chain`: optional ordered list for trust/entity look-through
- `evidence_reference`: CDD certification, BOI filing, registry extract
- `lifecycle_state`: proposed, active, superseded, revoked
- `regulatory_basis`: optional reference (CDD Rule, FATF R24, national statute)
### Mapping table
| Source concept | Canonical mapping |
| --- | --- |
| Beneficial owner (person) | Natural Person |
| BO linkage | Beneficial Ownership Relationship |
| CDD certification | Evidence Source |
| Legal entity customer | Organization / Legal Entity + Commercial Relationship |
| BOI filing record | Evidence Source (registry) on Legal Entity |
| FinCEN ID | Identifier (government registry) on Natural Person |
| PEP/sanctions hit on BO | Lifecycle State / Trust Relationship on BO relationship |
| LEI Level 2 parent | Ownership Relationship (corporate structure — separate) |
## Terminology Conflicts
- **Beneficial owner (CDD)** vs. **beneficial owner (BOI filing)** vs.
**beneficial owner (transparency registry)**: same conceptual person, different
regulatory scopes and evidence — use `scope` and `regulatory_basis` metadata.
- **Owner (Cerbos resource)** vs. **beneficial owner**: authorization attribute
vs. regulated natural-person linkage.
- **Shareholder** vs. **beneficial owner**: not all shareholders meet BO thresholds;
control prong may identify non-shareholders.
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- `control_basis` enum — jurisdiction-neutral role codes + `regulatory_basis`.
- FinCEN ID → **Registry Identifier** on Natural Person.
- Exempt entities → **Beneficial Ownership Exemption** Evidence (not absence).
- BOI filing volatility separated from CDD Beneficial Ownership Relationships.
## References
- FinCEN, CDD Rule FAQs — https://www.fincen.gov/resources/statutes-and-regulations/cdd-rule-faqs
- FinCEN, CDD Final Rule — https://www.fincen.gov/resources/statutes-regulations/cdd-final-rule
- FinCEN, Account Opening Exceptive Relief Order (FIN-2026-R001) — https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf
- FATF, Recommendation 24 — https://www.fatf-gafi.org/en/topics/fatf-recommendations.html
- Open Ownership, reliable identifiers for corporate vehicles — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
- Internal: `kyc-aml-commercial-identity-binding.md`, `lei-gleif-legal-entity-identifier.md`

240
infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md Normal file
View file

@ -0,0 +1,240 @@
# Commercial Identity Nuance Settlement (2026)
## Source Type
identity-canon adjudication note — resolves remaining open questions and
"remaining nuance" items across the commercial-identity research stack.
## Domain
Standard enums, cross-registry linking rules, regulatory layering, and adapter
guidance for commercial identity edge cases.
## Beneficial Ownership Nuances
### `control_basis` enum (settled)
Use a **jurisdiction-neutral role code** on Beneficial Ownership Relationship,
plus `regulatory_basis` for program-specific rules.
| `control_basis` | Typical sources |
| --- | --- |
| `senior_managing_official` | FATF generic; US CDD control prong when no other role fits |
| `chief_executive` | CEO, managing director, president, executive director |
| `chief_financial` | CFO, treasurer with control |
| `managing_member` | LLC managing member |
| `general_partner` | Partnership general partner |
| `board_chair` | Chair with operational control |
| `trustee` | Trust with management control |
| `settlor_with_control` | Settlor retaining control over trust |
| `other_control` | Catch-all — require `control_basis_detail` free text |
`regulatory_basis` values: `us_cdd`, `us_boi_cta`, `eu_amld`, `fatf_r24`, `national_statute`.
US CDD "significant responsibility to control, manage, or direct" maps to the
most specific code available, else `senior_managing_official`. EU AMLD "senior
managing official" maps directly. Store **one** control-prong person per US CDD
rule; multiple ownership-prong persons allowed.
### FinCEN ID (settled)
FinCEN ID for BOI filers maps to **Registry Identifier**:
- `authority_class: government_registry`
- `scheme: fincen_individual_id` (or jurisdiction-specific extension)
- `jurisdiction: US`
- Attached to **Natural Person**, not Organization.
### Exempt legal entity customers (settled)
Do not rely on absence of Beneficial Ownership Relationships. Record explicit
**Beneficial Ownership Exemption** as **Evidence Source** on the Legal Entity /
Organization with:
- `exemption_type`: `publicly_traded`, `government_entity`, `regulated_financial_institution`, `subsidiary_of_exempt_parent`, `other`
- `regulatory_basis`, `evidence_reference`, `lifecycle_state`
Absence alone is ambiguous (not collected vs. exempt vs. not applicable).
### BOI filing volatility vs. CDD (settled)
Separate regulatory layers in canon — do not merge:
| Layer | Canon artifact | Volatility |
| --- | --- | --- |
| CDD beneficial ownership | Beneficial Ownership Relationship | Stable for covered FIs; collection obligation endures |
| BOI registry filing | Evidence Source (`evidence_type: boi_filing`) | Jurisdiction-dependent; track lifecycle downstream |
| Transparency registry | Evidence Source (`evidence_type: bo_registry_extract`) | Per national register |
Canon does not prescribe legal outcomes; downstream adapters apply current statute.
CDD relationships remain even when BOI filing requirements change.
## Registry Identifier Nuances
### `authority_class` extension (settled)
Add `industry_association` for identifiers issued by trade, standards, or
procurement bodies without government incorporation authority:
- NCAGE / CAGE (defense supplier ID)
- GS1 GLN when used as organization/location key in supply chain
Retain `government_registry`, `regulatory_global`, `commercial_proxy`, `tax`.
### Cross-registry Synonymity strength (settled)
| Link | Default strength | Notes |
| --- | --- | --- |
| LEI ↔ national company reg / ALEI | **strong** | Same legal entity when LOU or government register confirms |
| LEI ↔ UEI | **strong** | When SAM.gov or authoritative crosswalk confirms |
| LEI ↔ DUNS | **medium** | D&B may assign per location; proxy authority |
| DUNS ↔ UEI | **medium** | Historical procurement migration |
| DUNS ↔ company reg | **medium** | Branch/location mismatch common |
| company reg ↔ ALEI | **authoritative** | Same register encoding |
Use `relation_type: same_as` when strength is strong or authoritative;
`linked_to` for medium. Require `evidence_reference` (crosswalk, operator verify).
### ISO 6523 OPI / branch modeling (settled)
ISO 6523 **organization part identifier (OPI)** models a **branch or org unit**,
not a separate legal entity by default:
- Store OPI on **Registry Identifier** as optional `organization_part_id`.
- Map branch to **Organization Unit** (Group specialization) or child **Organization**
when operationally distinct.
- Branch DUNS + parent LEI: link branch Proxy Commercial Identifier to parent
Organization via structural relationship; Synonymity Assertion (medium) between
branch DUNS and parent LEI when same legal entity confirmed.
## Reputation and Assurance Nuances
### `assurance_tier` vs. numeric score (settled)
**Primary:** `assurance_tier` enum (`opinion` | `observed` | `committed` | `adjudicated`).
**Optional:** `numeric_score` + `score_scale` on Evidence Source for downstream
(e.g., PAYDEX 0–100, star rating 1–5). Downstream maps score ranges to tiers;
canon does not merge tiers from scores alone.
### Platform escrow without separate contract (settled)
Segregated escrow with defined release conditions is **committed** tier:
- Model **Commercial Commitment** `commitment_type: escrow`
- Evidence Source: platform escrow terms, payment-provider escrow object, or
marketplace buyer-protection policy accepted at transaction time
- Funds segregation + conditional release = commitment, not merely observed metric
### Cross-platform reputation portability (settled)
Portable reputation uses **Synonymity Assertion** between **Reputation Signal**
Evidence Sources:
- Default `relation_type: linked_to` (not `same_as`)
- Default strength: **weak**
- Upgrade to medium only with verified identity bridge (same Natural Person proof,
verified purchase on both platforms, operator confirmation)
- Require `portability_evidence` reference; scope must list both platforms
### Smart-contract / oracle outcomes (settled)
| Outcome type | Tier | Canon |
| --- | --- | --- |
| On-chain condition check (oracle, escrow release) | observed | Performance Evidence |
| Binding ADR with identified parties (incl. on-chain tribunal with published rules) | adjudicated | Adjudication Outcome |
| Court judgment enforced on-chain | adjudicated | Adjudication Outcome |
Automation alone does not elevate to adjudicated without identifiable dispute
authority and parties.
## Payment Nuances
### Network tokens e.g. Visa VTS (settled)
Network tokens map to **Payment Instrument Reference**:
- `instrument_type: network_token`
- `network_token_service` (e.g., `visa_vts`, `mastercard_mdes`)
- Same lifecycle and PCI boundary as `pm_xxx` references
### Shared payment methods across org customers (settled)
One Payment Instrument Reference may attach to **multiple Commercial Records**
within the same payment-provider org **Scope**:
- `sharing_scope: payment_provider_org`
- `shared_across_records: [commercial_record_ids]`
- Do not Synonymity-merge Commercial Records — only share the instrument reference
### Customer wallet balance (settled)
Provider ledger balance (Stripe Customer balance) is a **Commercial Record**
attribute `provider_ledger_balance` — not a Credential, not a Commercial Commitment.
Currency and provider scope required.
## CRM and Pipeline Nuances
### `binding_trigger` enum (settled)
| Value | Commitment state | Typical evidence |
| --- | --- | --- |
| `quote_accepted` | proposed | CPQ acceptance, e-sign |
| `loi_signed` | proposed | Signed LOI |
| `purchase_order_executed` | active | PO record |
| `contract_executed` | active | Signed agreement |
| `subscription_activated` | active | Billing webhook |
| `regulatory_onboarding_complete` | active | KYC/KYB completion |
| `org_policy_closed_won` | active only if org maps Closed Won → executed contract **and** policy documented as Evidence |
`org_policy_closed_won` is downstream-configured; canon requires explicit Evidence.
### Renewal Opportunity (settled)
| Situation | Canon treatment |
| --- | --- |
| Renewal on existing contract (same agreement extended) | **Commitment amendment** Evidence on existing Commercial Commitment; optional Pipeline Pursuit for forecast tracking |
| Competitive rebid / new agreement cycle | New **Pipeline Pursuit** |
| Material term change | Commitment amendment + may create Pipeline Pursuit |
Rule: if `amends_commitment_id` is set and change type is `renewal` or `amendment`,
do not create a new root Commercial Commitment unless terms are net-new contract.
### Partner vs. customer Opportunity (settled)
Same **Pipeline Pursuit** type with `pursuit_role`:
- `customer` (default)
- `partner` (channel, alliance)
- `vendor` (reverse sourcing)
Role affects **Commercial Relationship** typing, not Pipeline Pursuit structure.
### Person Account adapter guidance (settled)
Salesforce Person Account and similar B2C shortcuts:
- **Canon storage:** Natural Person + Commercial Record (split layers)
- **Adapter projection:** `projection_mode: person_account_combined` on export only
- Do not introduce Person Account as canonical root; discourage unified tables in
downstream schema without layer tags
## eIDAS / EUDI Nuances (commercial stack)
### Qualified electronic seal (settled)
Maps to **Credential** with `credential_type: qualified_seal`, bound to
**Organization** / **Legal Entity** through **Representation Relationship**
(signing officer or mandated agent). Distinct from login Credential.
### EUDI organizational wallet Scope (settled)
Organizational wallet is a **Scope** specialization (`wallet_scope`) holding
wallet-hosted **Credentials** and **Claims** — not a **Tenant** (no admin
isolation semantics). Link wallet Scope to **Commercial Record** and Organization
actor via Commercial Relationship.
## References
All prior commercial-identity source notes. This note supersedes their Open
Questions sections where marked settled below.

153
infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md Normal file
View file

@ -0,0 +1,153 @@
# Commercial Identity Synthesis
## Source Type
identity-canon research synthesis connecting commercial theory, law, regulation,
and software practice to the canonical model.
## Domain
Cross-cutting commercial identity — binding, trust, persistence, and layer separation.
## Why This Source Matters
This note captures the research prompt: **identity and commerce are tightly coupled
in practice**. Conceptual or login-only identity can remain fluid when no commercial
value or enforceable promises attach. **Commercial binding** increases an identity's
relevance to other actors and creates foundations for trust, shared information, and
durable relationships.
## The Binding Gradient
| Stage | Commercial stake | Identity behavior | Canon pattern |
| --- | --- | --- | --- |
| Anonymous browse | None | Fluid, discardable | Persona, ephemeral Identifier |
| Free trial / lead | Low | Pseudonymous, reversible | Account + weak Commercial Record |
| Paying subscriber | Medium | Stable tenant + billing ID | Organization + Tenant + Commercial Record |
| KYC/AML customer | High | Verified, monitored, retained | Commercial Record + Evidence + BO linkage |
| Regulated markets (LEI) | Very high | Renewed legal identity, ownership public | Legal Entity + LEI Identifier + Lifecycle |
| Contractual enterprise | High | Agency, seals, signatures | Commercial Commitment + Representation |
**Insight:** fluidity is not a bug — it is rational when commercial externalities are
absent. Binding is what makes identity **economically and legally salient**.
## Layer Model (Commercial + Identity)
```text
Actor Layer Natural Person, Organization, Legal Entity
Record Layer Account (access), Commercial Record (billing/CRM/regulatory)
Reference Layer Identifiers (LEI, DUNS, UEI, VAT, stripe_customer_id)
Relationship Layer Commercial Relationship, Representation, Ownership, Trust
Commitment Layer Commercial Commitment (contract, subscription, payment mandate)
Evidence Layer KYC files, credit history, registry extracts, qualified credentials
Projection Layer Auth Subject, Auth Principal (unchanged — not commercial roots)
```
Commerce does not replace identity layers; it **selectively hardens** them when
counterparties must rely, sue, invoice, or report.
## How Binding Creates Trust
From commercial theory and practice:
1. **Attribution**: counterparties know **who** bears liability (legal person, BO, agent).
2. **Commitment**: contracts, subscriptions, and payment authorizations create **costly exit**.
3. **Evidence**: KYC, LEI, registry credentials, and credit files provide **verifiable history**.
4. **Reputation / assurance**: tiered reliance from opinion signals (reviews) through
observed metrics (PAYDEX) to committed stakes (bonds) and adjudicated outcomes
(courts) — see **Counterparty Assurance Gradient**.
5. **Enforcement**: law of agency and contract makes promises **actionable** beyond platform ToS.
Trust Relationship in canon should often be **justified by** Commercial Relationship +
Commercial Commitment + Evidence, not declared ad hoc.
## Software Mirrors (Practical)
| System | Commercial artifact | Identity separation lesson |
| --- | --- | --- |
| Stripe | Customer | Billing ≠ login |
| Salesforce | Account / Contact | CRM ≠ User |
| Auth0/Stytch | Organization / Member | Subscriber ≠ billing record |
| KYC platforms | Customer profile + BO | Regulated counterparty ≠ session |
| GLEIF | LEI | Legal entity ID for markets |
| D&B | DUNS + PAYDEX | Credit identity + reputation |
| eIDAS/EUDI | Legal person wallet | Qualified org credentials |
## Canon Decisions From This Research
### Rejected
- **Customer Account** as canonical type (overloads layers).
### Added / strengthened
- **Commercial Record** — billing, CRM, regulatory counterparty records.
- **Commercial Relationship** — vendor/customer commercial link.
- **Commercial Commitment** — enforceable or costly promise binding parties (contract,
subscription, payment mandate, regulatory onboarding acceptance).
- **Beneficial Ownership Relationship** — dedicated type from Natural Person to
Organization/Legal Entity for KYC/CDD (not Ownership subtype).
- **Registry Identifier** and **Proxy Commercial Identifier** — Reference layer
subtypes with authority class, ICD scheme, and renewal lifecycle.
- **Counterparty Assurance Gradient** — opinion → observed → committed →
adjudicated; Reputation Signal, Performance Evidence, Adjudication Outcome.
- **Payment Instrument Reference** + **Payment Mandate** — PCI boundary; not Credential.
- **Pipeline Pursuit** — CRM Opportunity before Commercial Commitment promotion.
### Unchanged roots
- **Actor** remains participation root.
- **Account** remains operational access record.
- Login, authz, and social layers unchanged; commerce **binds** them when stakes require.
## Fluid ↔ Bound Transitions
Model as lifecycle events, not silent merges:
- Lead → Account (CRM conversion): weak → medium evidence.
- Opportunity opened: Pipeline Pursuit — not Commercial Commitment until binding trigger.
- Trial → paid subscription: Commercial Commitment (subscription) + Payment Mandate
+ Payment Instrument Reference.
- Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
- Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.
## Scenario Impact
- **S04 (vendor/customer tenants)**: add Commercial Record per customer tenant, Commercial
Commitment for subscription/contract.
- **S14 (pseudonymous profile)**: incompatible with active Commercial Commitment unless
explicitly scoped (e.g., marketplace escrow with privacy partition).
- **S15 (legal entity + tenants)**: LEI/registry Identifier + Commercial Record + renewals.
## Research Gaps
- Smart contracts and automated Commercial Commitment lifecycle (implementation patterns).
- National statute variants beyond settled enum baselines (downstream legal config).
## Nuance settlement
Commercial identity edge-case enums and linking rules are consolidated in
`commercial-identity-nuance-settlement.md` (2026).
## Source Notes in This Stack
- `commercial-trust-binding-theory.md`
- `legal-person-agency-contract.md`
- `lei-gleif-legal-entity-identifier.md`
- `duns-commercial-credit-identity.md`
- `kyc-aml-commercial-identity-binding.md`
- `eidas-eudi-legal-person-wallet.md`
- `salesforce-crm-commercial-record.md`
- `beneficial-ownership-kyc-boi.md`
- `registry-identifier-subtypes.md`
- `reputation-assurance-gradient.md`
- `payment-credential-pci-boundary.md`
- `crm-pipeline-commitment-threshold.md`
- `commercial-identity-nuance-settlement.md`
- `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
- `../commercial-subscription/stripe-customer-billing.md`
## References
See individual source notes. Primary external anchors: GLEIF/ISO 17442, FinCEN CIP,
EU eIDAS, D&B DUNS, Salesforce Account model, Auth0/Stytch org tenancy, FATF digital identity.

119
infospace/assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md Normal file
View file

@ -0,0 +1,119 @@
# Commercial Trust and Identity Binding Theory
## Source Type
Academic and industry synthesis. Transaction-cost economics, contract performance
literature, digital trust research, and identity-canon conceptual framing.
## Domain
Commercial theory, trust formation, identity persistence, and the economic
function of binding commitments.
## Why This Source Matters
Practitioners often treat login identity and billing identity as separate
accidents of software architecture. Commercial theory suggests a deeper
pattern: **commercially unbound identities stay fluid**; **commercially bound
identities become durable points of coordination** for trust, information
sharing, and enforceable promises.
## Key Concepts
- **Fluid identity**: participation with low exit cost and weak external reliance;
pseudonymous handles, trial accounts, anonymous browsing.
- **Commercial binding**: attachment of economic or legal obligation to an
identity representation (payment authorization, contract, subscription, KYC
onboarding, credit exposure).
- **Reputation capital**: value accumulated when past performance is observable
and attributable to a stable identity.
- **Transaction costs**: search, bargaining, monitoring, and enforcement costs
that trust mechanisms reduce (Williamson, Coase tradition).
- **Contract performance assurance**: market and legal mechanisms ensuring
parties keep promises (bonding, hostages, repeat play, legal enforcement).
- **Transient trust**: short-lived trust between previously unknown parties
enabled by verified credentials and real-time assurance (EU digital wallet
discourse).
- **Perpetual master data**: continuous re-validation of enterprise identity
attributes once commercial relationships depend on accuracy (KYC/KYB, LEI
renewal).
- **Counterparty risk**: commercial exposure to wrong or misidentified party;
drives identity rigor.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Binding | Attachment of enforceable or costly-to-break obligation. |
| Commitment | Promise backed by legal, financial, or reputational stake. |
| Trust | Willingness to rely on another party under uncertainty. |
| Reputation | Observable history attributed to an identity. |
| Fluid identity | Low-stakes, easily abandoned or rotated representation. |
| Bound identity | Identity whose change imposes cost on self or counterparties. |
| Assurance | Mechanism increasing confidence in performance or identity. |
| Counterparty | Other party in a commercial transaction. |
## Modeling Assumptions
- Identity relevance scales with **stakes of reliance** by other parties.
- Without commercial binding, actors optimize for **low friction and privacy**
(fluid personas, ephemeral identifiers).
- Commercial activity introduces **attribution requirements** (who invoiced,
who signed, who is liable).
- Trust between commercial actors rests on **identity stability + evidence +
enforceable commitments**, not on profile richness alone.
- Digital systems separate layers (login, CRM, billing, KYC) but commercial
reality treats them as **one counterparty** when risk is integrated.
- Reputation and legal liability create **path dependence**: past bindings make
future identity changes costly (account migration, LEI renewal, contract novation).
## Identity-Canon Implications
- Distinguish **fluid participation** (Actor/Persona/Account with no commercial
commitment) from **commercially bound participation** (Commercial Record +
Commercial Relationship + Commercial Commitment).
- **Trust Relationship** in canon should often be **downstream of** Commercial
Relationship and evidenced commitments, not a substitute for them.
- **Synonymity Assertion** strength should rise when commercial counterparty
risk requires deterministic matching (KYC, LEI, registry ID).
- **Lifecycle State** on commercial artifacts gates access and trust (subscription
active, delinquent, KYC expired, LEI lapsed).
- User insight formalized: conceptual identity without commercial binding may
remain intentionally fluid; binding increases **relevance to other commercial
actors** and justifies **stronger identifiers and promises**.
## Terminology Conflicts
- **Trust (social)** vs. **trust (commercial)**: following ≠ credit trust.
- **Identity (conceptual)** vs. **identity (counterparty)**: philosophy vs. KYC record.
- **Binding (technical)** vs. **binding (legal)**: OIDC binding ≠ contract.
- **Reputation (brand)** vs. **reputation (performance history)**: marketing vs. credit.
## Candidate Canonical Mappings
| Theory concept | Candidate canonical concept |
| --- | --- |
| Fluid identity | Persona / Scoped Identifier without Commercial Commitment |
| Commercial binding | Commercial Commitment on Commercial Relationship |
| Reputation capital | Performance Evidence history + Trust Relationship (assurance_basis) |
| Star ratings / reviews | Reputation Signal (opinion tier) |
| Counterparty identification | Commercial Record + Legal Entity + Identifiers |
| Contractual promise | Commercial Commitment (contract subtype) |
| Assurance mechanism | Assurance Level + Evidence Source |
| Transient trust | Trust Relationship with short lifecycle + VC/qualified ID |
| Perpetual MDM | Ongoing Evidence Source refresh on Commercial Record |
## Open Questions
- Should Commercial Commitment be a Relationship subclass or metadata on
Commercial Relationship?
- How should fluid-to-bound transitions be modeled (trial → paid, anonymous → KYC)?
- Resolved: tiered Evidence Source pattern — see `reputation-assurance-gradient.md`.
## References
- Klein and Leffler (1981), role of market forces in contractual performance
- Williamson, transaction cost economics (institutional trust)
- FATF Guidance on Digital Identity (trust frameworks for financial identity)
- Spherity/EUDI organizational wallet discourse on transient trust and perpetual MDM
- identity-canon ResearchSeed (trust, synonymity, evidence)

157
infospace/assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md Normal file
View file

@ -0,0 +1,157 @@
# CRM Pipeline and Commercial Commitment Threshold
## Source Type
Product data model and sales-operations synthesis. Salesforce Opportunity stages,
forecast categories, and contract-law binding thresholds.
## Domain
When CRM pipeline artifacts (Opportunity, deal stage, forecast) constitute
canonical **Commercial Commitment** vs. provisional pursuit evidence only.
## Why This Source Matters
Salesforce **Opportunity** tracks potential revenue — but most pipeline stages are
**forecasts**, not enforceable obligations. Treating every Opportunity as
Commercial Commitment would:
- falsely elevate identity binding during early prospecting;
- collide with **Counterparty Assurance Gradient** (pipeline ≠ committed tier);
- ignore that **Closed Won** often precedes executed contract in real orgs.
Canon needs a **promotion threshold** — when pipeline becomes commitment.
## Key Concepts
### Salesforce Opportunity model
- **Opportunity**: deal record tied to Account; amount, stage, close date, forecast.
- **Stage**: position in sales process (e.g., Prospecting → Proposal → Negotiation
→ Closed Won / Closed Lost).
- **Forecast category**: Pipeline, Best Case, Commit, Closed — revenue prediction
semantics, not legal commitment.
- **Closed Won**: deal marked won in CRM — operational signal; may or may not
coincide with signed contract depending on org process.
- **Closed Lost**: pursuit ended — no commitment.
- **Quote / Order** (CPQ): closer to binding when customer accepts quote or order
is placed — stronger evidence than early stage.
### Binding threshold (legal/commercial)
A **Commercial Commitment** requires evidenced obligation that raises counterparty
reliance — aligned with canon definition and tier 3 assurance:
| Signal | Binding strength | Canon treatment |
| --- | --- | --- |
| Lead created | None | Pipeline Pursuit or weak Commercial Record |
| Opportunity Prospecting | None | Pipeline Pursuit |
| Opportunity Proposal | Low | Pipeline Pursuit + stage Evidence |
| Signed quote / LOI | Medium | Commercial Commitment `proposed` |
| Executed PO / order | High | Commercial Commitment `active` |
| Closed Won (CRM only) | Org-dependent | `proposed` until contract Evidence |
| Signed MSA / SOW | High | Commercial Commitment `active` |
| Active subscription (Stripe) | High | Commercial Commitment `active` (billing) |
**Rule:** CRM stage alone is **never sufficient** for `active` Commercial Commitment
unless org policy equates Closed Won with executed agreement **and** that policy
is recorded as Evidence Source (downstream configuration).
### Fluid-to-bound transition
Lead → Account conversion raises commercial attribution (Organization +
Commercial Record). Opportunity creation adds **Pipeline Pursuit**. Commitment
materializes only at binding trigger — not at Opportunity create.
## Modeling Assumptions
- **Pipeline is prospective** — counterparties may rely for forecasting internally
but external legal reliance is limited until commitment artifacts exist.
- **Multiple Opportunities** per Account are normal; commitments may coexist.
- **Opportunity amount** is expected value, not obligation amount until contracted.
- **Forecast Commit category** (Salesforce) is sales-team confidence, not legal
commitment — do not map to Commercial Commitment `active`.
- **CPQ Quote accepted** or **e-signature completed** are valid binding triggers
with Evidence Source.
## Identity-Canon Implications
### Resolved: Opportunity is not Commercial Commitment by default
Map Salesforce **Opportunity** (and HubSpot deal, etc.) to **Pipeline Pursuit** —
Record layer artifact for in-flight commercial deal pursuit.
**Pipeline Pursuit** fields:
- `source_system` — Salesforce, HubSpot, etc.
- `stage` — vendor stage name (Prospecting, Negotiation, Closed Won, …)
- `forecast_category` — pipeline, best_case, commit, closed
- `expected_amount`, `expected_close_date`
- `linked_commercial_record` — CRM Account / Commercial Record
- `lifecycle_state` — open, won, lost, abandoned
- `binding_status` — `none` | `proposed` | `active` (derived from evidence, not stage alone)
### Promotion to Commercial Commitment
Create or activate **Commercial Commitment** only when `binding_trigger` satisfied:
| Trigger | Commitment state | Evidence |
| --- | --- | --- |
| Signed LOI / quote acceptance | `proposed` | Document, e-sign event |
| Executed PO / order | `active` | Order record |
| Closed Won + contract on file | `active` | Contract Evidence Source |
| Subscription checkout complete | `active` | Stripe webhook (billing) |
| Stage-only Closed Won | **No auto-promotion** | Pipeline Pursuit `won` only |
**Pipeline Pursuit** may **reference** a Commercial Commitment once promoted;
do not replace Opportunity with commitment in CRM adapters — mirror both.
### What Opportunity stage provides
Stage changes produce **Evidence Source** events on Pipeline Pursuit (observed
tier — internal sales telemetry). They support **Trust Relationship** only for
**internal** vendor forecasting, not external counterparty assurance at tier 3.
### Lead and Account (unchanged)
- **Lead** → provisional prospect (weak Commercial Record or Pipeline Pursuit seed).
- **Account** → **Commercial Record** + Organization.
- **Opportunity** → **Pipeline Pursuit** (not Commercial Commitment).
## Terminology Conflicts
- **Opportunity (CRM)** vs. **Commercial Commitment**: forecast vs. obligation.
- **Forecast Commit (Salesforce)** vs. **Commercial Commitment (canon)**: homonym disaster.
- **Closed Won** vs. **contract signed**: CRM ops vs. legal binding.
- **Deal (informal)** vs. **Pipeline Pursuit**: resolve to Pipeline Pursuit.
## Candidate Canonical Mappings
| CRM concept | Canonical mapping |
| --- | --- |
| Account | Commercial Record + Organization |
| Contact | Natural Person |
| Lead | Pipeline Pursuit (seed) / weak Commercial Record |
| Opportunity | Pipeline Pursuit |
| Stage change | Evidence Source on Pipeline Pursuit |
| Quote accepted | Commercial Commitment `proposed` |
| Order / contract executed | Commercial Commitment `active` |
| Closed Lost | Pipeline Pursuit lifecycle `lost` |
| Forecast category "Commit" | Pipeline Pursuit metadata only |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- `binding_trigger` enum — seven values including `org_policy_closed_won`.
- Renewal on same contract → commitment amendment; rebid → new Pipeline Pursuit.
- `pursuit_role`: customer | partner | vendor on Pipeline Pursuit.
## References
- Salesforce Opportunity object — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm
- Shellblack, Salesforce data model overview — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
- Internal: `salesforce-crm-commercial-record.md`, `commercial-identity-synthesis.md`,
`reputation-assurance-gradient.md`, `legal-person-agency-contract.md`

91
infospace/assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md Normal file
View file

@ -0,0 +1,91 @@
# DUNS and Commercial Credit Identity
## Source Type
Industry registry. Dun & Bradstreet Data Universal Numbering System (D-U-N-S).
## Domain
Commercial credit, vendor onboarding, procurement identity, and business verification.
## Why This Source Matters
DUNS predates LEI as a global commercial identifier for **business entities** in
trade and credit. It ties identity to **creditworthiness and payment behavior**
(PAYDEX), illustrating how commercial activity creates durable, high-stakes identity
interest among counterparties.
## Key Concepts
- **DUNS number**: nine-digit proprietary identifier for a business location/entity.
- **D&B database**: 300M+ business records; global trade and procurement usage.
- **Business entity**: company or location receiving DUNS; not a natural person.
- **PAYDEX score**: D&B payment performance score (credit behavior).
- **Credit file**: aggregated commercial history attributed to DUNS.
- **Government procurement**: historically required DUNS (US); migrated to SAM UEI.
- **UEI (Unique Entity Identifier)**: US federal successor identifier in SAM.gov.
- **ISO/IEC 6523 ICD 0060**: standard representation for DUNS in ISO identifiers.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| DUNS / D-U-N-S | D&B business identifier. |
| Business entity | Company or site in D&B registry. |
| PAYDEX | Payment performance score. |
| Credit file | Commercial history record. |
| UEI | US government unique entity ID (SAM.gov). |
| Vendor onboarding | Procurement verification using DUNS/UEI. |
| Headquarters vs. branch | Separate DUNS per distinct business location. |
## Modeling Assumptions
- **Commercial identity serves credit and procurement**, not authentication.
- **Payment history feeds reputation** attributable to identifier.
- **Multiple national ID schemes** (DUNS, UEI, LEI, VAT, company reg) coexist; linking
requires Synonymity Assertion or registry crosswalk.
- **Identifier assignment is vendor-operated** (D&B), not self-asserted.
- **Commercial counterparties rely on DUNS** for risk decisions beyond bare legal existence.
## Identity-Canon Implications
- DUNS maps to **Proxy Commercial Identifier** (`scheme: 0060`,
`authority_class: commercial_proxy`) on **Commercial Record** / **Organization**.
- PAYDEX and credit file map to **Evidence Source** influencing **Trust Relationship**
and counterparty risk.
- UEI maps to **Identifier** (government authoritative) on Commercial Record.
- Illustrates user thesis: once credit exposure exists, identity becomes **economically
binding** and **reputationally persistent**.
- Link to LEI via Synonymity Assertion when same legal entity holds both.
## Terminology Conflicts
- **DUNS** vs. **LEI**: credit/procurement vs. financial regulatory identifier.
- **Business entity (D&B)** vs. **Tenant**: vendor record ≠ SaaS isolation.
- **Customer (credit)** vs. **Customer (role)**: credit customer vs. relationship role.
## Candidate Canonical Mappings
| D&B / procurement concept | Candidate canonical concept |
| --- | --- |
| DUNS number | Proxy Commercial Identifier (ICD 0060) |
| D&B business record | Commercial Record |
| PAYDEX | Evidence Source (credit performance) |
| UEI | Identifier (government registry) |
| Vendor onboarding check | Trust Relationship + Evidence Source |
| Parent/branch linkage | Organization structure Relationship |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- PAYDEX → Performance Evidence; `numeric_score` optional; tier enum primary.
- LEI↔DUNS Synonymity default **medium**.
## References
- Dun & Bradstreet DUNS — https://www.dnb.com/duns-number.html
- Wikipedia, Data Universal Numbering System — https://en.wikipedia.org/wiki/Data_Universal_Numbering_System
- GSA Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update

102
infospace/assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md Normal file
View file

@ -0,0 +1,102 @@
# eIDAS and EUDI Wallet for Legal Persons
## Source Type
Regulatory framework and industry analysis. EU eIDAS Regulation, eIDAS 2.0 / EUDI
Wallet, European Business Wallet (organizational wallet) initiatives.
## Domain
EU digital identity, qualified trust services, legal person credentials, and
cross-border commercial trust.
## Why This Source Matters
eIDAS bridges **legal identity** and **commercial trust** at EU scale: electronic
signatures, seals, timestamps, and (via EUDI) wallets for natural and **legal
persons** carrying verifiable credentials for B2B and B2G exchange.
## Key Concepts
- **eIDAS**: EU regulation for electronic identification and trust services.
- **eID (electronic identification)**: national schemes with mutual recognition.
- **Qualified trust services**: legally recognized signatures, seals, timestamps, etc.
- **Electronic seal**: legal-entity counterpart to personal e-signature.
- **EUDI Wallet**: European Digital Identity Wallet for citizens (eIDAS 2.0).
- **Organizational / legal person wallet**: extension for companies (EUBW discourse).
- **Verifiable credential (EU context)**: credentials in wallet (licenses, compliance certs).
- **Transient trust**: real-time verified trust between unknown parties via credentials.
- **KYB/KYS**: Know Your Business / Supplier via registry-sourced credentials.
- **Delegation of rights**: organizational members present credentials on behalf of legal person.
- **Authorization chains**: parent-subsidiary credential issuance hierarchies.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| eIDAS | EU trust framework regulation. |
| Qualified signature/seal | Highest assurance trust service. |
| Legal person | Company or organization under law. |
| EUDI Wallet | EU digital identity wallet. |
| Organizational wallet | Wallet for legal person credentials. |
| Electronic seal | Entity-level signing mechanism. |
| Trust service provider | TSP issuing qualified services. |
| Verifiable credential | Attested claim in wallet. |
## Modeling Assumptions
- **Natural person and legal person wallets differ materially** — org wallets need
delegation, hierarchy, API integration, higher volume.
- **Legal person acts through representatives** with scoped credentials (aligns with agency law).
- **Qualified services carry legal equivalence** to paper in EU cross-border context.
- **Registry-sourced credentials** (e.g., company register) anchor commercial identity to authority.
- **Commercial binding increases** when seals/signatures and compliance credentials are used.
- **Citizen wallet stack cannot be naively copied** for organizational use cases.
## Identity-Canon Implications
- Legal person wallet maps to **Organization/Legal Entity** + **Commercial Record** +
**Credential** (qualified seal) + **Claim** set.
- Representative presenting org credential maps to **Representation Relationship**
with scoped **Delegation**.
- Registry-issued credential maps to **Claim** with government **Evidence Source**.
- Transient trust maps to **Trust Relationship** established at transaction time with
VC/qualified credential evidence.
- Supports user thesis: commercial credentials make identity **relevant and durable**
to counterparties across borders.
- Pairwise/pseudonymous identity insufficient for qualified seal; commercial binding
requires legal person resolution.
## Terminology Conflicts
- **Legal person (civil law)** vs. **Legal Entity (canon)**: legal person includes natural persons.
- **Digital identity (eIDAS)** vs. **Identity Record**: assured ID vs. directory record.
- **Trust service** vs. **Trust Relationship**: regulatory service vs. canon relationship.
## Candidate Canonical Mappings
| eIDAS/EUDI concept | Candidate canonical concept |
| --- | --- |
| Legal person | Organization / Legal Entity |
| Organizational wallet | Commercial Record + Credential store (Scope) |
| Electronic seal | Credential (entity signing) |
| Qualified certificate | Credential + Assurance Level |
| Member presenter | Natural Person + Representation |
| Registry credential | Claim + authoritative Evidence Source |
| KYB/KYS process | Commercial Relationship onboarding |
| Authorization chain | Delegation + org hierarchy Relationships |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- Qualified seal → **Credential** `credential_type: qualified_seal` via Representation.
- Org wallet → **Scope** `wallet_scope`, linked to Commercial Record — not Tenant.
## References
- EU eIDAS Regulation — https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
- EU EUDI Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
- Spherity, EUDI Wallet for legal persons — https://www.spherity.com/post/the-european-busienss-wallet-eubw-and-legal-person-identity-redefining-trust-in-the-eu-s-digital

105
infospace/assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md Normal file
View file

@ -0,0 +1,105 @@
# KYC AML and Commercial Identity Binding
## Source Type
Regulatory framework synthesis. USA PATRIOT Act CIP, FinCEN KYC/AML, FATF digital
identity guidance.
## Domain
Financial regulation, customer identification, beneficial ownership, and ongoing
commercial relationship monitoring.
## Why This Source Matters
KYC/AML is where governments **mandate** commercial identity binding: institutions
must verify who they transact with, retain evidence, and monitor behavior. This is
the strongest practical force turning fluid identities into **regulated,
high-stakes counterparty records**.
## Key Concepts
- **KYC (Know Your Customer)**: policies ensuring institutions know customers and risks.
- **AML (Anti-Money Laundering)**: broader program preventing illicit finance.
- **CIP (Customer Identification Program)**: US mandate to verify identity before account opening.
- **CDD (Customer Due Diligence)**: risk assessment of customer relationship.
- **EDD (Enhanced Due Diligence)**: heightened review for high-risk customers.
- **Beneficial owner (BO)**: natural persons owning/controlling legal entity customers
(historically 25% threshold; may be lowered for high risk).
- **Ongoing monitoring**: transaction surveillance after onboarding.
- **Record retention**: CIP records kept years after relationship ends.
- **Sanctions / PEP screening**: compare identities against government lists.
- **Digital identity (FATF)**: guidance on digital ID assurance for KYC.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| KYC | Know-your-customer compliance program. |
| CIP | Customer identification at onboarding. |
| Beneficial owner | Natural person behind legal entity customer. |
| PEP | Politically exposed person (elevated risk). |
| Due diligence | Risk-based identity and activity review. |
| Ongoing monitoring | Continued scrutiny of customer activity. |
| Risk profile | Customer risk classification. |
| FinCEN | US Financial Crimes Enforcement Network. |
## Modeling Assumptions
- **Commercial relationship triggers identity rigor** proportional to risk.
- **Legal entity customers require beneficial owner identification** — natural
persons bound to organization customers.
- **Identity verification is not one-time**; monitoring continues across lifecycle.
- **Evidence must be retained** even after account closure.
- **False identity has regulatory and criminal consequences** — binding is external,
not user preference.
- **Friction is accepted** where commercial stakes require it.
## Identity-Canon Implications
- KYC onboarding creates **Commercial Record** + **Commercial Commitment** (regulated
relationship) bound to **Natural Person** and/or **Organization/Legal Entity**.
- **Beneficial owner** maps to **Natural Person** linked via **Beneficial
Ownership Relationship** to Organization/Legal Entity customer (see
`beneficial-ownership-kyc-boi.md`).
- CIP evidence maps to **Evidence Source** with **Assurance Level**.
- Ongoing monitoring produces **Evidence Source** events affecting **Lifecycle State**
and **Trust Relationship**.
- Supports fluid-to-bound transition: anonymous lead → verified customer with retained proof.
- **Account** (bank/login) is insufficient alone; KYC binds the **counterparty**.
## Terminology Conflicts
- **Customer (KYC)** vs. **Customer (Stripe)** vs. **Customer (role)**: regulated
counterparty vs. billing object vs. commercial role.
- **CIP customer** vs. **Account holder**: verified party vs. access credential.
- **Digital identity** vs. **login identity**: assurance-ranked ID vs. session user.
## Candidate Canonical Mappings
| KYC/AML concept | Candidate canonical concept |
| --- | --- |
| Verified customer | Commercial Record + Actor binding |
| CIP evidence | Evidence Source |
| Beneficial owner | Natural Person + Beneficial Ownership Relationship |
| Risk profile | Assurance Level + metadata on Commercial Relationship |
| EDD review | Evidence Source (enhanced) |
| Sanctions hit | Lifecycle State / Trust Relationship revocation |
| Transaction alert | Evidence Source event |
| Record retention | Lifecycle/archival policy on Commercial Record |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- Beneficial Owner → **Beneficial Ownership Relationship**; `control_basis` enum;
CDD vs. BOI filing layered separately.
## References
- Thomson Reuters, Customer Identification Program overview — https://legal.thomsonreuters.com/blog/overview-customer-identification-program-cip/
- Okta KYC definition — https://www.okta.com/identity-101/kyc/
- FinCEN, USA PATRIOT Act Section 326 — https://www.fincen.gov/resources/statutes-regulations/usa-patriot-act
- FATF Guidance on Digital Identity — https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-on-Digital-Identity.html

111
infospace/assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md Normal file
View file

@ -0,0 +1,111 @@
# Legal Person, Agency, and Contract Binding
## Source Type
Legal doctrine synthesis. Common-law agency principles, contract privity, and
juridical person concepts used in commercial law.
## Domain
Commercial law foundations for representation, liability, and binding promises
between parties.
## Why This Source Matters
Commercial software models "accounts" and "organizations," but courts and
regulators reason about **principals, agents, legal persons, and contractual
obligations**. Agency law explains how organizations act through people and why
commercial identity must bind **liability**, not just login state.
## Key Concepts
- **Legal person**: entity recognized by law as holder of rights and duties;
includes natural persons and juridical persons (corporations, LLCs, etc.).
- **Juridical person**: organization recognized as legal person distinct from
members (corporation, association).
- **Principal**: party on whose behalf an agent acts.
- **Agent**: party authorized to act for principal and bind principal within scope.
- **Fiduciary duty**: agent's duty of loyalty and care to principal.
- **Actual authority**: express or implied permission granted to agent.
- **Apparent authority**: third party reasonably believes agent has authority
based on principal's conduct.
- **Agency by contract**: principal-agent relationship created by agreement
(employment, power of attorney, brokerage).
- **Contract**: agreement creating enforceable obligations; requires parties with
capacity.
- **Privity**: doctrine limiting contract rights/obligations to parties to the
contract (with modern statutory exceptions).
- **Representation**: agent acts **for** principal; principal may be bound by
authorized acts.
- **Termination**: agency ends by agreement, operation of law (death, bankruptcy),
or breach.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Principal | Party represented by agent. |
| Agent | Party acting on principal's behalf. |
| Legal person | Rights-bearing entity under law. |
| Juridical person | Non-human legal person (company). |
| Fiduciary | Trust-based duty relationship. |
| Power of attorney | Written agency authorization. |
| Binding | Creating legal obligation on a party. |
| Capacity | Legal ability to enter contracts. |
| Apparent authority | Authority as seen by third parties. |
## Modeling Assumptions
- **Organizations act only through agents** (officers, employees, representatives).
- **Commercial binding requires identifiable parties** with legal capacity.
- **Representation is contractual or statutory**, not merely technical (API token).
- **Principal liability** may attach to unauthorized acts if apparent authority exists.
- **Agency terminates**; commercial systems must model lifecycle and revocation.
- **Natural person ≠ company** even when sole proprietor; legal structure matters
for liability and contract.
## Identity-Canon Implications
- **Organization** collective actor maps to juridical person when legally recognized.
- **Natural Person** maps to natural-person legal person.
- **Representation Relationship** in canon aligns with agency (acts for).
- **Delegation Relationship** is narrower grant of authority; agency may be broader.
- **Commercial Commitment** (contracts, PO acceptance) binds **Legal Entity** or
**Organization** actors through **Representation** chains.
- Login **Account** does not create agency; employment or explicit authorization does.
- **Apparent authority** explains why enterprises must govern service accounts and
admin roles carefully (S05, S10, S11).
## Terminology Conflicts
- **Agent (legal)** vs. **Artificial Agent (canon)**: lawyer's agent ≠ AI agent;
overlap when AI acts under delegated authority.
- **Principal (legal)** vs. **Authorization Principal**: legal principal vs. Cedar principal.
- **Legal person** vs. **Legal Entity** in canon: legal person includes natural persons.
- **Account holder** vs. **contracting party**: bank account ≠ signatory authority.
## Candidate Canonical Mappings
| Legal concept | Candidate canonical concept |
| --- | --- |
| Natural person (legal) | Natural Person |
| Juridical person | Organization / Legal Entity |
| Principal | Organization or Natural Person (represented party) |
| Agent (human) | Natural Person + Representation Relationship |
| Agent (org acting) | Organization + Representation Relationship |
| Power of attorney | Delegation Relationship + Credential |
| Contract | Commercial Commitment (contract) |
| Apparent authority | Trust Relationship risk + Administration governance |
| Agency termination | Lifecycle State on Representation/Delegation |
## Open Questions
- Should canon add **Legal Person** as umbrella for Natural Person + juridical
Organization/Legal Entity?
- How should apparent authority risks be represented for service accounts?
## References
- Stimmel Law, Agency – The Basic Law — https://www.stimmel-law.com/en/articles/agency-basic-law
- Contract privity doctrine (common law overview)
- Harvard Law School Forum, FinCEN beneficial ownership and corporate persons

95
infospace/assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md Normal file
View file

@ -0,0 +1,95 @@
# LEI and GLEIF Legal Entity Identifier
## Source Type
Standard and registry. ISO 17442 Legal Entity Identifier; GLEIF global LEI index.
## Domain
Regulated financial markets, legal entity identification, and ownership transparency.
## Why This Source Matters
LEI is the post-2008-crisis global standard for identifying **legal entities** in
financial transactions. It encodes **who** and **who owns whom**, making it a
canonical example of commercially binding identity with regulatory renewal
requirements.
## Key Concepts
- **LEI**: 20-character ISO 17442 identifier for a legal entity.
- **Legal entity (LEI scope)**: organization participating in financial transactions;
individuals cannot obtain LEI.
- **GLEIF**: Global Legal Entity Identifier Foundation; oversees LOUs and data quality.
- **LOU (Local Operating Unit)**: issuer/registrar for LEIs in a jurisdiction.
- **Level 1 data**: business card data — legal name, address, jurisdiction.
- **Level 2 data**: ownership — direct and ultimate parent relationships.
- **Renewal**: LEI valid one year; annual renewal required for continued use.
- **Regulatory mandate**: 45+ jurisdictions require LEI for certain financial reporting.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| LEI | Legal Entity Identifier code. |
| Legal entity | Juridical person in financial markets. |
| Level 1 | Entity reference data. |
| Level 2 | Parent/ownership reference data. |
| GLEIF | Global LEI system operator. |
| LOU | Local issuing organization. |
| Renewal | Annual reaffirmation of LEI validity. |
| Regulator reporting | MiFIR, derivatives reporting, etc. |
## Modeling Assumptions
- **LEI identifies legal entities only**, not natural persons or login accounts.
- **Ownership is first-class** in LEI Level 2 (parent chains).
- **Identity persistence is maintained by renewal**, not immutability of business facts.
- **Public global directory** enables counterparty verification.
- **LEI does not prove good behavior**; it proves identifiable legal presence.
- **One LEI per legal entity** for global financial identification.
## Identity-Canon Implications
- LEI maps to **Registry Identifier** (`scheme: 0199`, `authority_class:
regulatory_global`, `renewal_required: true`) for **Legal Entity** /
**Organization** actors.
- Level 2 parent data maps to **Ownership** or structural Organization relationships.
- LEI record maps to **Commercial Record** or authoritative **Identity Record**
with registry **Evidence Source**.
- Renewal maps to **Lifecycle State** on Identifier/Commercial Record.
- LEI exemplifies **commercial binding**: regulatory participation requires stable,
renewed legal identity.
- Distinct from DUNS (credit/commerce) and from OIDC sub (authentication).
## Terminology Conflicts
- **Legal entity (LEI)** vs. **Legal Entity (canon)**: aligned when jurisdictionally recognized.
- **Legal entity** vs. **Organization**: not every organization has LEI; LEI subset is regulated finance participants.
- **LEI** vs. **company registration number**: national registry ID vs. global LEI.
## Candidate Canonical Mappings
| LEI concept | Candidate canonical concept |
| --- | --- |
| LEI code | Registry Identifier (regulatory_global, ICD 0199) |
| Legal entity | Legal Entity / Organization |
| Level 1 data | Commercial Record / registry Profile |
| Level 2 parent | Ownership Relationship |
| GLEIF registry | Evidence Source (authoritative) |
| Annual renewal | Lifecycle State maintenance |
| LOU issuance | Issuer Scope + Trust Relationship |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- Registry Identifier subtype; LEI↔company reg **strong**; LEI↔DUNS **medium**.
## References
- ISO 17442 — https://www.iso.org/standard/78829.html
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
- Wikipedia, Legal Entity Identifier — https://en.wikipedia.org/wiki/Legal_Entity_Identifier

171
infospace/assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md Normal file
View file

@ -0,0 +1,171 @@
# Payment Credential Boundary — PCI and Commercial Commitment
## Source Type
Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment
Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment
separation.
## Domain
Payment instruments on billing customers — what belongs in canonical identity
model vs. PCI-scoped downstream vaults, and how charge authorization relates to
Commercial Commitment.
## Why This Source Matters
Stripe **Customer** objects carry **payment methods**, and canon **Credential**
already covers secrets and proof material. Collapsing them causes two failures:
1. **PCI scope bleed** — modeling PAN, CVV, or vault secrets in identity canon
implies they belong in general identity stores.
2. **Semantic collision** — login passkeys and payment mandates both "authorize
something" but authorize **authentication** vs. **commercial debit**.
Payment methods are commercially binding (tier 3 assurance) when they encode
**mandate to charge** — but the binding artifact is the **authorization/commitment**,
not the token reference.
## Key Concepts
### PCI DSS data categories
- **CHD (cardholder data)**: PAN, cardholder name, expiration, service code.
- **Sensitive authentication data (SAD)**: CVV/CVC, full track data, PIN — never
stored after authorization per PCI.
- **Token**: surrogate value replacing PAN; if properly implemented, token in
merchant environment is **out of PCI CHD scope** (PCI tokenization guidelines).
- **Scope principle**: systems that store, process, or transmit CHD fall under PCI;
token references (`pm_xxx`) in app DBs are not CHD when only the token exists.
### Stripe payment object model
- **PaymentMethod** (`pm_xxx`): reusable payment details attached to Customer;
contains type-specific non-transaction data (last4, fingerprint, billing details).
- **SetupIntent**: establishes future off-session payment — creates mandate to charge.
- **PaymentIntent**: one-time or reusable charge attempt.
- **Customer**: billing container; payment methods attach here, not to login User.
- **Mandates** (SEPA, Bacs, etc.): explicit customer authorization for debits.
### Authentication vs. payment authorization
| Dimension | Authentication credential | Payment authorization |
| --- | --- | --- |
| Proves | Identity / session control | Right to debit funds |
| Scope | IdP, app login, federation | Payment network / acquirer |
| Regulation | NIST 800-63, OIDC | PCI DSS, PSD2 SCA, Nacha |
| Canon home | Credential | Payment Mandate (Commercial Commitment) |
| Secret handling | Passkey, password hash | CHD in vault only; token ref in app |
## Modeling Assumptions
- **Canon is implementation-neutral** but must not encourage CHD in identity layers.
- **Payment provider owns payment truth**; app holds references and commitment state.
- **Reusable payment method** implies **Commercial Commitment** (payment mandate)
when customer consented to future charges (SetupIntent succeeded, card on file).
- **Single-use payment methods** may exist only for one PaymentIntent — weaker
commitment, often no reusable mandate.
- **Subscription** is separate Commercial Commitment (recurring service obligation);
payment mandate is **enabling** commitment for collection.
- **Webhook events** (`setup_intent.succeeded`, `payment_method.attached`) are
**Evidence Source** for mandate lifecycle.
## Identity-Canon Implications
### Resolved: do not map payment methods to Credential
**Credential** in canon covers authentication, federation, and entitlement proof
(passkey, password, certificate, VC). **Payment methods are not Credentials.**
Raw CHD and SAD are **out of canon entirely** — downstream PCI vault / payment
provider only.
### Payment Instrument Reference
Add **Payment Instrument Reference** — Reference layer value scoped to a payment
provider (Stripe `pm_xxx`, fingerprint, display last4, mandate ID). Links to
**Commercial Record**, not to login **Account**.
Properties:
- `provider_scope` — Stripe account, Adyen merchant, etc.
- `instrument_type` — card, sepa_debit, us_bank_account, etc.
- `reference_id` — provider token (not PAN).
- `reusable` — boolean.
- `lifecycle_state` — attached, detached, expired, revoked.
This is a **Scoped Identifier** specialization, not a Credential.
### Payment Mandate as Commercial Commitment
When a customer authorizes future charges (SetupIntent success, SEPA mandate
signed, card saved with explicit consent), model **Payment Mandate** as a
**Commercial Commitment** subtype:
- `commitment_type: payment_mandate`
- `lifecycle_state`: proposed → active → revoked → expired
- Parties: customer actor (via Commercial Record) and vendor/payment facilitator
- **Evidence Source**: SetupIntent result, mandate document, SCA proof metadata
- `assurance_tier: committed` on Counterparty Assurance Gradient
**Subscription** remains `commitment_type: subscription` — distinct but often
co-created at checkout.
### Commercial Record role
**Commercial Record** (Stripe Customer) **references** payment instrument refs
and **hosts** links to Payment Mandate commitments. Do not embed CHD attributes
in Commercial Record canon fields — only provider references and lifecycle flags
(`delinquent`, default payment method ref).
### Layer diagram
```text
Login Account → Credential (passkey, password)
Commercial Record → Payment Instrument Reference (pm_xxx)
Commercial Commitment → Payment Mandate + Subscription
PCI Vault / Stripe → CHD (downstream only, not canon)
Evidence Source → webhooks, mandate PDF, SCA audit
```
## Terminology Conflicts
- **Payment method (Stripe)** vs. **Credential (canon)**: both grant "permission"
but different permission domains.
- **Payment credential (informal)** vs. **Credential (glossary)**: avoid informal
phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
- **Saved card** vs. **payment mandate**: saved token may exist before explicit
off-session mandate — lifecycle `proposed` until SetupIntent completes.
- **customer_account (Stripe)** vs. **Account (login)**: reinforces commercial split.
## Candidate Canonical Mappings
| Source artifact | Canonical mapping |
| --- | --- |
| PAN / CVV | Out of canon (PCI downstream) |
| PaymentMethod `pm_xxx` | Payment Instrument Reference |
| SetupIntent succeeded | Payment Mandate Commercial Commitment + Evidence |
| Subscription object | Commercial Commitment (subscription) |
| Default payment method | Reference on Commercial Record |
| Payment webhook | Evidence Source |
| 3DS / SCA step-up | Evidence Source on mandate (not Credential) |
| Passkey for login | Credential (unchanged) |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- Network tokens → Payment Instrument Reference `instrument_type: network_token`.
- Shared methods → multi Commercial Record link within payment org Scope.
- Wallet balance → Commercial Record `provider_ledger_balance` attribute.
## References
- PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
- Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
- Stripe Customer object — https://docs.stripe.com/api/customers/object
- Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
- Internal: `../commercial-subscription/stripe-customer-billing.md`,
`reputation-assurance-gradient.md`, `commercial-identity-synthesis.md`

186
infospace/assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md Normal file
View file

@ -0,0 +1,186 @@
# Registry Identifier Subtypes — ISO 6523, ALEI, LEI, DUNS, UEI
## Source Type
Standards and registry synthesis. ISO/IEC 6523, ISO 17442 (LEI), ISO 8000-116
(ALEI), GLEIF, D&B DUNS, SAM.gov UEI, EITI/Open Ownership identifier guidance.
## Domain
Authoritative and proxy organization identifiers used in commerce, procurement,
financial markets, beneficial ownership transparency, and master data management.
## Why This Source Matters
Legal entities accumulate **multiple identifiers** from different registries —
company registration numbers, LEI, DUNS, UEI, VAT — each with different
**issuing authority**, **renewal rules**, and **trust basis**. Collapsing them
into generic Identifier loses lifecycle, authority, and cross-registry linking
semantics needed for commercial binding and BO transparency.
## Key Concepts
### ISO/IEC 6523 structure
ISO/IEC 6523 defines organization identification as:
- **International Code Designator (ICD)**: up to 4 digits identifying the issuing
scheme authority (registered with ISO/IEC 6523-2).
- **Organization identifier**: up to 35 characters within that scheme.
- **Optional organization part identifier (OPI)**: sub-entity within organization.
Combined form enables global interchange (PEPPOL, EDIFACT, Schema.org `iso6523Code`).
Example ICD allocations relevant to commercial identity:
| ICD | Scheme | Authority type |
| --- | --- | --- |
| 0060 | D-U-N-S (DUNS) | Commercial proxy (D&B) |
| 0088 | EAN Location Code (GLN) | GS1 location |
| 0151 | Singapore UEN | Government registry |
| 0199 | Legal Entity Identifier (LEI) | GLEIF / ISO 17442 |
| 0209 | GS1 identification keys | GS1 |
(Full list maintained at iso6523.info and PEPPOL ICD codelists.)
### Authoritative vs. proxy identifiers (ISO 8000-116 / ALEI)
**Authoritative Legal Entity Identifier (ALEI)**: identifier assigned by a
**government jurisdiction** authorized by statute to create legal entities and
maintain authoritative registries. Format: jurisdiction prefix + register +
local number (e.g., `US-DE.BER:3031657`).
**Proxy identifiers**: issued by institutions that do **not** create legal
entities — DUNS (D&B), NCAGE (CAGE), and arguably LEI (GLEIF issues to existing
legal entities but does not incorporate them).
**LEI nuance**: ISO 17442 / GLEIF is regulatory-mandated for financial
transactions but is a **cross-jurisdiction overlay** on existing legal entities,
not the incorporating register. Canon treats LEI as **Registry Identifier**
with `authority_class: regulatory_global`.
### Renewal and lifecycle
| Identifier | Renewal / validity | Lifecycle driver |
| --- | --- | --- |
| LEI | Annual renewal required | GLEIF / LOU reaffirmation |
| DUNS | No annual renewal; record updates | D&B data maintenance |
| UEI | Persistent in SAM.gov | Entity registration status |
| Company reg number | Jurisdiction-specific | Annual report / dissolution |
| ALEI / IBRN | Tied to registry filing status | Government register |
| VAT / tax ID | Jurisdiction-specific | Tax authority |
Renewal semantics belong on **Registry Identifier** lifecycle state, not on the
Organization actor.
### Cross-registry linking
Same legal entity may hold LEI + DUNS + UEI + national company number.
**Synonymity Assertion** (`same_as`, strong or authoritative) links Registry
Identifiers when evidenced by registry crosswalk, LOU verification, or operator
confirmation. Do not silently merge Commercial Records.
EITI and Open Ownership recommend **reliable organizational identifiers**
(especially authoritative registration numbers) in beneficial ownership datasets
to disambiguate corporate vehicles.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Registry Identifier | Identifier issued under a registered scheme with known authority. |
| ICD | ISO 6523 International Code Designator for a scheme. |
| ALEI | Authoritative Legal Entity Identifier (government register). |
| Proxy identifier | Commercial or overlay ID not from incorporating authority. |
| LOU | Local Operating Unit issuing LEIs. |
| Renewal | Periodic reaffirmation of identifier validity (esp. LEI). |
| Crosswalk | Mapping between identifiers for same entity. |
## Modeling Assumptions
- **Registry Identifier is an Identifier subtype**, not a Record layer entity.
The registry **record** (GLEIF entry, D&B profile, SAM registration) maps to
Commercial Record or Identity Record.
- **Authority class** matters more than brand name (LEI vs. DUNS vs. company reg).
- **Renewal is optional metadata** — present for LEI, absent for DUNS.
- **ICD code** is the preferred `scheme` key for ISO 6523-aligned identifiers.
- **Proxy Commercial Identifier** is a Registry Identifier with
`authority_class: commercial_proxy` for DUNS-like schemes.
## Identity-Canon Implications
### Resolved: Registry Identifier subtype
Add **Registry Identifier** as an Identifier specialization in the Reference layer.
**Recommended fields:**
- `scheme`: ICD code or well-known scheme URI (e.g., `0199` for LEI, `0060` for DUNS)
- `authority`: issuing body (GLEIF LOU, D&B, SAM.gov, Companies House, etc.)
- `authority_class`: `government_registry` | `regulatory_global` | `commercial_proxy` | `tax`
- `jurisdiction`: ISO country/subdivision when applicable
- `value`: the identifier string
- `renewal_required`: boolean
- `lifecycle_state`: active, lapsed, revoked, expired, superseded
- `last_renewed_at` / `expires_at`: when renewal applies
- `evidence_source`: registry lookup, LOU issuance, API verification
### Proxy Commercial Identifier
**Proxy Commercial Identifier** is a Registry Identifier with
`authority_class: commercial_proxy` — vendor-operated business keys (DUNS) used
for credit and procurement but not legal incorporation. Keeps DUNS mapping
explicit without conflating with ALEI or company registration numbers.
### Mapping table
| Source identifier | Canonical mapping |
| --- | --- |
| LEI code | Registry Identifier (`scheme: 0199`, `authority_class: regulatory_global`) |
| DUNS | Proxy Commercial Identifier (`scheme: 0060`) |
| UEI (SAM.gov) | Registry Identifier (`authority_class: government_registry`, US federal) |
| Company registration number | Registry Identifier (`authority_class: government_registry`, jurisdiction-local) |
| ALEI / IBRN | Registry Identifier (`authority_class: government_registry`, ISO 8000-116 format) |
| VAT / EIN / tax ID | Registry Identifier (`authority_class: tax`) |
| GLEIF registry entry | Commercial Record or Identity Record + Evidence Source |
| D&B business profile | Commercial Record + PAYDEX as Evidence Source |
| Same entity, multiple IDs | Synonymity Assertion between Registry Identifiers |
### Relationship to Beneficial Ownership
BO datasets should reference **Organization/Legal Entity** via Registry Identifier
(authoritative company reg preferred; LEI as strong cross-border key). Beneficial
Ownership Relationships attach to the entity actor, not to the identifier — but
identifier quality affects Evidence strength on BO filings.
## Terminology Conflicts
- **Legal entity (LEI)** vs. **Organization (canon)**: LEI subset ⊂ organizations
with financial/regulatory participation.
- **DUNS business entity** vs. **Legal Entity**: D&B may assign DUNS to locations
or branches not identical to juridical persons.
- **Identifier** vs. **Commercial Record**: Stripe `customer_id` is scoped
system Identifier; LEI is registry Identifier — different authority classes.
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- `authority_class` includes `industry_association` (NCAGE, GS1 GLN).
- LEI↔DUNS medium; LEI↔company reg/ALEI/UEI strong; crosswalk table in settlement note.
- OPI → Organization Unit / branch Registry Identifier with `organization_part_id`.
## References
- ISO/IEC 6523 — https://www.iso.org/standard/25773.html
- ISO 17442 (LEI) — https://www.iso.org/standard/78829.html
- ISO 8000-116 (ALEI) — https://www.iso.org/standard/75117.html
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
- iso6523.info ICD list — http://iso6523.info/icd_list.pdf
- PEPPOL ICD codelist — https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/
- GSA, Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update
- EITI, Organisational identifiers guidance — https://eiti.org/sites/default/files/2023-11/Technical%20Guidance%20%E2%80%93%20Organisational%20identifiers%20guidance%20%20WEB.pdf
- Open Ownership, reliable identifiers — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
- Internal: `lei-gleif-legal-entity-identifier.md`, `duns-commercial-credit-identity.md`

242
infospace/assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md Normal file
View file

@ -0,0 +1,242 @@
# Reputation and Counterparty Assurance Gradient
## Source Type
Cross-domain synthesis. Online reputation systems, credit reporting, contract
bonding theory, payment dispute automation, and alternative dispute resolution
(ADR) / litigation practice.
## Domain
How counterparties move from weak social proof to enforceable commercial reliance
— and how identity-canon should model that journey without collapsing tiers.
## Why This Source Matters
"Reputation" is overloaded: a five-star Yelp review, a D&B PAYDEX score, a
performance bond, and a court judgment all influence whether a counterparty is
trusted — but they differ radically in **evidence quality**, **gaming risk**,
**attribution strength**, and **enforceability**. Software often stores them in
one "rating" field. Canon must preserve the gradient so downstream systems do not
treat gamable opinion as legal fact or ignore contractual stakes already modeled
elsewhere.
## The Assurance Gradient (Journey)
Counterparty assurance typically escalates through four tiers. Higher tiers do
not replace lower ones; they **constrain** how much weight lower tiers may carry
for a given decision.
```text
Tier 1 OPINION Star ratings, reviews, karma, badges
(weak/gamable) Low cost to fake; Sybil-prone; scope-local
Tier 2 OBSERVED PAYDEX, on-time %, chargeback rate, audit logs,
(evidence) verified transaction history, KYC outcome
Tier 3 COMMITTED Contract, bond, escrow, guarantee, insurance,
(financial) SLA penalties, payment mandate, subscription lock-in
Tier 4 ADJUDICATED Arbitration award, court judgment, regulator action,
(legal) enforced settlement, lien, bankruptcy filing
```
### Tier 1 — Opinion signals (weak, gamable)
**Examples:** Amazon/Yelp star ratings, eBay feedback scores, Stack Overflow
reputation, Uber driver rating, Trustpilot reviews, Airbnb host score.
**Properties:**
- **Low cost of manipulation** — fake reviews, review bombing, sock puppets,
Sybil accounts (Jøsang reputation attack taxonomy).
- **Scope-local** — reputation on eBay does not transfer to Etsy without
explicit portability (reputation bank problem).
- **Voluntary participation bias** — satisfied and angry customers over-represent;
silent majority absent.
- **Identity attribution weak** — reviewer may be unverified persona; linkage to
Natural Person or Organization often absent.
- **Economic effect real but bounded** — eBay seller ratings correlate with price
premium, but platforms add escrow and buyer protection because ratings alone
insufficient.
**Canon mapping:** **Reputation Signal** — an **Evidence Source** with
`assurance_tier: opinion`. Attach to **Profile**, **Commercial Record**, or
**Actor** with explicit **Scope** (platform namespace). Default synonymity and
trust strength: **weak**. Do not promote to Commercial Commitment.
**Gaming defenses (downstream):** verified-purchase flags, rate limits, graph
analysis, moderation — model as separate Evidence Source metadata, not as tier
upgrade by itself.
### Tier 2 — Observed metrics (evidence-based)
**Examples:** D&B PAYDEX, business credit scores, platform completion rate,
on-time delivery statistics, SLA attainment dashboards, chargeback ratio,
sanctions-screen clear result, KYC pass, LEI renewal status.
**Properties:**
- **Grounded in observable events** — payment dates, shipment scans, registry
lookups, transaction logs.
- **Stronger attribution** — usually tied to **Registry Identifier**, **Commercial
Record**, or verified **Account** history.
- **Third-party or platform issuer** — D&B, credit bureaus, marketplace operator,
KYC vendor acts as **Evidence Source** issuer.
- **Still revisable** — metrics update; disputes may correct; not legally
conclusive.
- **Monitoring lifecycle** — ongoing CDD and PAYDEX refresh mirror **Lifecycle
State** on evidence, not one-time truth.
**Canon mapping:** **Performance Evidence** — **Evidence Source** with
`assurance_tier: observed`. Link to **Commercial Record** / **Organization** via
**Registry Identifier** or **Commercial Relationship**. Supports **Trust
Relationship** with medium-to-strong confidence when issuer is authoritative.
### Tier 3 — Committed stakes (contractual / financial)
**Examples:** Performance bonds, surety bonds, letters of credit, escrow deposits,
service-level agreements with liquidated damages, signed MSAs, active subscription
with payment mandate, insurance certificates, qualified electronic seals on
contracts (eIDAS).
**Properties:**
- **Costly to breach** — Klein-Leffler bonding: quality assurance through
market forces when reputation alone insufficient; hostages and penalties.
- **Explicit parties** — **Legal Person** / **Organization** actors bound via
**Commercial Commitment** and **Representation** chains.
- **Automated enforcement partial** — smart-contract escrow, Stripe retention,
auto-renewal billing, SLA breach triggers — automation executes **committed**
rules without yet reaching court.
- **Identity stakes rise** — counterparties need stable **Registry Identifier**,
**Commercial Record**, and often **Beneficial Ownership Relationship** because
liability is real.
**Canon mapping:** **Commercial Commitment** (contract, subscription, payment
mandate, bond) with **Evidence Source** attesting execution. Assurance tier:
`committed`. **Trust Relationship** here should cite the commitment ID, not
opinion aggregates.
**Distinction:** A five-star rating is not a bond. A bond is not a review.
Model separately; combine only in downstream risk engines with explicit weighting.
### Tier 4 — Adjudicated outcomes (automated dispute → legal resolution)
**Escalation path:**
1. **Platform automation** — chargeback dispute rules, marketplace arbitration
(eBay Money Back Guarantee), payment processor outcome.
2. **Contractual ADR** — mandatory arbitration clause (AAA, ICC, JAMS); neutral
award binding per contract and statute.
3. **Courts** — breach of contract, fraud, collections, judgment lien, bankruptcy.
**Properties:**
- **Third-party or state authority** — arbitrator, court, regulator issues outcome.
- **High attribution** — parties identified in proceeding; ties to **Legal Entity**.
- **Enforceable beyond platform** — judgments attach to legal persons; credit
reporting may follow.
- **Lifecycle durable** — satisfied, appealed, vacated, enforced — explicit
**Lifecycle State**.
**Canon mapping:** **Adjudication Outcome** — **Evidence Source** with
`assurance_tier: adjudicated`. May trigger **Commercial Commitment** state change
(breached, fulfilled), **Trust Relationship** revocation, or **Lifecycle State**
on **Commercial Record**. Do not model as "bad review."
## Cross-Tier Dynamics
| Transition | What changes | Canon event |
| --- | --- | --- |
| Opinion → Observed | Platform verifies purchase; metric computed from logs | New Performance Evidence; optional Synonymity link reviewer Account to transaction |
| Observed → Committed | Parties sign contract / post bond | Commercial Commitment created; Trust Relationship cites commitment |
| Committed → Adjudicated | Breach → ADR/court | Adjudication Outcome Evidence; commitment lifecycle update |
| Adjudicated → Observed | Judgment paid; credit file updated | Performance Evidence refresh (credit bureau) |
**De-escalation:** Adjudicated fraud finding may **invalidate** opinion signals
(moderation) but should not silently delete Evidence — supersede with lifecycle.
**Identity coupling:** Higher tiers require stronger **actor attribution**.
Opinion may attach to **Persona**; adjudication attaches to **Legal Entity** +
**Registry Identifier**.
## Relationship to Existing Canon
| Concept | Role in assurance gradient |
| --- | --- |
| Evidence Source | Carrier for all tiers; use `assurance_tier` metadata |
| Trust Relationship | Counterparty reliance; must cite tier basis |
| Commercial Commitment | Tier 3 anchor |
| Commercial Relationship | Scope for which assurance applies |
| Registry Identifier | Attribution for tiers 2–4 |
| Beneficial Ownership Relationship | Liability chain for tier 3–4 entity customers |
| Assurance Level (NIST) | Orthogonal — identity/auth proofing, not commercial performance |
| Synonymity Assertion | Link platform persona to legal entity when tiers mix |
## Reputation Systems Literature (Practical)
Jøsang survey and Resnick criteria for effective reputation systems:
1. Long-lived entities with predictable future interaction.
2. Capture and distribute feedback from prior interactions.
3. Use feedback to guide trust.
**Implication for canon:** Tier 1 only works when **Scope** is stable and
interaction history is modeled as Evidence with temporal bounds. Reputation
**capital** (economic value of good history) is aggregate **Performance Evidence**
over time — not a separate ontological root.
**Attacks:** self-promotion, Sybil, slandering, whitewashing — map to
`integrity_risk` metadata on opinion-tier Evidence; downstream concern, but canon
should flag tier-1 default weakness.
## Candidate Canonical Mappings
| Source artifact | Canonical mapping |
| --- | --- |
| Star rating / review | Reputation Signal (Evidence Source, tier: opinion) |
| Verified purchase review | Reputation Signal + Performance Evidence link |
| PAYDEX / credit score | Performance Evidence (tier: observed) |
| SLA dashboard | Performance Evidence on Commercial Relationship |
| Signed MSA / bond | Commercial Commitment + Evidence Source (tier: committed) |
| Escrow release | Commercial Commitment lifecycle event |
| Arbitration award | Adjudication Outcome (tier: adjudicated) |
| Court judgment | Adjudication Outcome + may affect Legal Entity lifecycle |
| "Trust score" UI | Downstream projection — not canonical root |
## Resolved Canon Question
**Do not add Reputation as a first-class entity.**
Instead:
1. **Counterparty Assurance Gradient** — modeling pattern (four tiers).
2. **Evidence Source** specializations by tier: **Reputation Signal** (opinion),
**Performance Evidence** (observed), **Adjudication Outcome** (adjudicated);
tier 3 uses existing **Commercial Commitment**.
3. **Trust Relationship** carries `assurance_basis` referencing tier + evidence IDs.
**Convenience term only:** "Reputation" in prose — resolve to specific tier and
Evidence Source before modeling.
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- `assurance_tier` primary; optional `numeric_score` + `score_scale` downstream.
- Segregated escrow → Commercial Commitment `commitment_type: escrow`.
- Reputation portability → Synonymity `linked_to`, weak default.
- Oracle release → observed; ADR/court → adjudicated.
## References
- Josang, "A survey of trust and reputation systems for online service provision" — https://doi.org/10.1016/j.dss.2005.05.019
- Hoffman et al., "A survey of attack and defense techniques for reputation systems" — ACM Computing Surveys
- Klein and Leffler (1981), quality assurance through bonding / price premiums
- RFC 7070, An Architecture for Reputation Reporting — https://www.rfc-editor.org/rfc/rfc7070
- Wikipedia, Reputation system — https://en.wikipedia.org/wiki/Reputation_system
- Internal: `commercial-trust-binding-theory.md`, `duns-commercial-credit-identity.md`,
`legal-person-agency-contract.md`, `kyc-aml-commercial-identity-binding.md`

94
infospace/assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md Normal file
View file

@ -0,0 +1,94 @@
# Salesforce CRM Commercial Record Model
## Source Type
Product data model reference. Salesforce Account, Contact, Lead, and B2B relationship patterns.
## Domain
CRM, sales operations, commercial customer records, and B2B account hierarchies.
## Why This Source Matters
Salesforce **Account** is the archetypal **commercial record** in enterprise software:
a company or household you sell to, distinct from **Contact** (people) and **User**
(login). It operationalizes commercial identity separate from authentication.
## Key Concepts
- **Account**: company, household, or partner organization in CRM; core commercial record.
- **Contact**: person associated with accounts; human relationship endpoint.
- **Lead**: unqualified prospect before conversion to Account/Contact.
- **Opportunity**: potential revenue deal tied to Account.
- **Account hierarchy**: parent-child account relationships (global HQ → subsidiaries).
- **Account-Contact Relationship**: many-to-many person-to-account roles (ACR).
- **Person Account**: B2C pattern merging person and account for individual consumers.
- **Partner / Customer / Competitor**: account type labels for commercial role hints.
- **User (Salesforce)**: internal login for CRM operators, not customer identity.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Account | CRM commercial entity record. |
| Contact | Person linked to accounts. |
| Lead | Pre-qualification prospect. |
| ACR | Account-Contact Relationship with roles. |
| Account hierarchy | Parent/child commercial structure. |
| Person Account | B2C combined person+account pattern. |
| Customer account (informal) | Often means CRM Account object. |
## Modeling Assumptions
- **Commercial party (Account) ≠ login User**; sales data outlives individual logins.
- **Multiple contacts** represent people acting for commercial account (agency in practice).
- **Hierarchy models corporate structure** for roll-up revenue and ownership context.
- **Lead → Account conversion** is fluid-to-bound transition in commercial funnel.
- **Person Account** blurs person/account boundary for B2C — convenient but risky for canon purity.
- **Account type** hints customer/vendor/partner but is not authorization.
## Identity-Canon Implications
- Salesforce **Account** maps to **Commercial Record** linked to **Organization**
(B2B) or **Natural Person** (person account).
- **Contact** maps to **Natural Person** + **Affiliation** or **Representation** to Organization.
- **ACR** maps to **Membership** or **Representation** with role metadata.
- **Account hierarchy** maps to Organization parent/child structural relationships.
- **Lead** maps to provisional Identity/Commercial prospect with weak evidence until conversion.
- **User** maps to internal **Account** (employee), not customer.
- Validates Commercial Record concept from Customer Account resolution work.
## Terminology Conflicts
- **Account (CRM)** vs. **Account (login)**: Salesforce naming collision.
- **Customer account** language vs. **Account object**: product uses Account for all.
- **Person Account** vs. **P2 separation**: B2C shortcut vs. canon layers.
## Candidate Canonical Mappings
| Salesforce concept | Candidate canonical concept |
| --- | --- |
| Account (B2B) | Commercial Record + Organization |
| Contact | Natural Person |
| Account-Contact Relationship | Affiliation / Representation |
| Account hierarchy | Organization structure Relationship |
| Lead | Prospective Commercial Record (weak) |
| Opportunity | Pipeline Pursuit (promotes to Commercial Commitment on binding trigger) |
| User | Account (internal operator) |
| Person Account | Commercial Record + Natural Person (combined projection) |
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- Opportunity → **Pipeline Pursuit**; binding triggers and renewal/amendment rules.
- Person Account → split Natural Person + Commercial Record; adapter `projection_mode`
only on export.
## References
- Salesforce Account object reference — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_account.htm
- Shellblack, Leads vs Account and Contacts — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
- SalesforceBen, Account best practices — https://www.salesforceben.com/best-practices-salesforce-account-object/

102
infospace/assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md Normal file
View file

@ -0,0 +1,102 @@
# B2B SaaS Subscriber and Organization Tenancy
## Source Type
Product documentation and industry practice synthesis. Auth0 Organizations and
B2B SaaS multi-tenancy guidance; Stytch B2B Auth School org-tenancy model.
## Domain
B2B SaaS identity, organization tenancy, subscriber administration, and
vendor/customer delineation in IAM products.
## Why This Source Matters
IAM vendors explicitly separate the subscribing party (customer/subscriber) from
login accounts and from billing records. This source clarifies why "customer
account" overloads identity, commercial, and access semantics.
## Key Concepts
- **Subscriber**: Auth0-preferred term for the immediate B2B customer — the
party that holds a provisioned tenant and subscription.
- **Vendor**: provider of the B2B SaaS application (platform operator).
- **Organization tenancy**: architecture where organizations are first-class
entities; members are scoped to their organization.
- **Member**: end user with membership in an organization (Stytch); distinct
from platform-wide user identity.
- **Tenant / tenancy holder**: operational partition occupied by a subscriber.
- **Org discovery**: determining which organization a user authenticates into.
- **Membership control**: granting/revoking which users may access a subscriber's
tenant.
- **Identity isolation**: per-subscriber credential and IdP configuration vs.
platform-wide user population.
- **B2B2C / B2B2B variants**: additional "customer" and "consumer" layers below
the subscribing organization.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Subscriber | B2B customer occupying a tenant; Auth0 avoids "customer" label. |
| Vendor | SaaS platform provider. |
| Organization | First-class customer entity; "the organization is the customer" (Stytch). |
| Member | Employee or invited user within an organization. |
| Tenant | Isolation boundary for subscriber data, branding, and config. |
| Customer (informal) | Often used interchangeably with subscriber or organization. |
| User | Login identity; may belong to multiple organizations. |
| Consumer | End user in B2B2C scenarios below the subscriber org. |
## Modeling Assumptions
- **The subscribing company is modeled as an organization**, not as a user
account or billing record.
- **One human can be a member of multiple subscriber organizations** (contractors,
agencies).
- **Platform stores users globally**; membership scopes them to subscriber orgs.
- **Billing is subscription-based** but handled outside core IAM in most products.
- **Vendor administration** may cross tenant boundaries with subscriber consent;
subscriber administration does not.
- **No IAM product defines "Customer Account"** as a separate entity type.
## Identity-Canon Implications
- **Subscriber** maps to **Organization** actor in **Customer Relationship**
with vendor + **Tenant** Scope — not a canonical noun.
- **Member** maps to **Account** + **Membership Relationship** to Organization.
- **Vendor** maps to **Vendor Relationship** role on vendor Organization actor.
- Supports S04, S05 without Customer Account concept.
- Individual (B2C-style) subscriber maps to **Natural Person** + **Tenant**
Scope, still without Customer Account.
## Terminology Conflicts
- **Customer vs. Subscriber vs. Organization**: three labels for overlapping B2B
party; IAM prefers organization or subscriber.
- **Customer vs. Consumer**: B2B2C uses both; subscriber org vs. end consumer.
- **Tenant vs. Organization**: Stytch equates customer to organization; tenant
is the isolation fabric they occupy.
- **Account**: must not be used for subscriber org or billing party.
## Candidate Canonical Mappings
| B2B SaaS IAM concept | Candidate canonical concept |
| --- | --- |
| Subscriber | Organization + Customer Relationship role |
| Organization (tenant holder) | Organization + Tenant Scope |
| Member | Account + Membership Relationship |
| Vendor (platform) | Organization + Vendor Relationship role |
| Tenant | Tenant (Scope) |
| User (login) | Account |
| Consumer (B2B2C) | Natural Person or Account (context-dependent) |
## Open Questions
- None blocking Customer Account resolution. Commercial billing layer documented
separately in `stripe-customer-billing.md`.
## References
- Auth0: Demystifying Multi-Tenancy in B2B SaaS — https://auth0.com/blog/demystifying-multi-tenancy-in-b2b-saas/
- Auth0 Organizations — https://auth0.com/docs/manage-users/organizations
- Stytch: Organization tenancy — https://stytch.com/blog/organization-tenancy/

106
infospace/assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md Normal file
View file

@ -0,0 +1,106 @@
# Stripe Customer and Subscription Billing
## Source Type
Product API documentation and SaaS architecture practice. Stripe Customer object
and B2B subscription billing integration patterns.
## Domain
Commercial billing, payment methods, subscriptions, and tenant-to-billing linkage
in multi-tenant SaaS.
## Why This Source Matters
Stripe's Customer object is the most widely deployed example of a **billing
customer** that is explicitly not a login account. It demonstrates why
"customer account" must be split into commercial records vs. identity records.
## Key Concepts
- **Customer (Stripe)**: billing entity with email, name, payment methods,
subscriptions, balance, and invoice settings.
- **Subscription**: recurring billing agreement tied to a Customer.
- **Payment method**: card or bank source attached to Customer for charges.
- **Metadata**: key-value pairs linking Stripe Customer to app tenant ID.
- **Delinquent**: billing health flag on Customer from invoice state.
- **Business name / individual name**: Customer may represent company or person.
- **customer_account (Stripe API)**: newer field referencing an Account object
representing a customer — explicit split from legacy Customer.
- **Webhook-driven sync**: Stripe owns payment state; app database owns business
state; webhooks bridge them.
- **Tenant mapping**: standard pattern stores `stripe_customer_id` on tenant record.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Customer | Stripe billing object; not authentication identity. |
| Subscription | Recurring charge agreement. |
| Invoice | Bill document; drives delinquent state. |
| Payment method | Stored payment instrument. |
| Balance | Credit or amount owed on Customer. |
| Metadata | App-defined correlation (e.g., tenant_id). |
| customer_account | Stripe Account representing customer (newer API). |
| Tenant (app) | Application isolation unit linked via metadata. |
## Modeling Assumptions
- **Billing state lives in payment provider**; app caches plan/feature access.
- **One Stripe Customer per tenant** is the common B2B pattern (not per login user).
- **B2B Customer** often has `business_name`; B2C may use `individual_name`.
- **Customer email** is billing contact, not necessarily login email.
- **Commercial identity can exist without Organization** (sole proprietor, individual
plan).
- **CRM "Account"** (Salesforce-style) follows similar commercial-record pattern.
## Identity-Canon Implications
- Stripe **Customer** maps to **Commercial Record** in Record layer — not Account,
not Customer Account, not Organization.
- Link Commercial Record to **Tenant** Scope and/or **Organization** / **Natural
Person** actor via **Commercial Relationship** or Identifier binding.
- Stripe **customer_account** field reinforces separate commercial vs. identity
account split at API level.
- **Subscription state** is Lifecycle State on Commercial Record (downstream).
- Supports S04 when billing is modeled alongside vendor/customer orgs.
## Terminology Conflicts
- **Customer (Stripe) vs. Customer (relationship role)**: same word, different
layers — billing object vs. vendor/customer commercial role.
- **Customer vs. Account**: Stripe uses "customer" and emerging "customer_account"
deliberately separate from login accounts.
- **Customer vs. Tenant**: integration stores stripe ID on tenant; not same entity.
- **CRM Account vs. Account (login)**: Salesforce Account = commercial record.
## Candidate Canonical Mappings
| Stripe / billing concept | Candidate canonical concept |
| --- | --- |
| Customer object | Commercial Record |
| Subscription | Commercial Record lifecycle / entitlement metadata |
| Payment method | Payment Instrument Reference (not Credential) |
| SetupIntent / mandate | Payment Mandate (Commercial Commitment) |
| Metadata.tenant_id | Identifier binding to Tenant Scope |
| business_name | Commercial Record attribute |
| individual_name | Commercial Record attribute (person-backed) |
| customer_account (API) | Commercial Record variant / provider projection |
| Delinquent / balance | Lifecycle State on Commercial Record |
| Webhook event | Evidence Source for billing state change |
## Open Questions
- Does sole-proprietor billing (person-backed Commercial Record without
Organization) need a distinct pattern in scenario tests?
## Resolved (see payment-credential-pci-boundary.md)
- Payment methods → **Payment Instrument Reference**; mandates → **Payment Mandate**.
CHD out of canon; not **Credential**.
## References
- Stripe Customer object — https://docs.stripe.com/api/customers/object
- Stripe Billing — https://docs.stripe.com/billing
- Stripe org customer sharing — https://docs.stripe.com/get-started/account/orgs/sharing/customers-payment-methods

109
infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md Normal file
View file

@ -0,0 +1,109 @@
# Deterministic vs Probabilistic Matching
## Source Type
Academic and industry practice. Entity resolution, record linkage, and
duplicate detection literature plus operational MDM patterns.
## Domain
Entity resolution, record linkage, duplicate detection, and account matching
confidence.
## Why This Source Matters
Entity resolution literature distinguishes deterministic keys from probabilistic
matching — the foundation for weak vs. strong synonymity modeling.
## Key Concepts
- **Deterministic matching**: records match when agreed key fields are equal
(exact email, government ID, OIDC `iss`+`sub`).
- **Probabilistic matching**: match score from weighted field similarity
(Fellegi-Sunter, Jaro-Winkler, ML classifiers).
- **Record linkage**: identifying records across datasets referring to same
entity.
- **Blocking**: reduce comparison space by bucketing on partial keys.
- **Match threshold**: score above which records are linked or flagged.
- **False positive / false negative tradeoff**: precision vs. recall in linking.
- **Golden record / survivor**: MDM pattern selecting canonical merged record.
- **Non-destructive link**: associate records without merge (preferred in modern MDM).
- **Human review queue**: ambiguous matches escalated for operator decision.
- **Master data management (MDM)**: operational discipline around entity resolution.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Deterministic match | Equality on predefined key fields. |
| Probabilistic match | Scored similarity above threshold. |
| Record linkage | Cross-dataset entity correspondence. |
| Blocking key | Partial key for candidate pair generation. |
| Match score | Confidence metric for probable same entity. |
| Duplicate | Records hypothesized to refer to same entity. |
| Merge | Combine records into one (destructive). |
| Link | Associate records preserving sources (non-destructive). |
| Survivor record | Chosen primary after merge. |
| Quarantine | Hold ambiguous matches for review. |
## Modeling Assumptions
- **Same entity is hypothesis until verified** in probabilistic approaches.
- **Deterministic rules are domain-specific** (no universal golden key).
- **Merge destroys provenance** unless carefully audited — increasingly avoided.
- **Confidence is continuous or banded** (weak/medium/strong).
- **Source system identity must be preserved** for compliance and undo.
- **Human review is part of high-assurance linking.**
- **Privacy regulations constrain** which fields can be matched.
## Identity-Canon Implications
- Deterministic match maps to **strong Synonymity Assertion** when keys are
authoritative (S13).
- Probabilistic match maps to **weak Synonymity Assertion** with confidence
score and method (S12).
- **Link without merge** is the canonical preferred pattern (**P7**).
- **Match score** maps to confidence/strength on Synonymity Assertion.
- **Blocking/method** maps to Evidence Source metadata.
- **Quarantine** maps to Lifecycle State `proposed` on assertion.
- **Golden record** is downstream MDM pattern; canon should not require merge.
- **Human review** maps to Evidence Source (operator decision).
## Terminology Conflicts
- **Duplicate vs. Synonymity**: duplicates imply merge; synonymity allows coexistence.
- **Match vs. Link**: industry uses interchangeably; canon distinguishes strength.
- **Entity vs. Actor**: resolution literature says entity; canon prefers Actor target.
- **Identity vs. Record**: matching is between records, not persons directly.
- **Deterministic vs. Strong**: deterministic can still be wrong if key is shared
(shared email).
## Candidate Canonical Mappings
| Entity resolution concept | Candidate canonical concept |
| --- | --- |
| Deterministic match | Strong Synonymity Assertion |
| Probabilistic match | Weak Synonymity Assertion |
| Match score | Confidence / strength metadata |
| Link (non-destructive) | Synonymity Assertion |
| Merge | Downstream anti-pattern (avoid) |
| Blocking key | Evidence Source method |
| Review queue | Lifecycle State `proposed` |
| Source record ID | Identifier |
| Golden record | Downstream projection only |
| False positive handling | Revocation / supersession of assertion |
## Open Questions
- What confidence bands (weak/medium/strong) should canon standardize?
- Which deterministic keys are authoritative per source family (OIDC iss+sub,
persistent SAML NameID, verified email)?
- Should probabilistic matchers be required to store feature-level Evidence Source?
- How should shared-attribute false positives (family email) be classified?
## References
- Fellegi-Sunter model (1969) — foundational probabilistic record linkage
- Christen, "Data Matching" (2012) — entity resolution textbook
- NIST SP 800-63A evidence requirements — https://pages.nist.gov/800-63-4/sp800-63A.html
- MDM Institute duplicate management practices — industry reference

114
infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md Normal file
View file

@ -0,0 +1,114 @@
# GDPR Pseudonymization and Privacy
## Source Type
Regulatory guidance. EU GDPR (Regulation 2016/679) Article 4(5) and Recital 26;
EDPB guidance on identifiability, anonymization, and data subject rights.
## Domain
Privacy regulation, pseudonymization, identifiability, data minimization, and
lawful basis for identity processing.
## Why This Source Matters
GDPR pseudonymization and identifiability concepts affect how canonical models
should represent privacy-limited links, scoped identifiers, and correlation risk.
## Key Concepts
- **Personal data**: information relating to identified or identifiable natural
person.
- **Identifiable person**: can be identified directly or indirectly by reasonable
means.
- **Pseudonymization (Art. 4(5))**: processing personal data so it cannot be
attributed to a subject without additional information kept separately.
- **Anonymization**: irreversible de-identification; data no longer personal.
- **Data subject**: identified or identifiable natural person.
- **Controller / Processor**: roles responsible for processing personal data.
- **Purpose limitation**: data used for specified, explicit, legitimate purposes.
- **Data minimization**: adequate, relevant, limited to necessary.
- **Right of access / erasure**: data subject rights affecting linked records.
- **Additional information**: key held separately to re-identify pseudonymous data.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Personal data | Data about identifiable natural person. |
| Pseudonymization | Reversible de-identification with separate key. |
| Anonymization | Irreversible; no longer personal data (if effective). |
| Data subject | Natural person the data relates to. |
| Identifiable | Reasonably linkable to person. |
| Additional information | Re-identification key stored separately. |
| Controller | Determines purposes and means of processing. |
| Processing | Any operation on personal data. |
| Erasure | Delete personal data (right to be forgotten). |
| Profiling | Automated evaluation of personal aspects. |
## Modeling Assumptions
- **Pseudonymization is not anonymization**; data may remain personal.
- **Separate storage of additional information** is required for pseudonymization.
- **Scope and access control on keys** determine correlation risk.
- **Linking pseudonymous records across purposes** may increase identifiability.
- **Legal basis and purpose** govern whether linking is permissible.
- **Erasure requests** may require breaking links or deleting assertions.
- **Regulatory role (controller)** is organizational, not purely technical.
## Identity-Canon Implications
- **Pseudonymous Identifier** and **Scoped Identifier** map to pseudonymization
techniques (pairwise sub, hashed email, internal IDs).
- **Privacy-limited Synonymity Assertion** must record privacy classification
and scope (S14).
- **Additional information** (re-identification key) maps to separately secured
**Evidence Source** or **Credential** with strict Scope access.
- **Data subject** maps to **Natural Person** with privacy rights overlay
(downstream policy, not canon legal advice).
- **Erasure** maps to Lifecycle State transitions: revoke assertions, sever
bindings, archive with legal exceptions noted downstream.
- Pairwise OIDC, tenant-local subjects, and restricted persona links are
technical pseudonymization patterns aligned with GDPR concepts.
- Reinforces visibility of privacy constraints on relationships (**P8**, S14 checks).
## Terminology Conflicts
- **Pseudonym vs. Pseudonymization**: pseudonym is identifier; pseudonymization
is processing technique.
- **Anonymous vs. Pseudonymous**: often conflated in product marketing.
- **Identity vs. Personal data**: not all identifiers are personal data in all
contexts.
- **Deletion vs. Revocation**: erasure may require more than assertion revocation.
- **Subject**: GDPR data subject vs. OIDC/SAML subject.
## Candidate Canonical Mappings
| GDPR concept | Candidate canonical concept |
| --- | --- |
| Data subject | Natural Person (privacy overlay) |
| Pseudonymization | Processing pattern on Identifier / Profile |
| Pseudonymous identifier | Scoped Identifier / Pseudonymous Identifier |
| Additional information | Separately secured Evidence Source / key |
| Purpose limitation | Scope + policy metadata on processing |
| Cross-system link | Synonymity Assertion (privacy classification required) |
| Erasure request | Lifecycle State + assertion revocation |
| Identifiability risk | Privacy classification on links |
| Controller | Organization actor (downstream legal role) |
| Anonymized dataset | Out of scope for personal identity linking |
## Open Questions
- Should canon include a standard `privacy_classification` enum for assertions?
- How should erasure of one account affect Synonymity Assertions touching other
accounts (S02)?
- Does pseudonymization key storage warrant a canonical secured Scope type?
- Should identifiability review be documented as operator workflow in downstream
recommendations only?
## References
- GDPR Article 4(5) pseudonymization — https://gdpr-info.eu/art-4-gdpr/
- GDPR Recital 26 on identifiability — https://gdpr-info.eu/recitals-novo/26/
- EDPB Guidelines on identifiability (various) — https://edpb.europa.eu/
- ISO/IEC 20889 privacy enhancing data de-identification terminology

106
infospace/assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md Normal file
View file

@ -0,0 +1,106 @@
# Synonymity Assertions
## Source Type
Concept synthesis from identity-canon ResearchSeed, entity resolution practice,
federation account linking, and semantic web `sameAs` patterns.
## Domain
Identity linking, scoped equivalence, account linking, and non-destructive record
association.
## Why This Source Matters
Synonymity assertions are the identity-canon-native model for linking records
without merge — synthesizing federation binding, entity resolution, and
semantic equivalence patterns.
## Key Concepts
- **Synonymity assertion**: scoped, evidenced claim that two or more identifiers,
records, or actors refer to the same target for a stated purpose.
- **Relation type**: `same_as`, `probably_same_as`, `linked_to`, `represents`,
`controls`, `acts_for` (from ResearchSeed).
- **Strength**: weak, medium, strong, authoritative bands.
- **Scope**: namespace, tenant, relying party, or purpose boundary limiting
assertion validity.
- **Evidence**: verification event, issuer signature, operator review, import
job output.
- **Source system**: system that created or maintains the assertion.
- **Lifecycle**: proposed, active, revoked, expired, superseded.
- **Privacy classification**: controls visibility and correlation risk.
- **Non-merge invariant**: linked records retain independent identity and provenance.
- **Supersession chain**: new assertion replaces old when identifiers change.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Synonymity | Sameness or equivalence under conditions. |
| Assertion | Explicit modeled statement, not implicit merge. |
| same_as | High-confidence equivalence. |
| probably_same_as | Probabilistic equivalence. |
| linked_to | Operational convenience link. |
| represents | One record represents another (controller, profile). |
| Scope | Boundary limiting assertion meaning. |
| Strength | Confidence band. |
| Revocation | Assertion no longer valid. |
| Supersession | New assertion replaces prior. |
## Modeling Assumptions
- **Equivalence is contextual**, not universal.
- **Multiple assertions can coexist** for different scopes and purposes.
- **Conflicting assertions possible**; require review workflow.
- **Downstream systems consume assertions** according to their assurance needs.
- **Privacy-limited assertions** must not leak across scopes (S14).
- **Federation bindings are synonymity assertions** (`iss`+`sub` → local account).
- **sameAs on web is weak by default** unless corroborated.
## Identity-Canon Implications
- Synonymity Assertion is a **first-class Relationship** class in canon.
- Recommended fields align with ResearchSeed and ConceptualModel invariants.
- OIDC RP binding, SAML persistent NameID mapping, SCIM `externalId`
correlation, and entity-resolution matches all project into Synonymity
Assertions with appropriate strength.
- Supports all linking scenarios: S12 (weak), S13 (strong), S14 (privacy-limited).
- **P7** is the governing principle; merge is downstream exception only.
- Revocation from RISC/SSF events should update assertion Lifecycle State.
## Terminology Conflicts
- **Link vs. Merge**: products say "linked accounts" after merge.
- **sameAs vs. same_as**: semantic web informal vs. canon typed relation.
- **Account linking vs. Identity linking**: may target accounts or identifiers.
- **Alias vs. Synonymity**: alias is presentation; synonymity is assertion.
- **Duplicate resolution vs. Synonymity**: MDM duplicate implies survivor selection.
## Candidate Canonical Mappings
| Practice / source pattern | Candidate canonical concept |
| --- | --- |
| OIDC iss+sub → local user | Strong Synonymity Assertion (scoped) |
| SAML persistent NameID map | Strong Synonymity Assertion |
| Probabilistic duplicate score | Weak Synonymity Assertion (`probably_same_as`) |
| Operator-verified link | Strong Synonymity Assertion (authoritative) |
| Pairwise sub RP binding | Privacy-limited Synonymity Assertion |
| SCIM externalId correlation | Identifier Binding / medium Synonymity |
| schema.org sameAs | Weak Synonymity Assertion (caution) |
| DID equivalentId | Method-dependent Synonymity |
| VC subject DID binding | Strong Synonymity Assertion with cryptographic evidence |
## Open Questions
- Should `linked_to` remain distinct from `same_as` for operational vs. semantic links?
- What minimum field set is mandatory for all Synonymity Assertions (see OpenQuestions)?
- How should conflicting assertions be represented (priority, review state)?
- Should privacy classification be enum or policy reference?
## References
- identity-canon ResearchSeed.md — synonymity assertion fields
- identity-canon ConceptualModel.md — identity linking model
- OIDC account linking practice — https://openid.net/specs/openid-connect-core-1_0.html
- W3C VC subject identification — https://www.w3.org/TR/vc-data-model-2.0/

138
infospace/assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md Normal file
View file

@ -0,0 +1,138 @@
# Keycloak Organizations
## Source Type
Product documentation and implementation reference for Keycloak 26+ organization
features and core realm/user/group/role model.
## Domain
Multi-tenant IAM, B2B/B2B2C organization management, and OIDC/SAML federation.
## Why This Source Matters
Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C
organization management terminology.
Keycloak is a widely deployed open-source IAM product. Its newer Organizations
feature adds first-class B2B org semantics on top of the classic realm model,
making it a live vocabulary source for tenant/org/customer overlap.
## Key Concepts
- **Realm**: top-level administrative and security namespace; owns users,
clients, identity providers, roles, groups, and authentication flows.
- **User**: realm-local account with credentials, attributes, group/role
mappings, and federation links.
- **Organization** (26+): B2B entity with members, domains, identity providers,
and invited users; supports multi-org membership per user.
- **Organization member**: user linked to an organization with membership
metadata (roles within the org context).
- **Group**: realm-level hierarchical collection for user grouping and role
mapping.
- **Role**: realm role or client role; assigned directly, via group, or via
composite roles.
- **Client**: OIDC/SAML application registered in a realm; may represent a
tenant application or service.
- **Identity Provider (IdP)**: federated authentication source brokering
external identities into realm users.
- **User federation**: LDAP/AD/Kerberos bridge supplying or syncing users.
- **Attribute**: key-value metadata on users, clients, or organizations.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Realm | Hard identity/admin boundary; separate user namespace per realm. |
| User | Realm-local login account with credentials and profile attributes. |
| Organization | B2B org actor within a realm; has domains, members, and IdP config. |
| Member | User belonging to an organization. |
| Group | Realm hierarchy node; users inherit roles through group membership. |
| Role | Named permission bundle at realm or client scope. |
| Client | Application or service consuming tokens from the realm. |
| Identity Provider | External auth source; may assert identities into realm users. |
| Domain (org) | Email domain associated with an organization for discovery/broker routing. |
| Federated identity | Link between realm user and external IdP identity. |
## Modeling Assumptions
- **Realm is the primary isolation boundary** for users, credentials, and
admin policy.
- **User means account** in product vocabulary; one realm user per login
identity within that realm.
- **Organization is a B2B overlay** within a realm, not a replacement for
realm or tenant infrastructure boundaries.
- **Groups carry authorization semantics** through role mapping, not just
social grouping.
- **Roles are permission bundles**, assignable directly or transitively via
groups and composites.
- **Federation links** connect external IdP identities to local users via
brokered login.
- **Multi-org membership** is supported: one user can belong to multiple
organizations in the same realm.
## Identity-Canon Implications
- Keycloak **Realm** maps to **Realm** (Scope specialization) with hard
namespace boundaries.
- Keycloak **User** maps to **Account** in a realm Scope; not **Natural
Person**.
- Keycloak **Organization** maps to **Organization** collective actor with
**Membership Relationship** to member Accounts.
- **Group** maps to **Group** with Membership edges; role inheritance is
authorization projection.
- **Role** maps to **Role** (authorization projection), not membership.
- **Client** maps to application **Scope** or registered resource in
authorization domain.
- **Federated identity** link maps to **Synonymity Assertion** or
**Identifier Binding** between external IdP identifier and local Account.
- **Domain** on organization is an **Identifier** used for discovery routing.
- Supports scenarios S03 (enterprise orgs), S04 (vendor/customer B2B), S05
(delegated admins via roles/groups).
## Terminology Conflicts
- **Realm vs. Tenant**: Keycloak realm is both issuer namespace and admin
partition; products often call this "tenant."
- **User vs. Member**: org member is still a realm User; membership is a
relationship overlay.
- **Organization vs. Group**: both exist; org has B2B semantics (domains, IdP),
group is generic hierarchy.
- **Role vs. Membership**: group membership implies role inheritance;
conflates relationship types.
- **Client vs. Tenant**: clients are applications, not customer isolation
boundaries.
## Candidate Canonical Mappings
| Keycloak concept | Candidate canonical concept |
| --- | --- |
| Realm | Realm (Scope) |
| User | Account |
| Organization | Organization |
| Organization membership | Membership Relationship |
| Group | Group |
| Group membership | Membership Relationship |
| Role (realm/client) | Role (authorization projection) |
| Client | Application Scope / registered client |
| Identity Provider | Trust Relationship + external issuer Scope |
| Federated identity link | Synonymity Assertion / Identifier Binding |
| User attribute | Profile attribute or Claim |
| Organization domain | Identifier (email domain) |
## Open Questions
- Should Keycloak Realm remain a **Realm** specialization or absorb **Tenant**
semantics when used as SaaS isolation?
- How should multi-org user membership be modeled when the same Account holds
Membership edges to multiple Organizations?
- Does Keycloak Organization domain verification warrant a **Claim** or
**Evidence Source** in canon?
- Should composite roles be modeled as Role aggregation or as derived
authorization projection only?
## References
- Keycloak Organizations documentation — https://www.keycloak.org/docs/latest/server_admin/#_organizations
- Keycloak Server Administration Guide — https://www.keycloak.org/docs/latest/server_admin/
- Keycloak Realm concepts — https://www.keycloak.org/docs/latest/server_admin/#_create-realm

130
infospace/assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md Normal file
View file

@ -0,0 +1,130 @@
# LDAP RFC 4519 and inetOrgPerson RFC 2798
## Source Type
Standard. RFC 4519 defines LDAP attribute types and object classes; RFC 2798
defines the `inetOrgPerson` auxiliary object class for Internet person entries.
## Domain
Directory services, enterprise identity records, and hierarchical naming.
## Why This Source Matters
LDAP directory schema, RFC 4519 attribute/object class vocabulary, and
inetOrgPerson RFC 2798.
LDAP remains the structural backbone of many enterprise directories. Its
distinguished names, organizational units, and groupOfNames semantics
precede and often underpin SCIM and IAM product models.
## Key Concepts
- **Directory Information Tree (DIT)**: hierarchical namespace of entries
identified by Distinguished Names (DNs).
- **Entry**: a collection of attribute type/value pairs with one structural
object class and optional auxiliary object classes.
- **Distinguished Name (DN)**: unique identifier within a directory; composed
of Relative Distinguished Names (RDNs) such as `cn`, `ou`, `dc`.
- **inetOrgPerson**: auxiliary object class for person entries with `cn`,
`sn`, `mail`, `uid`, `employeeNumber`, and related attributes.
- **organizationalUnit (ou)**: container for organizational structure.
- **groupOfNames / groupOfUniqueNames**: group entries with `member` or
`uniqueMember` attributes referencing member DNs.
- **posixAccount / posixGroup**: UNIX-oriented account and group semantics
with `uid`, `gid`, `homeDirectory`, and `memberUid`.
- **Attribute syntax and matching rules**: typed attributes (DirectoryString,
IA5String, JPEG) with defined comparison semantics.
- **Referrals and aliases**: indirection for distributed or aliased entries.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| person / inetOrgPerson | Directory entry representing a human; attributes, not a login session. |
| uid | User identifier string; often login name in POSIX contexts. |
| cn (commonName) | Display or legal name component of DN. |
| mail | Email address attribute; may be multi-valued. |
| employeeNumber | Workforce identifier assigned by employer. |
| ou (organizationalUnit) | Structural container in the DIT; department or division. |
| dc (domainComponent) | DNS-domain component in DN; defines directory partition. |
| member / uniqueMember | DN reference from a group entry to a member entry. |
| groupOfNames | Group requiring at least one member; membership by DN reference. |
| account (posixAccount) | UNIX account attributes bound to a person entry. |
## Modeling Assumptions
- **Identity is entry-centric**: a person is a directory entry located in a
hierarchical tree, not a free-floating actor.
- **Naming implies structure**: DN path encodes organizational placement
(`ou=Engineering,ou=People,dc=example,dc=com`).
- **Groups are entries**, not relationships; membership is an attribute on the
group entry pointing to member DNs.
- **Person and account can co-reside** on one entry (inetOrgPerson +
posixAccount auxiliary class).
- **Uniqueness** is per-directory-partition; `uid` or DN must be unique within
scope.
- **No standard org-entity object class** for corporations; org structure is
implied by `ou` containers.
- **Authorization** is external; groups are conventionally mapped to permission
sets by consuming applications.
## Identity-Canon Implications
- LDAP **inetOrgPerson entry** maps to **Identity Record** with optional
**Account** when posixAccount or login-binding attributes are present.
- **DN** and **uid** are **Identifiers** within the directory **Scope**
(namespace).
- **organizationalUnit** maps to a structural container, candidate
**Organization Unit** or scope partition — not automatically an
**Organization** actor.
- **groupOfNames** maps to **Group** with **Membership Relationship** via
member DN references.
- DN hierarchy suggests **Affiliation** or structural relationships but LDAP
does not type them explicitly.
- LDAP reinforces that **Identifier** (DN) carries locational semantics
beyond bare value identity.
## Terminology Conflicts
- **Account**: posixAccount is attribute bundle on a person entry; conflicts
with IAM Account as a distinct operational record.
- **User**: directory "user" means entry or uid; conflicts with application
session user.
- **Organization**: `ou` is a container, not a legal or commercial org actor.
- **Group**: LDAP group is an entry with member attributes; conflicts with
SCIM Group resource and social community.
- **Person**: inetOrgPerson is a schema label, not a legal natural-person
assertion.
## Candidate Canonical Mappings
| LDAP concept | Candidate canonical concept |
| --- | --- |
| inetOrgPerson entry | Identity Record |
| posixAccount attributes | Account (co-located on same entry) |
| DN | Identifier (locator + namespace) |
| uid, mail, employeeNumber | Identifier |
| organizationalUnit (ou) | Scope partition or org-unit container |
| groupOfNames entry | Group |
| member / uniqueMember | Membership Relationship |
| dc partition | Scope / Namespace |
| attribute values | Profile attributes or Claims on Identity Record |
## Open Questions
- Should DN be modeled as a compound Identifier (locator + value) or split
into Namespace Scope plus local Identifier?
- How should multi-valued `mail` attributes interact with synonymity assertions
when matching across systems?
- Does `ou` hierarchy warrant a canonical **Organizational Structure**
relationship type, or remain a naming convention?
- When inetOrgPerson and posixAccount coexist, is one Identity Record with
Account facet sufficient?
## References
- RFC 4519: LDAP Attribute Types and Object Classes — https://datatracker.ietf.org/doc/html/rfc4519
- RFC 2798: Definition of the inetOrgPerson Object Class — https://datatracker.ietf.org/doc/html/rfc2798
- RFC 4511: LDAP Protocol — https://datatracker.ietf.org/doc/html/rfc4511
- RFC 2307: POSIX account/group schema — https://datatracker.ietf.org/doc/html/rfc2307

138
infospace/assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md Normal file
View file

@ -0,0 +1,138 @@
# Ory Kratos and Keto
## Source Type
Product documentation and open-source implementation reference for Ory Kratos
(identity management) and Ory Keto (relationship-based authorization).
## Domain
Cloud-native identity management, self-service flows, and ReBAC authorization
separation.
## Why This Source Matters
Ory Kratos identity/user management and Ory Keto relationship-based
authorization separation.
Ory explicitly separates identity management (Kratos) from authorization
(Keto). This architectural split is a strong reference for identity-canon's
P6 principle (authorization projections separate from identity model).
## Key Concepts
- **Identity (Kratos)**: core identity record with traits (schema-defined
attributes), credentials, verifiable addresses, and recovery settings.
- **Traits**: JSON attributes on an identity (email, name, etc.) governed by
identity schema.
- **Credential**: password, OIDC link, TOTP, WebAuthn, or lookup secret
attached to an identity.
- **Identity schema**: JSON Schema defining allowed traits and validation.
- **Session**: authenticated session bound to an identity after credential
verification.
- **Recovery / Verification flow**: self-service processes for account
recovery and address verification.
- **Relation tuple (Keto)**: `namespace:object#relation@subject` assertion
for ReBAC checks.
- **Namespace (Keto)**: typed object class in the authorization model with
defined relations and permissions.
- **Subject (Keto)**: entity in a relation tuple; may reference a Kratos
identity or arbitrary identifier.
- **Permission check**: evaluate whether a subject has a relation to an
object in a namespace.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Identity | Kratos record with traits and credentials; not authorization entity. |
| Traits | Schema-validated attributes on an identity. |
| Credential | Authentication factor bound to identity. |
| Session | Active authenticated state for an identity. |
| Schema | JSON Schema defining identity trait structure per use case. |
| Relation tuple | Subject-relation-object fact in Keto. |
| Namespace | Authorization object type with relation definitions. |
| Subject | Authorization participant in a tuple. |
| Object | Resource or entity being authorized in a tuple. |
| Relation | Named edge type between subject and object. |
## Modeling Assumptions
- **Identity and authorization are separate services** with distinct storage
and APIs.
- **Identity means traits + credentials**, not permissions.
- **Traits are schema-driven**, allowing multiple identity schemas per
deployment (consumer vs. admin personas).
- **Sessions are ephemeral** authentication state, not identity records.
- **Authorization uses Zanzibar-style tuples** in Keto, not Kratos groups or
roles.
- **Subjects in Keto may not map 1:1** to Kratos identities; integration is
application-level.
- **No first-class organization or tenant** in Kratos core; multi-tenancy is
application concern.
## Identity-Canon Implications
- Kratos **Identity** maps to **Identity Record** with **Profile** (traits)
and **Credential** attachments.
- Kratos does not use "account" explicitly; Identity is closer to Account +
Profile combined.
- **Session** is ephemeral auth state, not a canonical entity; maps to
downstream session projection.
- **Identity schema** maps to schema governance for Profile/Identity Record
attributes in a Scope.
- Keto **relation tuple** maps to **Relationship Tuple** (authorization
projection) or typed **Relationship** with authz implication.
- Keto **namespace** maps to **Authorization Domain** Scope.
- Keto **subject** maps to **Authorization Principal** projection.
- Strong evidence for **P6**: identity store and authorization graph are
orthogonal.
- Supports S01 (single local identity), S10 (service identity via traits +
credentials), S11 (agent via separate Keto tuples).
## Terminology Conflicts
- **Identity**: Kratos Identity is a record with credentials; conflicts with
bare "identity" meaning personhood or issuer subject.
- **Subject**: Keto subject is authorization participant; OIDC subject is
issuer identifier; different layers.
- **Traits vs. Profile**: traits are stored attributes; profile is
presentation — often conflated in Kratos.
- **Namespace**: Keto namespace is authorization object type; DNS/LDAP
namespace is naming scope.
- **No user term**: Kratos avoids "user" in API, but docs sometimes use it
informally.
## Candidate Canonical Mappings
| Ory concept | Candidate canonical concept |
| --- | --- |
| Kratos Identity | Identity Record + Account facet |
| Traits | Profile attributes |
| Credential | Credential |
| Session | Ephemeral auth projection (non-canonical) |
| Identity schema | Profile/record schema in Scope |
| Keto relation tuple | Relationship Tuple (authorization projection) |
| Keto namespace | Authorization Domain Scope |
| Keto subject | Authorization Principal |
| Keto object | Authorization Resource |
| Keto relation | Relationship type (authz) |
| Verification flow | Evidence Source event |
## Open Questions
- Should Kratos Identity be split into Account + Profile in canon, or kept
as unified Identity Record?
- How should Keto subjects that reference non-Kratos identifiers (e.g.,
`group:engineering#member`) map to canonical Group + Membership?
- Does Kratos multi-schema support (consumer vs. admin) map to Persona or
separate Identity Records?
- Should session be documented as a projection type in canon or remain
explicitly out of scope?
## References
- Ory Kratos documentation — https://www.ory.sh/docs/kratos/
- Ory Keto documentation — https://www.ory.sh/docs/keto/
- Ory Kratos identity model — https://www.ory.sh/docs/kratos/manage-user-identities/identity-schema
- Ory Keto relation tuples — https://www.ory.sh/docs/keto/concepts/relation-tuples

133
infospace/assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md Normal file
View file

@ -0,0 +1,133 @@
# SCIM RFC 7643 and RFC 7644
## Source Type
Standard. RFC 7643 defines the SCIM 2.0 core schema; RFC 7644 defines the
SCIM 2.0 protocol for provisioning.
## Domain
Identity provisioning and directory synchronization.
## Why This Source Matters
SCIM 2.0: RFC 7643 schema and RFC 7644 protocol.
SCIM is the dominant platform-neutral provisioning baseline. It defines
resource types, attribute schemas, and CRUD/search operations for users and
groups without prescribing authentication or authorization semantics.
## Key Concepts
- **Resource**: a provisionable object with a `schemas` array, `id`, `meta`,
and typed attributes.
- **User resource**: a person-oriented identity record with `userName`,
`name`, `emails`, `phoneNumbers`, `addresses`, `groups`, `roles`, and
`active` lifecycle state.
- **Group resource**: a named collection with `displayName`, `members`, and
optional `type` (direct or indirect membership).
- **Enterprise User extension** (RFC 7643 §4.3): adds `employeeNumber`,
`costCenter`, `organization`, `division`, `department`, and `manager` for
workforce semantics.
- **Service Provider Config**: exposes supported features, authentication
schemes, and bulk limits.
- **Meta block**: `resourceType`, `created`, `lastModified`, `version`,
`location` — lifecycle and versioning metadata on every resource.
- **Operations**: Create, Read, Update, Delete, Search (POST /Users/.search),
and Bulk (RFC 7644 §3.7).
- **PatchOp**: partial updates via `add`, `remove`, `replace` on paths.
- **ExternalId**: cross-system correlation identifier supplied by the client.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| User | A provisionable identity record; not necessarily a login account in the consuming system. |
| Group | A named collection of members; may represent authorization, organizational, or mailing-list grouping. |
| userName | Unique identifier within the service provider's namespace; often used as login handle. |
| externalId | Client-supplied correlation key for linking to an upstream system of record. |
| active | Boolean lifecycle flag; inactive users retain the record but should lose access. |
| member | Reference (`value`, `display`, `$ref`) to a User or Group in a Group's membership list. |
| organization (extension) | Free-text employer or org name on a user; not a structured org resource. |
| manager | Reference to another User who manages this user. |
| roles | Application-specific role strings on the User resource; not RBAC policy. |
| Service Provider | The system receiving provisioned resources. |
| Client | The system sending provisioning requests. |
## Modeling Assumptions
- A **User** is the primary provisionable identity record; there is no separate
Account or Person resource type in core SCIM.
- **Groups** absorb membership semantics; there is no first-class relationship
tuple beyond group membership references.
- **Organization structure** is flattened into user attributes (department,
division, organization) rather than modeled as org entities.
- **Lifecycle** is binary (`active` true/false) with soft-disable semantics;
deletion is a separate operation.
- **Uniqueness** is scoped to the service provider; `userName` must be unique
within the SP namespace.
- **Authorization** is out of scope; `roles` and group membership are hints
that downstream systems may map to policies.
- **Multi-tenancy** is not defined; tenant isolation is an implementation
concern of the service provider.
## Identity-Canon Implications
- SCIM **User** maps to **Identity Record** (and often **Account** when the
SP uses it for login), not to **Natural Person**.
- SCIM **Group** maps to **Group** collective actor with **Membership
Relationship** edges to member records.
- `userName` and `externalId` are **Identifiers** within the SP **Scope**.
- `active` maps to **Lifecycle State** on the Identity Record.
- Enterprise extension `manager` suggests a **Representation** or reporting
relationship, but SCIM does not type it beyond a User reference.
- `organization`, `department`, `division` are attribute-level hints, not
**Organization** actors; canon should not treat them as structured org graphs.
- SCIM reinforces **P2** (person ≠ account) and **P5** (membership explicit)
but lacks actor-layer primitives.
## Terminology Conflicts
- **User**: SCIM User is a record, not a human being. Conflicts with
application "user" meaning login session holder.
- **Group**: SCIM Group may mean LDAP security group, mailing list, or org
unit depending on deployment; conflicts with social **Community**.
- **Role**: SCIM `roles` are opaque strings; conflicts with Cedar/OpenFGA
relationship-based roles and IAM permission bundles.
- **Organization**: SCIM extension `organization` is a string attribute;
conflicts with **Organization** collective actor in IAM products.
- **Active**: boolean disable vs. full lifecycle states (suspended, archived)
used in enterprise directories.
## Candidate Canonical Mappings
| SCIM concept | Candidate canonical concept |
| --- | --- |
| User resource | Identity Record (+ Account when login-enabled) |
| Group resource | Group |
| member reference | Membership Relationship |
| userName | Identifier |
| externalId | Identifier (cross-system correlation) |
| active | Lifecycle State |
| manager (extension) | Representation Relationship (weakly typed) |
| organization/department/division | Affiliation hints; not Organization actors |
| roles (extension) | Role labels; authorization projection input |
| meta.created/lastModified | Evidence timestamps for record provenance |
| Service Provider namespace | Scope |
## Open Questions
- Should SCIM `externalId` be modeled as a dedicated **Identifier Binding**
or a generic Identifier with source metadata?
- How should indirect group membership (`type: indirect`) map to canon
membership vs. inherited authorization projection?
- Does the Enterprise User `manager` reference warrant a canonical
**Reporting Relationship** distinct from Representation?
- Should a SCIM-only deployment without login map User exclusively to
Identity Record, skipping Account?
## References
- RFC 7643: SCIM 2.0 Core Schema — https://datatracker.ietf.org/doc/html/rfc7643
- RFC 7644: SCIM 2.0 Protocol — https://datatracker.ietf.org/doc/html/rfc7644
- IETF SCIM working group overview — https://datatracker.ietf.org/wg/scim/about/

130
infospace/assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md Normal file
View file

@ -0,0 +1,130 @@
# ZITADEL Organizations and Projects
## Source Type
Product documentation and implementation reference for ZITADEL's multi-instance
organization, project, and grant model.
## Domain
Cloud-native IAM, multi-tenancy, B2B SaaS identity, and fine-grained
authorization grants.
## Why This Source Matters
ZITADEL organizations, projects, roles, grants, and multi-tenancy concepts.
ZITADEL is designed for multi-tenant SaaS from the ground up. Its org →
project → grant hierarchy provides a live product vocabulary for separating
customer organizations, application projects, and role grants.
## Key Concepts
- **Instance**: ZITADEL deployment; top-level operational boundary.
- **Organization**: primary tenant/customer entity; owns users, projects,
policies, and branding.
- **Project**: application or service scope within an organization; owns roles,
applications, and grants.
- **Application**: OIDC/SAML/API client registered under a project.
- **User**: human identity within an organization with authentication methods
and profile.
- **Machine user / service user**: non-human identity for API access.
- **Grant**: assignment of project roles to a user or organization (including
cross-org grants for B2B).
- **Role**: project-scoped permission label granted via grants.
- **Organization domain**: verified domain for org discovery and policy.
- **User grant vs. org grant**: direct user-to-project role vs. org-wide
project access.
- **Actions / Flows**: customizable authentication and provisioning pipelines.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Organization | Customer or business entity; primary multi-tenant partition. |
| Project | Application or product scope within an org. |
| Grant | Role assignment linking user or org to a project. |
| Role | Named capability within a project. |
| User | Human identity record within an organization. |
| Machine user | Service identity for programmatic access. |
| Application | Registered client (OIDC/SAML/API) under a project. |
| Instance | ZITADEL deployment boundary. |
| Org grant | Organization-level access to a project's roles. |
| Domain verification | Proof that an org controls an email domain. |
## Modeling Assumptions
- **Organization is the primary customer/tenant boundary** for users and
admin delegation.
- **Project separates applications** within an org; roles are project-scoped.
- **Grants are the authorization assignment mechanism**, not group membership.
- **Users belong to exactly one organization** (per current product model);
cross-org access is via grants to shared projects.
- **Machine users are first-class** identities distinct from human users.
- **B2B** is modeled by granting one organization's project roles to another
organization's users or to the org itself.
- **Branding and login policy** are org-scoped configuration.
## Identity-Canon Implications
- ZITADEL **Organization** maps to **Organization** actor and/or **Tenant**
Scope depending on deployment (often both: org as actor, org as tenant
boundary).
- **Project** maps to **Application Scope** or child **Scope** under tenant.
- **User** maps to **Account** (human); **Machine user** maps to **Service
Account**.
- **Grant** maps to **Role** assignment via **Delegation** or Membership-like
relationship with authorization implication.
- **Role** maps to **Role** (authorization projection).
- **Application** maps to registered client within Application Scope.
- **Domain verification** maps to **Claim** or **Evidence Source** for org
domain ownership.
- Product vocabulary strongly supports S04 (vendor/customer) and S05
(delegated admin via grants).
## Terminology Conflicts
- **Organization vs. Tenant**: ZITADEL uses "organization" for what SaaS
products often call "tenant."
- **Grant vs. Membership**: grants assign roles; no generic group concept at
project level.
- **User vs. Account**: product says "user" but means org-local identity
record with credentials.
- **Project vs. Application**: project is container; application is client;
both compete with "tenant" in other products.
- **Role vs. Grant**: role is definition; grant is assignment; IAM products
often collapse these.
## Candidate Canonical Mappings
| ZITADEL concept | Candidate canonical concept |
| --- | --- |
| Instance | Scope (deployment boundary) |
| Organization | Organization + Tenant Scope |
| Project | Application Scope |
| User | Account |
| Machine user | Service Account |
| Application | Registered client / Application Scope |
| Role | Role (authorization projection) |
| Grant | Role assignment relationship (Delegation-like) |
| Org grant | Membership or Delegation at org level |
| Domain verification | Claim + Evidence Source |
| User profile | Profile |
## Open Questions
- When ZITADEL Organization serves as both commercial actor and isolation
boundary, should canon use one node with dual typing or separate Organization
+ Tenant linked by Ownership?
- How should cross-org project grants map: **Delegation**, **Trust**, or a
vendor-specific **Grant Relationship**?
- Does single-org-per-user constraint affect canon modeling of multi-org
persons (S02)?
- Should Machine user always map to Service Account, or sometimes to
Artificial Agent?
## References
- ZITADEL documentation — https://zitadel.com/docs
- ZITADEL Organizations — https://zitadel.com/docs/guides/manage/console/organizations
- ZITADEL Projects and roles — https://zitadel.com/docs/guides/manage/console/projects

114
infospace/assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md Normal file
View file

@ -0,0 +1,114 @@
# ActivityPub Actors and Followers
## Source Type
Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
federated social actors, inboxes, and follower relationships.
## Domain
Federated social graphs, actor identity, following/followers, and server-side
account representation.
## Why This Source Matters
ActivityPub treats users as server-side actors with inboxes and outboxes. A
person may have several actors across servers, mapping well to contextual
identities and personas.
## Key Concepts
- **Actor**: Activity Streams object (Person, Service, Group, Organization,
Application) with `inbox`, `outbox`, `followers`, `following`, `liked`.
- **Person actor**: human-associated actor on a federated server.
- **Service / Application actor**: automated or app-mediated actor.
- **Group actor**: collective actor with shared inbox/outbox.
- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject.
- **Followers / Following collections**: reverse-indexed social graph edges.
- **preferredUsername**: handle local to the origin server.
- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL.
- **SharedInbox**: delivery optimization for addressing multiple actors.
- **Public / followers-only addressing**: audience scoping for activities.
- **WebFinger**: discovery of actor profile from `acct:user@domain`.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. |
| Person | Actor type for human-associated accounts. |
| Follow | Directed activity establishing follower relationship. |
| Follower | Actor who follows another actor. |
| preferredUsername | Local handle on origin server. |
| Actor ID | HTTPS URI identifying actor globally. |
| Inbox / Outbox | Message endpoints for receiving/sending activities. |
| Group (actor type) | Collective actor in ActivityPub sense. |
| Service | Non-human automated actor type. |
| acct: URI | Account identifier for WebFinger discovery. |
## Modeling Assumptions
- **Actor is the primary social identity unit**, hosted on an origin server.
- **One human may operate multiple actors** across servers (implicit, not
standardized as same-person link).
- **Following is a social subscription**, not membership or authorization.
- **Actor ID is globally unique** within the fediverse namespace.
- **Server is authority** for actor existence and deletion.
- **Groups and Organizations are actor types**, not separate provisioning models.
- **No standardized account linking** across actors for same natural person.
## Identity-Canon Implications
- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association
via Account/Profile on origin server).
- **Person actor** implies **Natural Person** operator but actor ≠ person.
- **Service/Application actor** maps to **Artificial Agent**.
- **Group actor** maps to **Community** or **Group** collective actor.
- **Follow** maps to **Following Relationship** (directed, social).
- **preferredUsername** + domain maps to **Identifier** in server **Scope**.
- **Actor ID (URL)** maps to global **Identifier**.
- Multi-server actors per person support S02, S09, S14 without mandatory
synonymity.
- **followers-only** audience maps to Scope/audience boundary on Profile.
## Terminology Conflicts
- **Actor vs. User**: ActivityPub actor is server entity; apps say user.
- **Person vs. Natural Person**: Person is actor type, not verified human.
- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group.
- **Follow vs. Member**: following ≠ community membership unless separately defined.
- **Account vs. Actor**: `acct:` suggests account, but actor is richer object.
## Candidate Canonical Mappings
| ActivityPub concept | Candidate canonical concept |
| --- | --- |
| Actor (Person) | Actor + Profile + Account (on origin server) |
| Actor (Service) | Artificial Agent + Service Account |
| Actor (Group) | Community or Group collective actor |
| Actor (Organization) | Organization collective actor |
| Follow activity | Following Relationship |
| Followers/Following collections | Relationship indexes |
| preferredUsername | Identifier (local handle) |
| Actor ID (URL) | Identifier (global) |
| acct: URI | Identifier |
| Origin server domain | Scope |
| Inbox/Outbox | Operational endpoints (downstream) |
| WebFinger | Discovery protocol (downstream) |
## Open Questions
- Should cross-server actors for one Natural Person require explicit Synonymity
Assertion, or remain unlinked by default?
- Does ActivityPub Organization actor type map to Organization or Community
depending on moderation model?
- How should moved-to / moved-from actor migration (if used) map to Identifier
Binding supersession?
- Should followers-only audience be a Profile visibility Scope or separate
Relationship attribute?
## References
- W3C ActivityPub — https://www.w3.org/TR/activitypub/
- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/
- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033

113
infospace/assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md Normal file
View file

@ -0,0 +1,113 @@
# FOAF Agent Person Group OnlineAccount
## Source Type
Semantic vocabulary. FOAF (Friend of a Friend) RDF vocabulary for persons,
agents, groups, and online accounts.
## Domain
Semantic web social identity, person/agent distinction, and account
representation.
## Why This Source Matters
FOAF distinguishes persons, agents, organizations, groups, accounts, and
membership-like properties — an early explicit separation of actor, account,
and online presence.
## Key Concepts
- **foaf:Person**: a person (human); may have name, homepage, depiction.
- **foaf:Agent**: anything that can do things; superclass of Person, Organization,
Group.
- **foaf:Organization**: collective agent with members and name.
- **foaf:Group**: collective agent with `member` property linking to agents.
- **foaf:OnlineAccount**: account on a service; links via `accountServiceHomepage`
and `accountName`.
- **foaf:OnlineChatAccount / OnlineGamingAccount**: specialized account types.
- **foaf:member**: agent belongs to group (inverse of Group membership).
- **foaf:knows**: social acquaintance link between agents (not authorization).
- **foaf:mbox / mbox_sha1sum**: email or hashed email identifiers.
- **foaf:openid**: OpenID identifier for agent.
- **foaf:Document / Image**: non-agent resources.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Person | Human being in FOAF sense. |
| Agent | Anything capable of action; includes persons and collectives. |
| Organization | Named collective agent. |
| Group | Collective agent with explicit members. |
| OnlineAccount | Presence on a service with account name. |
| member | Membership link from group to agent. |
| knows | Social network acquaintance between agents. |
| accountName | Handle on a service. |
| accountServiceHomepage | Service URL defining account namespace. |
| mbox | Email identifier (often `mailto:` URI). |
## Modeling Assumptions
- **Agent is the root actionable type**; Person is a specialization.
- **Person is explicitly human**, separate from accounts.
- **OnlineAccount is not the person**; it is an account on a service linked
to an agent.
- **Groups and Organizations are agents** with member properties.
- **Social knows is weak affiliation**, not trust or authorization.
- **Identifiers (mbox, openid) are properties**, not first-class scoped objects.
- **RDF graph allows multiple incomplete assertions** about same agents.
## Identity-Canon Implications
- FOAF **Person** maps closely to **Natural Person**.
- FOAF **Agent** maps to **Actor**.
- FOAF **Organization** / **Group** map to **Organization** / **Group**
collective actors.
- FOAF **OnlineAccount** maps to **Account** with service **Scope** defined
by `accountServiceHomepage`.
- **accountName** maps to **Identifier**.
- **member** maps to **Membership Relationship**.
- **knows** maps to **Affiliation Relationship** (social, weak).
- FOAF is strong evidence for **P1** (actor root) and **P2** (person ≠ account).
- Supports S01, S08, S09 with explicit person/account split.
## Terminology Conflicts
- **Agent vs. Artificial Agent**: FOAF Agent includes humans; canon Artificial
Agent is non-human only.
- **Group vs. Community**: FOAF Group is generic collective; community implies
participation norms.
- **OnlineAccount vs. Profile**: FOAF account is service presence; profile is
broader presentation surface.
- **knows vs. Following**: knows is bidirectional acquaintance; ActivityPub
Follow is directed.
- **mbox vs. Identifier**: mbox is contact + identifier; conflation risk.
## Candidate Canonical Mappings
| FOAF concept | Candidate canonical concept |
| --- | --- |
| Person | Natural Person |
| Agent | Actor |
| Organization | Organization |
| Group | Group |
| OnlineAccount | Account |
| accountName | Identifier |
| accountServiceHomepage | Scope (service namespace) |
| member | Membership Relationship |
| knows | Affiliation Relationship |
| mbox / openid | Identifier |
| depiction / name | Profile attributes |
## Open Questions
- Should FOAF OnlineAccount always imply Account, or sometimes Profile only?
- How should `mbox_sha1sum` map for privacy-preserving synonymity (weak match)?
- Does FOAF Group map to Group only, or also Community when informal?
- Should knows remain Affiliation, or split into Following vs. acquaintance?
## References
- FOAF vocabulary specification — http://xmlns.com/foaf/spec/
- FOAF 0.99 RDF schema — http://xmlns.com/foaf/0.1/

112
infospace/assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md Normal file
View file

@ -0,0 +1,112 @@
# Schema.org Person Organization Membership
## Source Type
Semantic vocabulary. Schema.org types and properties for Person, Organization,
membership, and role-like affiliations.
## Domain
Structured data about people and organizations, SEO/social graphs, and
membership representation on the web.
## Why This Source Matters
Schema.org distinguishes persons, organizations, membership, employee roles,
and affiliation properties — widely used for web-scale person/org modeling.
## Key Concepts
- **Person**: living human; properties include `name`, `email`, `identifier`,
`sameAs`, `affiliation`, `worksFor`, `memberOf`.
- **Organization**: business, club, or other collective; `member`, `employee`,
`department`, `subOrganization`, `parentOrganization`.
- **OrganizationRole**: intermediate type linking person to organization with
`roleName`, `startDate`, `endDate`.
- **member / memberOf**: reciprocal membership between Person and Organization.
- **employee / worksFor**: employment relationship properties.
- **affiliation**: organization a person is affiliated with (looser than member).
- **sameAs**: URL of related entity — often used for weak equivalence/synonymity.
- **identifier**: PropertyValue or Text for external IDs.
- **SportsTeam / PerformingGroup**: specialized Organization subtypes.
- **ProgramMembership**: membership in a program with tier/benefits.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Person | Human being in structured data. |
| Organization | Collective entity (company, club, NGO). |
| memberOf | Person belongs to Organization. |
| member | Organization has Person as member. |
| employee | Person employed by Organization. |
| worksFor | Inverse employment link. |
| affiliation | Looser org association for Person. |
| sameAs | Related/equivalent resource URL (weak linking). |
| OrganizationRole | Named role with temporal bounds. |
| subOrganization | Org hierarchy child. |
| identifier | External ID for entity. |
## Modeling Assumptions
- **Person means human** in schema.org intent.
- **Membership and employment are properties**, not reified relationship objects
(except OrganizationRole).
- **sameAs is informal equivalence** between web resources, not verified identity.
- **Organizations can nest** via subOrganization/parentOrganization.
- **Roles can be typed** via OrganizationRole with dates.
- **No authentication or authorization** semantics.
- **Properties are multi-valued**; one person can have many memberships.
## Identity-Canon Implications
- Schema.org **Person** maps to **Natural Person**.
- **Organization** maps to **Organization** collective actor.
- **memberOf / member** map to **Membership Relationship**.
- **employee / worksFor** map to **Affiliation Relationship** or employment
specialization of Membership.
- **affiliation** maps to **Affiliation Relationship** (looser).
- **OrganizationRole** maps to **Role** relationship with temporal bounds.
- **subOrganization** maps to structural relationship between Organization
actors (child/parent).
- **sameAs** maps to **weak Synonymity Assertion** between web resources —
high conflation risk if treated as strong link.
- **identifier** maps to **Identifier** PropertyValue.
- Supports S03 (sub-orgs), S07 (informal groups as Organization subtypes), S08.
## Terminology Conflicts
- **Person vs. Profile**: schema.org Person is often used for public profile page.
- **member vs. employee**: overlapping employment semantics; not always distinct.
- **sameAs vs. Synonymity**: sameAs is SEO linking, not identity proofing.
- **Organization vs. Community**: SportsTeam/PerformingGroup blur social vs. org.
- **Role vs. OrganizationRole**: roleName may be job title or permission label.
## Candidate Canonical Mappings
| Schema.org concept | Candidate canonical concept |
| --- | --- |
| Person | Natural Person |
| Organization | Organization |
| memberOf / member | Membership Relationship |
| employee / worksFor | Affiliation or employment Membership |
| affiliation | Affiliation Relationship |
| OrganizationRole | Role + Membership with temporal bounds |
| subOrganization | Organization hierarchy Relationship |
| sameAs | Weak Synonymity Assertion (caution) |
| identifier | Identifier |
| ProgramMembership | Membership Relationship (program scope) |
## Open Questions
- Should sameAs ever promote beyond weak Synonymity without additional evidence?
- Does OrganizationRole warrant a canonical temporal Relationship subtype?
- How should ProgramMembership map vs. Community membership?
- Should subOrganization be a distinct Relationship type or Organization attribute?
## References
- Schema.org Person — https://schema.org/Person
- Schema.org Organization — https://schema.org/Organization
- Schema.org OrganizationRole — https://schema.org/OrganizationRole
- Schema.org sameAs — https://schema.org/sameAs

108
infospace/assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md Normal file
View file

@ -0,0 +1,108 @@
# WebID and Solid Profile
## Source Type
Standard and ecosystem specification. WebID (W3C CG) for decentralized
identifiers; Solid Protocol for user-controlled data pods and profiles.
## Domain
Decentralized identity-style profile discovery, user-controlled storage, and
WebID-based identification.
## Why This Source Matters
WebID/Solid support user-controlled profiles and decentralized identity-style
profile discovery, relevant to persona, identifier, and data-sovereignty
semantics.
## Key Concepts
- **WebID**: HTTP(S) URI identifying an agent; dereferencing yields profile
document (RDF).
- **WebID profile document**: RDF description of agent with type, name,
certificates, and links.
- **Solid Pod**: user-controlled personal data store with access control.
- **Solid Profile**: extended profile in pod with extended attributes and
preferences.
- **WebID-OIDC**: bridge binding OIDC authentication to WebID URI.
- **Agent type in profile**: self-described person or organization.
- **ACL (WAC / ACP)**: resource-level access control on pod resources.
- **Type Index**: registry of resource types in a pod.
- **Identity provider linkage**: OIDC issuer associated with WebID.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| WebID | HTTP URI identifying an agent; profile at same URL. |
| Profile document | RDF at WebID URI describing the agent. |
| Pod | User-controlled storage space. |
| Solid Profile | Profile data stored in pod. |
| Agent | Entity described by WebID (person or org). |
| WebID-OIDC | OIDC flow producing ID token with WebID claim. |
| ACL | Access control on pod resources. |
| Type Index | Discovery of pod resource categories. |
| issuer | OIDC provider linked to WebID authentication. |
## Modeling Assumptions
- **Identifier (WebID URI) is primary**; profile is dereferenceable description.
- **User controls data placement** in pod, not only profile attributes.
- **Agent self-describes** type (person/org) in RDF profile.
- **Authentication can bind OIDC subject to WebID** via WebID-OIDC.
- **Access control is resource-centric** on pod, separate from identity record.
- **No central directory**; discovery via URI dereferencing.
- **Multiple profiles/pods per person** possible across providers.
## Identity-Canon Implications
- **WebID URI** maps to **Identifier** (globally dereferenceable).
- **Profile document** maps to **Profile** with RDF attributes.
- **Pod** maps to user-controlled **Scope** for data storage.
- **Agent in profile** maps to **Actor** (Natural Person or Organization).
- **WebID-OIDC binding** maps to **Synonymity Assertion** / **Identifier
Binding** between OIDC `sub`+`iss` and WebID URI.
- **ACL** maps to authorization projection on resources in pod Scope.
- Supports S14 (pseudonymous/scoped identity), S02 (multiple profiles), user
sovereignty goals from ResearchSeed.
## Terminology Conflicts
- **WebID vs. DID**: both decentralized identifiers; different ecosystems and
resolution models.
- **Profile vs. Account**: Solid profile is data surface; may not include
login credentials on same system.
- **Agent vs. Actor**: WebID agent is self-described entity; canon Actor is
broader participation root.
- **Identity vs. WebID**: developers equate WebID with whole identity.
- **ACL vs. Authorization Principal**: pod ACL uses WebID URIs as agents.
## Candidate Canonical Mappings
| WebID/Solid concept | Candidate canonical concept |
| --- | --- |
| WebID URI | Identifier |
| Profile document | Profile |
| Solid Pod | Scope (user-controlled data) |
| Agent (in RDF) | Actor |
| WebID-OIDC binding | Identifier Binding / Synonymity Assertion |
| OIDC iss + sub | Scoped Identifier |
| ACL agent | Authorization Principal (WebID URI) |
| Type Index | Profile/discovery metadata |
| Pod resource | Resource (downstream) |
## Open Questions
- Should WebID URI be a distinct Identifier subtype vs. generic HTTP URI?
- How should WebID-OIDC binding strength compare to OIDC pairwise sub (S14)?
- Does pod Scope warrant a canonical "Data Scope" specialization?
- Should Solid ACL remain purely authorization projection, or inform
Relationship types for resource sharing?
## References
- Solid Protocol — https://solidproject.org/TR/protocol
- WebID 1.0 (community spec) — https://www.w3.org/2005/Incubator/webid/wiki/Identity_Providers
- WebID-OIDC — https://solid.github.io/webid-oidc-spec/
- Solid Access Control (ACP) — https://solidproject.org/TR/acl-spec

109
infospace/assimilation/canon-federation/source/research/verifiable-claims/did-core.md Normal file
View file

@ -0,0 +1,109 @@
# W3C DID Core
## Source Type
Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
## Domain
Decentralized identifiers, verifiable identity subjects, DID documents, and
verification methods.
## Why This Source Matters
DIDs provide externally controlled identifiers with cryptographic verification
methods, relevant to portable identity, issuer independence, and synonymity
across systems.
## Key Concepts
- **DID**: globally unique URI following `did:method:identifier` syntax.
- **DID subject**: entity identified by a DID; may be person, org, or thing.
- **DID controller**: entity authorized to change DID document (may differ from
subject).
- **DID document**: JSON-LD document resolved from DID; contains verification
methods, services, and controllers.
- **Verification method**: cryptographic key or proof mechanism for authentication
or signing.
- **Service endpoint**: machine-readable service URL in DID document.
- **DID method**: specific ledger or resolution rules (`did:web`, `did:key`,
`did:ion`, etc.).
- **Resolution**: process of retrieving DID document from DID URL.
- **Also-known-as / equivalentId**: related identifier properties (method-specific).
- **Delegation**: controller grants another party control via verification
relationship.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| DID | Decentralized identifier string. |
| DID subject | Entity the DID names. |
| DID controller | Party that can update DID document. |
| DID document | Resolved metadata about DID. |
| Verification method | Key/material for prove/control. |
| Service | Endpoint declaration in document. |
| DID method | Resolution and registry rules. |
| Resolve | Fetch DID document. |
| Controller | Authority over DID lifecycle. |
| Subject (DID) | Identified party; not necessarily controller. |
## Modeling Assumptions
- **Identifier is primary**; subject is named by DID, not stored in central directory.
- **Control is cryptographic** via verification methods and controllers.
- **Subject and controller may diverge** (custodial wallets, organizational DIDs).
- **DID document is mutable** under controller authority.
- **Methods vary in persistence, privacy, and registry model.**
- **No built-in person/account distinction**; semantics are method and usage dependent.
- **Relationships to other DIDs** may appear as services or custom properties.
## Identity-Canon Implications
- **DID** maps to **Identifier** (decentralized, resolvable).
- **DID subject** maps to **Actor** or target of **Claim** depending on usage.
- **DID controller** maps to **Representation** or **Ownership** relationship
over identifier control.
- **Verification method** maps to **Credential** (cryptographic).
- **DID document** maps to **Profile** / metadata record for Identifier.
- **Service endpoint** maps to operational binding (downstream).
- DID-based strong binding supports S13 (verified link), S14 (pseudonymous
scoped identity when using pairwise/privacy-preserving methods).
- Reinforces **P8** (evidence via cryptographic verification).
## Terminology Conflicts
- **Subject**: DID subject vs. OIDC sub vs. authorization subject.
- **Controller vs. Owner**: controller is key/document authority; owner is
broader relationship.
- **Identity vs. DID**: DID is identifier, not identity record.
- **Credential vs. Verification method**: verification method is key material;
VC is claim artifact.
- **Resolve vs. Lookup**: resolution is method-specific; not uniform directory.
## Candidate Canonical Mappings
| DID Core concept | Candidate canonical concept |
| --- | --- |
| DID | Identifier |
| DID subject | Actor (context-dependent) |
| DID controller | Representation or Ownership Relationship |
| DID document | Profile / Identifier metadata record |
| Verification method | Credential |
| Service endpoint | Operational binding (downstream) |
| DID method namespace | Scope (method-specific) |
| Resolution result | Evidence Source |
| equivalentId / alsoKnownAs | Synonymity Assertion (method-dependent) |
## Open Questions
- Should DID be a distinct Identifier subtype with method and resolution metadata?
- How should subject/controller split map for organizational vs. personal DIDs?
- Does equivalentId warrant weak or strong Synonymity by default?
- How do DID methods with pairwise features (e.g., did:ion pairwise) map to
Scoped Identifier?
## References
- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/

106
infospace/assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md Normal file
View file

@ -0,0 +1,106 @@
# OpenID for Verifiable Credentials (OpenID4VC)
## Source Type
Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related
OAuth 2.0 profiles for verifiable credentials.
## Domain
VC issuance and presentation protocols, wallet-holder flows, and federation of
verifiable credential ecosystems.
## Why This Source Matters
OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials,
connecting federation protocols to portable claim semantics.
## Key Concepts
- **OpenID4VCI**: issuer-to-holder credential issuance using OAuth 2.0 access
tokens and credential offers.
- **OpenID4VP**: holder-to-verifier presentation using authorization requests
and VP tokens.
- **Credential Issuer**: OIDC/OAuth entity issuing VCs.
- **Wallet / Holder**: stores credentials and responds to presentation requests.
- **Verifier**: requests and validates presentations.
- **Credential Offer**: deeplink/URI initiating issuance to wallet.
- **Proof of possession**: holder proves control of key bound to credential.
- **Authorization Request (VP)**: verifier specifies required credential types.
- **SD-JWT VC**: selective disclosure JWT credential format (parallel track).
- **mDL / ISO 18013-5**: mobile document format integrated in some profiles.
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Credential Issuer | OAuth/OIDC party issuing VCs. |
| Wallet | Holder software storing VCs. |
| Verifier | Party requesting VP from wallet. |
| Credential offer | Issuance initiation artifact. |
| Authorization request | Presentation request to wallet. |
| VP token | Presentation response token. |
| c_nonce | Issuance proof challenge. |
| format | VC encoding (jwt_vc, ldp_vc, sd-jwt). |
| credential_definition | Type/filter for requested credential. |
| presentation_definition | Verifier's input requirements. |
## Modeling Assumptions
- **Issuance is OAuth-mediated** between issuer, wallet, and optional broker.
- **Presentation is verifier-driven** with explicit requested claim types.
- **Holder wallet is trust boundary** for credential storage and selective disclosure.
- **OIDC identity may bootstrap wallet** or issuer trust.
- **Multiple credential formats** coexist (JWT, JSON-LD, SD-JWT).
- **Revocation/status checked at verification** time.
- **Pairwise issuance** possible for privacy-preserving credentials.
## Identity-Canon Implications
- OpenID4VCI issuance flow maps to **Credential** creation with **Claim**,
**Issuer** Scope, and **Evidence Source** (issuance event).
- OpenID4VP presentation maps to verifier **Trust Relationship** evaluating
**Credential** + **Claim** subset.
- **Wallet** maps to holder **Actor** + storage **Scope** (custody boundary).
- OIDC authentication preceding issuance maps to **Authenticated Subject** →
**Account** → VC **Subject** binding via **Identifier Binding**.
- Selective disclosure supports S14 (privacy-limited claims).
- Bridges federation (OIDC) and VC layers for S13 strong links.
- Reinforces projection pattern: OIDC for auth, VC for claims.
## Terminology Conflicts
- **Issuer**: OIDC issuer vs. VC issuer — often same entity, different roles.
- **Subject**: OIDC sub in token vs. VC credentialSubject.
- **Credential**: OAuth credential vs. Verifiable Credential.
- **Verifier vs. RP**: overlapping roles with added VP verification.
- **Wallet vs. Account**: wallet is credential store, not always login account.
## Candidate Canonical Mappings
| OpenID4VC concept | Candidate canonical concept |
| --- | --- |
| Credential Issuer | Issuer Scope + Trust Relationship |
| Wallet / Holder | Actor (custody) + Scope |
| Verifier | Verifier / RP Scope |
| Issued VC | Credential + Claim |
| Credential offer | Evidence Source (issuance initiation) |
| Presentation | Credential presentation (operational) |
| OIDC auth prior to issuance | Authenticated Subject → Identifier Binding |
| presentation_definition | Verifier policy (downstream) |
| SD-JWT selective disclosure | Privacy-limited Claim exposure |
| Status check | Lifecycle State verification |
## Open Questions
- Should wallet custody be a canonical Scope specialization (Holder Scope)?
- How should OIDC sub to VC subject binding strength be classified (weak vs.
strong Synonymity)?
- Does OpenID4VP verifier policy belong in canon or strictly downstream?
- Should SD-JWT credentials map to Credential subtype with disclosure metadata?
## References
- OpenID4VCI — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
- OpenID4VP — https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
- OpenID4VCI SD-JWT profile — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-sd-jwt-vc

110
infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md Normal file
View file

@ -0,0 +1,110 @@
# W3C Verifiable Credentials Data Model 2.0
## Source Type
Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).
## Domain
Verifiable claims, issuers, holders, verifiers, credential lifecycle, and
portable identity assertions.
## Why This Source Matters
Verifiable Credentials formalize issuer-holder-verifier semantics for portable,
cryptographically verifiable claims about subjects — central to evidence-based
identity modeling.
## Key Concepts
- **Verifiable Credential (VC)**: tamper-evident credential making claims about
a subject, signed by issuer.
- **Verifiable Presentation (VP)**: bundle of VCs (and proofs) presented by holder
to verifier.
- **Issuer**: entity that asserts claims and signs VC.
- **Holder**: entity possessing VC (may or may not be subject).
- **Verifier**: entity checking VC/VP validity.
- **Subject**: entity claims are about (`credentialSubject`).
- **Claim**: individual statement within credentialSubject.
- **Proof**: cryptographic proof of integrity and issuer authenticity.
- **Credential schema**: type and structure definition for VC.
- **Status**: revocation/suspension via StatusList2021 or similar.
- **ValidFrom / ValidUntil**: temporal validity window.
- **Evidence**: supporting documents referenced in VC (DID, attachments).
## Relevant Terminology
| Term | Source meaning |
| --- | --- |
| Verifiable Credential | Signed claim set about subject. |
| Presentation | Holder-submitted package for verification. |
| Issuer | Signing authority for claims. |
| Holder | Party storing/presenting VC. |
| Verifier | Party validating VC/VP. |
| Subject | Entity described by credentialSubject. |
| credentialSubject | Claim object about subject. |
| Proof | Cryptographic verification data. |
| StatusList | Revocation/suspension mechanism. |
| type | VC semantic type(s). |
| validFrom / validUntil | Temporal bounds. |
## Modeling Assumptions
- **Claims are assertions, not ground truth** until verified by verifier policy.
- **Issuer authority is explicit** and cryptographically attributable.
- **Holder may differ from subject** (custodial credentials).
- **Revocation is first-class** via status mechanisms.
- **Temporal validity matters** for employment, membership, age claims.
- **Selective disclosure** may hide parts of credentialSubject (privacy).
- **Subject may be identified by DID, URI, or other identifier.**
## Identity-Canon Implications
- **VC** maps to **Credential** containing **Claim** set.
- **credentialSubject** claims map to individual **Claim** objects about
**Actor**, **Membership**, or attributes.
- **Issuer** maps to issuer **Scope** + **Trust Relationship**.
- **Holder** maps to **Actor** or **Account** holding credential.
- **Verifier** maps to relying party evaluating Trust + Evidence.
- **Subject** maps to **Actor** or Identifier target.
- **Status/revocation** maps to **Lifecycle State** on Credential/Claim.
- **validFrom/validUntil** map to relationship/assertion temporal bounds.
- Supports S13 (strong verified link), S03 (org membership claims), S06
(guardian credentials if issued).
- Reinforces **P7** and **P8**: claims are evidenced assertions.
## Terminology Conflicts
- **Credential vs. Credential (auth)**: VC vs. password/OIDC token.
- **Subject**: VC subject vs. OIDC sub.
- **Claim vs. Attribute**: VC claim vs. directory/LDAP attribute.
- **Holder vs. Account**: holder is possession role, not login account.
- **Verifier vs. RP**: overlapping but VC adds cryptographic verification step.
## Candidate Canonical Mappings
| VC Data Model concept | Candidate canonical concept |
| --- | --- |
| Verifiable Credential | Credential |
| credentialSubject claim | Claim |
| Issuer | Issuer Scope + Trust Relationship |
| Holder | Actor / Account (possession role) |
| Verifier | Relying party / verifier Scope |
| Subject | Actor or Identifier target |
| Proof | Evidence Source (cryptographic) |
| StatusList entry | Lifecycle State (revoked/suspended) |
| validFrom / validUntil | Temporal bounds on Claim |
| Presentation | Credential bundle (operational) |
## Open Questions
- Should canon treat VC as Credential subtype or parallel Claim container?
- How should membership VCs map to Membership Relationship vs. Claim only?
- Does selective disclosure require Persona or Scoped Identifier linkage?
- Should issuer DID vs. issuer URL be standardized Identifier forms?
## References
- W3C VC Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/
- VC Data Model 1.1 (widely deployed) — https://www.w3.org/TR/vc-data-model/
- Status List 2021 — https://www.w3.org/TR/vc-status-list-2021/

194
infospace/assimilation/canon-federation/source/scenarios/ScenarioTests.md Normal file
View file

@ -0,0 +1,194 @@
# Scenario Tests
Status: draft. These are narrative tests for the conceptual model. They are
not executable tests yet; they define expected representation checks for future
model revisions.
## Test Format
- Scenario: concrete identity situation.
- Expected representation: the canonical concepts that should be used.
- Checks: conditions the model must satisfy without collapsing terms.
## S01. Single Person With One Local Account
Expected representation: one Natural Person, one Account in an application
Scope, one local Identifier, one Profile, and one Membership or access
relationship if the account belongs to a group.
Checks:
- The person is not identical to the account.
- The profile is not the credential.
- Authorization can project the account or subject into a Principal.
## S02. Person With Multiple Accounts Across Scopes
Expected representation: one Natural Person, multiple Accounts, one Account
per Scope, and optional Synonymity Assertions linking account records.
Checks:
- Each account keeps its source and lifecycle state.
- Linking accounts does not merge them destructively.
- Different scopes can use different identifiers.
## S03. Enterprise With Sub-Organizations
Expected representation: Organization actors linked by structural
relationships, plus Accounts and Membership relationships scoped to relevant
systems.
Checks:
- Sub-organization is not automatically a tenant.
- Legal entity status is modeled separately.
- Membership and administration relationships are explicit.
## S04. Vendor Tenant Serving Customer Tenants
Expected representation: Vendor and Customer relationship roles between
Organization actors; Tenant scopes for platform isolation; optional
Administration relationships for delegated support.
Checks:
- Customer is not collapsed into Tenant.
- Vendor is not collapsed into Realm.
- Cross-tenant administration is scoped and evidenced.
## S05. Customer Organization With Delegated Administrators
Expected representation: Organization actor, Tenant scope, administrator
Accounts, Delegation and Administration relationships.
Checks:
- Admin rights are relationships, not just group names.
- Delegation has source, target, scope, and lifecycle state.
- Authorization projection can consume the relationship separately.
## S06. Family With Guardian And Dependent Accounts
Expected representation: Family or Household collective actor, Natural Person
actors, guardian/dependent relationships, child Accounts, and privacy
constraints.
Checks:
- Guardian relationship is not generic membership.
- Household and legal family can differ.
- Privacy-sensitive links can be scoped.
## S07. Spontaneous Interest Group
Expected representation: Community or Group collective actor, Membership
relationships, optional moderator Administration relationships.
Checks:
- Informal group does not need legal entity or tenant semantics.
- Moderation is not the same as membership.
- Group identity can exist without strong real-world identity proofing.
## S08. Community With Members, Moderators, And Followers
Expected representation: Community actor; Membership relationships for
members; Administration or moderation relationships for moderators; Following
relationships for followers.
Checks:
- Follower is not a member unless the source says so.
- Moderator authority is explicit and scoped.
- Public profile can differ from account.
## S09. Social Media Follower Graph
Expected representation: Actor or Persona profiles connected by Following
relationships in a social Scope.
Checks:
- Following is directed.
- Following does not imply affiliation, membership, trust, or authorization.
- Pseudonymous profiles can remain scoped.
## S10. Bot Or Service Account Acting For An Organization
Expected representation: Artificial Agent actor, Service Account, Organization
actor, Representation or Delegation relationship, and Credential records.
Checks:
- Bot is not a natural person.
- Service account has an owner or responsible actor.
- Delegated authority has bounded scope and lifecycle.
## S11. AI Agent Acting Under Delegated Authority
Expected representation: Artificial Agent actor, Account or Service Account,
Delegation relationship from a Natural Person or Organization, and audit or
evidence references for actions.
Checks:
- Delegation identifies who granted authority.
- Agent actions can be attributed without treating the agent as the person.
- Authorization projection can include delegated context.
## S12. Weak Identity Match From Imported Data
Expected representation: source Identity Records linked by a weak Synonymity
Assertion with method, evidence, confidence, scope, and lifecycle state.
Checks:
- Weak match does not merge accounts.
- Consumers can reject or quarantine weak links.
- Evidence source remains visible.
## S13. Strong Account Link After Explicit Verification
Expected representation: Accounts linked by a strong Synonymity Assertion or
Account Link relationship, with verification evidence and revocation path.
Checks:
- Strong link is still scoped.
- Verification method is recorded.
- Revocation or unlinking is possible.
## S14. Pseudonymous Profile Linked Only Within A Restricted Scope
Expected representation: Persona or Profile with Scoped Identifier and
privacy-limited Synonymity Assertion visible only inside an allowed Scope.
Checks:
- Public consumers cannot infer the hidden link.
- The pseudonym can have relationships independent of legal identity.
- Scope boundaries are explicit.
## S15. Organization Represented By A Legal Entity And Operational Tenants
Expected representation: Organization actor, Legal Entity specialization or
relationship, one or more Tenant scopes, and Representation relationships for
authorized persons or agents.
Checks:
- Legal entity and tenant are separate model elements.
- Multiple tenants can relate to one organization.
- Representation authority is scoped and evidenced.
## Current Result
After IDENTITY-WP-0003 corpus backfill, `model/ConceptualModel.md` documents
an explicit representation path for each scenario (S01–S15). All fifteen
scenarios remain representable without glossary or principle changes.
Remaining ambiguities are tracked in `OpenQuestions.md` (Realm promotion,
mandatory Synonymity Assertion fields). Customer Account is resolved: use
Commercial Record for billing-side artifacts. These affect refinement, not
scenario satisfiability.

230
infospace/assimilation/canon-federation/source/terminology/TerminologyConflictMap.md Normal file
View file

@ -0,0 +1,230 @@
# Terminology Conflict Map
Status: draft. Revised after IDENTITY-WP-0003 corpus backfill. Each conflict
includes source-backed examples from populated research notes.
## Conflict: User
Problem: `user` can mean a person, account, login credential holder,
application profile, authorization subject, or product-facing actor.
Source evidence:
- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
`zitadel-organizations-projects.md`)
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)
Canonical stance: do not use `user` as a root concept.
Current mapping rule:
- Provisioning record (SCIM/LDAP) → Identity Record
- Login-enabled product record → Account
- Public/local display → Profile
- Access evaluation → Principal or Authenticated Subject
- Human being → Natural Person
## Conflict: Identity
Problem: `identity` can mean selfhood, a directory record, an issuer-bound
subject, a set of claims, a DID, a credential, a profile, or an account.
Source evidence:
- Kratos Identity = traits + credentials (`ory-kratos-keto.md`)
- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`)
- DID is identifier, not identity record (`did-core.md`)
- VC credentialSubject = claims about subject (`vc-data-model-2.md`)
Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
Claim, Credential, Profile, Persona, or Synonymity Assertion.
## Conflict: Account
Problem: account can mean login account, customer billing account, social
media handle, service account, or FOAF online presence.
Source evidence:
- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)
Canonical stance: Account is operational access record in a scope. Billing
records map to Commercial Record; commercial parties use Customer/Vendor roles
and Commercial Relationship.
## Conflict: Subject, Principal, Actor
Problem: protocols, authorization engines, and social models overload these terms.
Source evidence:
- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)
Canonical stance:
- Actor = conceptual participant
- Authenticated Subject = issuer/protocol view
- Authorization Principal = decision-engine projection
## Conflict: Tenant, Realm, Organization, Customer
Problem: multi-tenant products collapse isolation boundaries and commercial actors.
Source evidence:
- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)
Canonical stance:
- Tenant = administrative/isolation scope
- Realm = issuer/admin namespace (Scope specialization)
- Organization = collective actor
- Customer = commercial relationship role
Model relationships among them; do not synonymize.
## Conflict: Group, Role, Team, Community
Problem: IAM groups, collaboration teams, social communities, and authz member
relations use overlapping labels.
Source evidence:
- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes)
- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`)
- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`)
- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`)
- Schema.org Organization subtypes include SportsTeam (`schema-org` note)
Canonical stance:
- Group = named collection with membership
- Role = capability bundle or relationship label
- Team = collaboration group or org unit
- Community = participation-oriented collective actor
## Conflict: Member, Follower, Affiliate
Problem: membership, following, affiliation, and authz member relations hide
distinct semantics behind `member`.
Source evidence:
- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`)
- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`)
- OpenFGA organization#member = authz projection (`openfga-modeling.md`)
- FOAF member = group membership; knows = acquaintance (`foaf` note)
Canonical stance: use typed relationships with scope and evidence.
## Conflict: Profile And Persona
Problem: profiles are account records, RDF documents, public pages, or VC subjects.
Source evidence:
- WebID profile document = RDF at URI (`webid-solid-profile.md`)
- Kratos traits often called profile informally (`ory-kratos-keto.md`)
- ActivityPub actor profile = public actor representation
- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes)
Canonical stance:
- Profile = presentation surface in scope
- Persona = deliberate contextual presentation with privacy boundaries
## Conflict: Identifier, Credential, Claim
Problem: tokens and documents bundle all three.
Source evidence:
- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`)
- VC = signed claims with proof (`vc-data-model-2.md`)
- DID verification method = cryptographic credential (`did-core.md`)
- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`)
Canonical stance: identifier refers; credential proves; claim states.
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
## Conflict: Credential (Auth) vs. Verifiable Credential
Problem: "credential" means password, OIDC token, or W3C VC.
Source evidence:
- NIST authenticator/credential (`nist-800-63-4.md`)
- VC Data Model verifiable credential (`vc-data-model-2.md`)
- OpenID4VC bridges OAuth credential terminology with VCs (`openid4vc.md`)
Canonical stance: use Credential with context. VC maps to Credential containing
Claims; login secrets map to Credential (authentication factor).
## Conflict: Issuer
Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.
Source evidence:
- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
- VC issuer signs credential (`vc-data-model-2.md`)
- NIST CSP performs proofing (`nist-800-63-4.md`)
Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
role when mapping.
## Conflict: Customer Account
Problem: `customer account` collapses login account, B2B subscriber organization,
Stripe billing customer, and CRM account into one product noun.
Source evidence:
- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)
Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:
- login/access → Account;
- subscribing company → Organization + Customer role + Tenant;
- billing/CRM → Commercial Record;
- vendor↔customer link → Commercial Relationship.
## Review Queue
- [x] Customer Account — resolved; use Commercial Record + Commercial Relationship.
- [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope
specialization; promote in glossary if scenario review confirms.
- [ ] Split authz `member` relation from social Membership in downstream adapters.
- [ ] Classify schema.org sameAs default strength — corpus says weak only.
- [ ] Standardize assurance dimensions — NIST IAL/AAL/FAL as orthogonal metadata.

162
infospace/assimilation/canon-federation/source/terminology/TerminologyInventory.md Normal file
View file

@ -0,0 +1,162 @@
# Terminology Inventory
Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Mappings remain
candidate until reviewed against `canon/CanonicalGlossary.md` and scenario
tests.
## Use
Use this file to collect source terms and their current candidate canonical
home. Use `terminology/TerminologyConflictMap.md` when a term is overloaded or
has incompatible meanings across source families.
## Inventory
| Term | Candidate canonical concept | Source families | Notes |
| --- | --- | --- | --- |
| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. |
| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. |
| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. |
| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. |
| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. |
| identifier | Identifier | OIDC sub, SAML NameID, LDAP DN, DID, WebID | Value referring within or across scopes. See Scoped Identifier when correlation is limited. |
| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. |
| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. |
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. |
| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. |
| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. |
| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. |
| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. |
| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. |
| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. |
| machine user | Service Account | ZITADEL | Product term for non-human org identity. |
| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. |
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. |
| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
| stripe customer | Commercial Record | Stripe, billing | Billing object; link to Tenant via metadata. Not Account. |
| payment method / pm_xxx | Payment Instrument Reference | Stripe, Adyen | Tokenized provider reference; not Credential; not CHD in canon. |
| payment mandate / setup intent | Payment Mandate (Commercial Commitment) | Stripe, SEPA | Authorization to charge; commitment_type payment_mandate. |
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
| opportunity (crm) | Pipeline Pursuit | Salesforce, HubSpot | In-flight deal; not Commercial Commitment until binding trigger. |
| forecast commit (salesforce) | Pipeline Pursuit metadata | Salesforce | Sales forecast category; not Commercial Commitment. |
| closed won | Pipeline Pursuit lifecycle + optional commitment | CRM | Won stage alone does not auto-create active commitment. |
| quote accepted / loi signed | Commercial Commitment (proposed) | CPQ, sales | Binding trigger with document evidence. |
| crm account | Commercial Record | Salesforce, CRM | Commercial record; not login Account. |
| customer account | Resolve by layer | billing, IAM, CRM | Not canonical — see TerminologyConflictMap. |
| commercial record | Commercial Record | Stripe, CRM, billing | Record layer; payment/subscription/commerce state. |
| commercial relationship | Commercial Relationship | vendor/customer SaaS | Vendor-to-customer typed relationship. |
| commercial commitment | Commercial Commitment | contracts, subscriptions, KYC | Binding obligation raising identity stakes. |
| beneficial owner | Beneficial Owner + Beneficial Ownership Relationship | KYC/AML, FinCEN CDD, FATF R24 | Natural person behind legal entity customer; dedicated relationship type with ownership/control prongs. |
| beneficial ownership | Beneficial Ownership Relationship | FinCEN CDD, BOI, Open Ownership | Regulated Natural Person → Organization/Legal Entity linkage; not Ownership subtype. |
| lei | Registry Identifier (regulatory_global) | GLEIF, ISO 17442, ICD 0199 | Legal entity identifier with annual renewal. |
| duns | Proxy Commercial Identifier | D&B, ICD 0060 | Commercial-proxy registry identifier. |
| uei | Registry Identifier (government_registry) | SAM.gov | US federal entity identifier. |
| company registration number | Registry Identifier (government_registry) | national registers, ALEI | Authoritative incorporating-register identifier. |
| alei / ibrn | Registry Identifier (government_registry) | ISO 8000-116 | Authoritative legal entity identifier from government register. |
| iso 6523 / icd | Registry Identifier scheme | ISO/IEC 6523, PEPPOL | ICD + organization identifier encoding. |
| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
| paydex | Performance Evidence | D&B | Observed-tier payment performance metric. |
| reputation | Resolve by assurance tier | marketplaces, credit | Not canonical — see Counterparty Assurance Gradient. |
| star rating / review | Reputation Signal | Yelp, Amazon, App Store | Opinion-tier Evidence Source; weak, gamable. |
| feedback score | Reputation Signal | eBay, Uber | Platform-local opinion tier. |
| credit score | Performance Evidence | bureaus, D&B | Observed-tier counterparty metric. |
| performance bond / surety | Commercial Commitment | construction, procurement | Committed-tier financial assurance. |
| escrow | Commercial Commitment | marketplaces, Stripe | Committed-tier funds segregation. |
| arbitration award | Adjudication Outcome | AAA, ICC, JAMS | Adjudicated-tier dispute result. |
| court judgment | Adjudication Outcome | courts | Adjudicated-tier enforcement outcome. |
| assurance gradient | Counterparty Assurance Gradient | commercial identity | Four-tier reliance model (opinion → adjudicated). |
| control_basis | Beneficial Ownership Relationship metadata | FinCEN CDD, EU AMLD | Settled role enum (chief_executive, managing_member, …). |
| binding_trigger | Pipeline Pursuit promotion | CRM adapters | Settled enum (quote_accepted, contract_executed, …). |
| fincen id | Registry Identifier (government_registry) | BOI | Natural person government registry ID. |
| person account | Natural Person + Commercial Record | Salesforce B2C | Adapter projection_mode person_account_combined only. |
| ncage / cage | Registry Identifier (industry_association) | defense procurement | Industry association authority class. |
| network token | Payment Instrument Reference | Visa VTS, MDES | instrument_type network_token. |
| escrow (platform) | Commercial Commitment (escrow) | marketplaces | Committed tier when funds segregated. |
| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. |
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
| fluid identity | Persona / weak binding | theory | Low commercial stake; intentional mutability. |
| bound identity | Commercial Commitment present | theory | High counterparty reliance; stable identifiers. |
| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. |
| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. |
| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. |
| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. |
| instance | Scope | ZITADEL | Deployment-level boundary above organizations. |
| project | Application Scope | ZITADEL | Application/product container within org. |
| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. |
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. |
| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. |
| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. |
| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. |
| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. |
| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. |
| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. |
| follow | Following Relationship | ActivityPub | Activity establishing follower edge. |
| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. |
| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. |
| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. |
| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. |
| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. |
| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. |
| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. |
| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. |
| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. |
| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. |
| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. |
| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. |
| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. |
| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. |
| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. |
| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. |
| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. |
| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. |
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. |
| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. |
| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. |
| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. |
| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. |
| distinguished name | Identifier | LDAP | Compound locator in directory namespace. |
| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. |
| traits | Profile attributes | Kratos | Schema-validated identity attributes. |
| verification method | Credential | DID Core | Cryptographic key in DID document. |
| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. |
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. |
| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. |
| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. |
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. |
| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. |
| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. |
| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. |
| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. |
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. |
| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. |
| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. |
## Source Note Citations
Terms above are grounded in backfilled notes under:
- `research/identity-provisioning/` (5 notes)
- `research/authentication-federation/` (4 notes)
- `research/authorization-relationships/` (4 notes)
- `research/social-community-graphs/` (4 notes)
- `research/verifiable-claims/` (3 notes)
- `research/entity-resolution-privacy/` (3 notes)
- `research/commercial-subscription/` (2 notes)
- `research/commercial-identity/` (8 notes)
## Remaining Backfill Needs
- Split `group` into authorization group vs. social collective where sources
disagree (OpenFGA member vs. ActivityPub follower).
- Add product-version qualifiers when Keycloak/ZITADEL models evolve.
- Promote stable mappings to `canon/CanonicalGlossary.md` after scenario
review.

111
infospace/assimilation/canon-federation/views/family-area.md Normal file
View file

@ -0,0 +1,111 @@
# family-area provenance reading index
Historical input only. Current canon and ADR-006 override superseded assertions.
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c.
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
## Shared terminology and scenario fragments
### S06. Family With Guardian And Dependent Accounts
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 71–82; SHA-256 `a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106`.
Historical wording; this is not a current model definition.
```text
## S06. Family With Guardian And Dependent Accounts
Expected representation: Family or Household collective actor, Natural Person
actors, guardian/dependent relationships, child Accounts, and privacy
constraints.
Checks:
- Guardian relationship is not generic membership.
- Household and legal family can differ.
- Privacy-sensitive links can be scoped.
```
### Conflict: Synonymity, Linking, Matching, Merge
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
Historical wording; this is not a current model definition.
```text
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
```
### pan / cvv / chd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
Historical wording; this is not a current model definition.
```text
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
```
### crm account
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 79–79; SHA-256 `9b1dcdfbe61b780895d51b439da2dffc0df0df7cc4dfb4d57de7dd3f8eb30d0e`.
Historical wording; this is not a current model definition.
```text
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
```
### family
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 89–89; SHA-256 `b1494107b59c6ed89546a86eeb073414ee575a2376f3c695ecb23b5c2668e32d`.
Historical wording; this is not a current model definition.
```text
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
```
### household
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 90–90; SHA-256 `0719bdf791feaaf5a70b1990b2ea38f730312c1addbbdd6562ddb0b7abbb75ed`.
Historical wording; this is not a current model definition.
```text
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
```
### policy
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
Historical wording; this is not a current model definition.
```text
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
```
### contextual tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
Historical wording; this is not a current model definition.
```text
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
```

301
infospace/assimilation/canon-federation/views/itc-access.md Normal file
View file

@ -0,0 +1,301 @@
# itc-access provenance reading index
Historical input only. Current canon and ADR-006 override superseded assertions.
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
- [research/authentication-federation/nist-800-63-4.md](../source/research/authentication-federation/nist-800-63-4.md) — 8697b739399c.
- [research/authentication-federation/oidc-core-subject-identifiers.md](../source/research/authentication-federation/oidc-core-subject-identifiers.md) — e1a0bf8a2754.
- [research/authentication-federation/saml-nameid-federation.md](../source/research/authentication-federation/saml-nameid-federation.md) — 394457cf75d2.
- [research/authentication-federation/shared-signals-caep-risc.md](../source/research/authentication-federation/shared-signals-caep-risc.md) — 7303fd449a83.
- [research/authorization-relationships/cedar-principal-action-resource-context.md](../source/research/authorization-relationships/cedar-principal-action-resource-context.md) — 1932a8632dd3.
- [research/authorization-relationships/cerbos-abac-derived-roles.md](../source/research/authorization-relationships/cerbos-abac-derived-roles.md) — c35f15042d45.
- [research/authorization-relationships/openfga-modeling.md](../source/research/authorization-relationships/openfga-modeling.md) — e2d03ddfa7be.
- [research/authorization-relationships/zanzibar-rebac.md](../source/research/authorization-relationships/zanzibar-rebac.md) — 1f736195ab4b.
- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf.
- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25.
- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3.
- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f.
- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3.
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
## Shared terminology and scenario fragments
### S01. Single Person With One Local Account
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 13–24; SHA-256 `0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5`.
Historical wording; this is not a current model definition.
```text
## S01. Single Person With One Local Account
Expected representation: one Natural Person, one Account in an application
Scope, one local Identifier, one Profile, and one Membership or access
relationship if the account belongs to a group.
Checks:
- The person is not identical to the account.
- The profile is not the credential.
- Authorization can project the account or subject into a Principal.
```
### Conflict: User
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 6–28; SHA-256 `03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6`.
Historical wording; this is not a current model definition.
```text
## Conflict: User
Problem: `user` can mean a person, account, login credential holder,
application profile, authorization subject, or product-facing actor.
Source evidence:
- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
`zitadel-organizations-projects.md`)
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)
Canonical stance: do not use `user` as a root concept.
Current mapping rule:
- Provisioning record (SCIM/LDAP) → Identity Record
- Login-enabled product record → Account
- Public/local display → Profile
- Access evaluation → Principal or Authenticated Subject
- Human being → Natural Person
```
### Conflict: Identity
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 29–43; SHA-256 `acf3297ff3ac425a535639c97c8e9368833d0e4e78225679263bcd5ab6ecbbed`.
Historical wording; this is not a current model definition.
```text
## Conflict: Identity
Problem: `identity` can mean selfhood, a directory record, an issuer-bound
subject, a set of claims, a DID, a credential, a profile, or an account.
Source evidence:
- Kratos Identity = traits + credentials (`ory-kratos-keto.md`)
- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`)
- DID is identifier, not identity record (`did-core.md`)
- VC credentialSubject = claims about subject (`vc-data-model-2.md`)
Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
Claim, Credential, Profile, Persona, or Synonymity Assertion.
```
### Conflict: Subject, Principal, Actor
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 60–79; SHA-256 `5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb`.
Historical wording; this is not a current model definition.
```text
## Conflict: Subject, Principal, Actor
Problem: protocols, authorization engines, and social models overload these terms.
Source evidence:
- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)
Canonical stance:
- Actor = conceptual participant
- Authenticated Subject = issuer/protocol view
- Authorization Principal = decision-engine projection
```
### Conflict: Identifier, Credential, Claim
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 150–162; SHA-256 `ff9f6502a126229aa65ea20817e698285a74df128aa35ea286cf24f87462216e`.
Historical wording; this is not a current model definition.
```text
## Conflict: Identifier, Credential, Claim
Problem: tokens and documents bundle all three.
Source evidence:
- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`)
- VC = signed claims with proof (`vc-data-model-2.md`)
- DID verification method = cryptographic credential (`did-core.md`)
- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`)
Canonical stance: identifier refers; credential proves; claim states.
```
### Conflict: Synonymity, Linking, Matching, Merge
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
Historical wording; this is not a current model definition.
```text
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
```
### Conflict: Issuer
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 191–203; SHA-256 `e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7`.
Historical wording; this is not a current model definition.
```text
## Conflict: Issuer
Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.
Source evidence:
- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
- VC issuer signs credential (`vc-data-model-2.md`)
- NIST CSP performs proofing (`nist-800-63-4.md`)
Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
role when mapping.
```
### subject
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 25–25; SHA-256 `904b2af8c84d271ad315098c387b00d51eef6463d3d4343c16469844f65f9cd5`.
Historical wording; this is not a current model definition.
```text
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
```
### principal
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 26–26; SHA-256 `3ab8b5d536f3e1da3f172f95431751a51786291480592b7e2e784338466657ba`.
Historical wording; this is not a current model definition.
```text
| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. |
```
### pan / cvv / chd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
Historical wording; this is not a current model definition.
```text
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
```
### representation
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 102–102; SHA-256 `1a93d64d4e3f608806754d3889b9655d0083e2f5ce92db14780c8513fbfff419`.
Historical wording; this is not a current model definition.
```text
| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. |
```
### pairwise subject
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 115–115; SHA-256 `508a529137ad7a0e7f1409063b306cad3bb1f8aa1c9c15f179c21ab657f46d33`.
Historical wording; this is not a current model definition.
```text
| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. |
```
### relationship tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 116–116; SHA-256 `3cab1bbb2dfc5afd3dcde230e104ddd95e67ccddc46fb2bbcc38f99103a55f49`.
Historical wording; this is not a current model definition.
```text
| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. |
```
### policy
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
Historical wording; this is not a current model definition.
```text
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
```
### holder
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 128–128; SHA-256 `1e57bb144bb8a072a4180be14a8a91f8126c4f958397a8fd62e12c63db8806b6`.
Historical wording; this is not a current model definition.
```text
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
```
### data subject
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 132–132; SHA-256 `2aae43d6df259e4678d0a2d27fcf4efd546ecd99201d1a3e573cef845e78a822`.
Historical wording; this is not a current model definition.
```text
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
```
### tuple (authz)
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 135–135; SHA-256 `89a5e53a0468189c92022352aac36ccf34b62a8a34b49c13241eb5fa91aa830c`.
Historical wording; this is not a current model definition.
```text
| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. |
```
### userset
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 136–136; SHA-256 `6ad9832f81b69b4e039e5bb2c0e8751894d408412f573668619adfa74cde2e8c`.
Historical wording; this is not a current model definition.
```text
| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. |
```
### contextual tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
Historical wording; this is not a current model definition.
```text
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
```

156
infospace/assimilation/canon-federation/views/itc-evid.md Normal file
View file

@ -0,0 +1,156 @@
# itc-evid provenance reading index
Historical input only. Current canon and ADR-006 override superseded assertions.
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
- [research/authentication-federation/nist-800-63-4.md](../source/research/authentication-federation/nist-800-63-4.md) — 8697b739399c.
- [research/authentication-federation/oidc-core-subject-identifiers.md](../source/research/authentication-federation/oidc-core-subject-identifiers.md) — e1a0bf8a2754.
- [research/authentication-federation/saml-nameid-federation.md](../source/research/authentication-federation/saml-nameid-federation.md) — 394457cf75d2.
- [research/authentication-federation/shared-signals-caep-risc.md](../source/research/authentication-federation/shared-signals-caep-risc.md) — 7303fd449a83.
- [research/commercial-identity/beneficial-ownership-kyc-boi.md](../source/research/commercial-identity/beneficial-ownership-kyc-boi.md) — 602aad062291.
- [research/commercial-identity/commercial-identity-nuance-settlement.md](../source/research/commercial-identity/commercial-identity-nuance-settlement.md) — cabb54601ee7.
- [research/commercial-identity/commercial-identity-synthesis.md](../source/research/commercial-identity/commercial-identity-synthesis.md) — ac70ecdb2046.
- [research/commercial-identity/commercial-trust-binding-theory.md](../source/research/commercial-identity/commercial-trust-binding-theory.md) — fc7be6f0641b.
- [research/commercial-identity/crm-pipeline-commitment-threshold.md](../source/research/commercial-identity/crm-pipeline-commitment-threshold.md) — 459828097e09.
- [research/commercial-identity/duns-commercial-credit-identity.md](../source/research/commercial-identity/duns-commercial-credit-identity.md) — b33b789b047f.
- [research/commercial-identity/eidas-eudi-legal-person-wallet.md](../source/research/commercial-identity/eidas-eudi-legal-person-wallet.md) — be8b05990cd0.
- [research/commercial-identity/kyc-aml-commercial-identity-binding.md](../source/research/commercial-identity/kyc-aml-commercial-identity-binding.md) — 5d3f63465cd7.
- [research/commercial-identity/legal-person-agency-contract.md](../source/research/commercial-identity/legal-person-agency-contract.md) — c3110cc62b49.
- [research/commercial-identity/lei-gleif-legal-entity-identifier.md](../source/research/commercial-identity/lei-gleif-legal-entity-identifier.md) — ef2ba7156f6d.
- [research/commercial-identity/payment-credential-pci-boundary.md](../source/research/commercial-identity/payment-credential-pci-boundary.md) — bcacaee7090c.
- [research/commercial-identity/registry-identifier-subtypes.md](../source/research/commercial-identity/registry-identifier-subtypes.md) — 1a621787a869.
- [research/commercial-identity/reputation-assurance-gradient.md](../source/research/commercial-identity/reputation-assurance-gradient.md) — 0c992d05657d.
- [research/commercial-identity/salesforce-crm-commercial-record.md](../source/research/commercial-identity/salesforce-crm-commercial-record.md) — 52bf8c8dbbd7.
- [research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md](../source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md) — 12585f844728.
- [research/entity-resolution-privacy/gdpr-pseudonymization.md](../source/research/entity-resolution-privacy/gdpr-pseudonymization.md) — de2bfcf7f52b.
- [research/entity-resolution-privacy/synonymity-assertions.md](../source/research/entity-resolution-privacy/synonymity-assertions.md) — 6ba40ec37221.
- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf.
- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25.
- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3.
- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f.
- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3.
- [research/verifiable-claims/did-core.md](../source/research/verifiable-claims/did-core.md) — cbe5fd46e093.
- [research/verifiable-claims/openid4vc.md](../source/research/verifiable-claims/openid4vc.md) — e6fcc0612146.
- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c.
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
## Shared terminology and scenario fragments
### S12. Weak Identity Match From Imported Data
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 140–150; SHA-256 `b5f26ea04922d59bfe1c7dd240a2348e4afc6cc45a257ea5dfbb733e614649d5`.
Historical wording; this is not a current model definition.
```text
## S12. Weak Identity Match From Imported Data
Expected representation: source Identity Records linked by a weak Synonymity
Assertion with method, evidence, confidence, scope, and lifecycle state.
Checks:
- Weak match does not merge accounts.
- Consumers can reject or quarantine weak links.
- Evidence source remains visible.
```
### Conflict: Synonymity, Linking, Matching, Merge
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
Historical wording; this is not a current model definition.
```text
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
```
### pan / cvv / chd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
Historical wording; this is not a current model definition.
```text
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
```
### star rating / review
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 63–63; SHA-256 `3dbb10a8ab536c181da9205e3cfb4fae3031e0fd007fb4bb6205bb532e1959f1`.
Historical wording; this is not a current model definition.
```text
| star rating / review | Reputation Signal | Yelp, Amazon, App Store | Opinion-tier Evidence Source; weak, gamable. |
```
### arbitration award
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 68–68; SHA-256 `5631838512e0e0b5452b591adc1f4f77f380df18cecf4e6164dab0546207ef67`.
Historical wording; this is not a current model definition.
```text
| arbitration award | Adjudication Outcome | AAA, ICC, JAMS | Adjudicated-tier dispute result. |
```
### court judgment
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 69–69; SHA-256 `ba21ec0155b991faea17beea69f8fbcaa4489f51e522ced3b2ded31fe06f4c3e`.
Historical wording; this is not a current model definition.
```text
| court judgment | Adjudication Outcome | courts | Adjudicated-tier enforcement outcome. |
```
### kyc / cip
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 78–78; SHA-256 `489f788d80be6f2e796a116a2338e697145669829f355c121e18975dbbfbf13f`.
Historical wording; this is not a current model definition.
```text
| kyc / cip | Evidence Source + Assurance | FinCEN, FATF | Regulated commercial identity onboarding. |
```
### evidence
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 105–105; SHA-256 `f6a2c13eb05ca9f7299d1e704815b2dbf0a2d0c8ca75a032bc4aaca087b28b86`.
Historical wording; this is not a current model definition.
```text
| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. |
```
### policy
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
Historical wording; this is not a current model definition.
```text
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
```
### contextual tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
Historical wording; this is not a current model definition.
```text
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
```

77
infospace/assimilation/canon-federation/views/itc-gov.md Normal file
View file

@ -0,0 +1,77 @@
# itc-gov provenance reading index
Historical input only. Current canon and ADR-006 override superseded assertions.
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
- [research/commercial-identity/beneficial-ownership-kyc-boi.md](../source/research/commercial-identity/beneficial-ownership-kyc-boi.md) — 602aad062291.
- [research/commercial-identity/commercial-identity-nuance-settlement.md](../source/research/commercial-identity/commercial-identity-nuance-settlement.md) — cabb54601ee7.
- [research/commercial-identity/commercial-identity-synthesis.md](../source/research/commercial-identity/commercial-identity-synthesis.md) — ac70ecdb2046.
- [research/commercial-identity/commercial-trust-binding-theory.md](../source/research/commercial-identity/commercial-trust-binding-theory.md) — fc7be6f0641b.
- [research/commercial-identity/crm-pipeline-commitment-threshold.md](../source/research/commercial-identity/crm-pipeline-commitment-threshold.md) — 459828097e09.
- [research/commercial-identity/duns-commercial-credit-identity.md](../source/research/commercial-identity/duns-commercial-credit-identity.md) — b33b789b047f.
- [research/commercial-identity/eidas-eudi-legal-person-wallet.md](../source/research/commercial-identity/eidas-eudi-legal-person-wallet.md) — be8b05990cd0.
- [research/commercial-identity/kyc-aml-commercial-identity-binding.md](../source/research/commercial-identity/kyc-aml-commercial-identity-binding.md) — 5d3f63465cd7.
- [research/commercial-identity/legal-person-agency-contract.md](../source/research/commercial-identity/legal-person-agency-contract.md) — c3110cc62b49.
- [research/commercial-identity/lei-gleif-legal-entity-identifier.md](../source/research/commercial-identity/lei-gleif-legal-entity-identifier.md) — ef2ba7156f6d.
- [research/commercial-identity/payment-credential-pci-boundary.md](../source/research/commercial-identity/payment-credential-pci-boundary.md) — bcacaee7090c.
- [research/commercial-identity/registry-identifier-subtypes.md](../source/research/commercial-identity/registry-identifier-subtypes.md) — 1a621787a869.
- [research/commercial-identity/reputation-assurance-gradient.md](../source/research/commercial-identity/reputation-assurance-gradient.md) — 0c992d05657d.
- [research/commercial-identity/salesforce-crm-commercial-record.md](../source/research/commercial-identity/salesforce-crm-commercial-record.md) — 52bf8c8dbbd7.
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
## Shared terminology and scenario fragments
### Conflict: Synonymity, Linking, Matching, Merge
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
Historical wording; this is not a current model definition.
```text
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
```
### pan / cvv / chd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
Historical wording; this is not a current model definition.
```text
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
```
### policy
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
Historical wording; this is not a current model definition.
```text
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
```
### contextual tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
Historical wording; this is not a current model definition.
```text
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
```

1439
infospace/assimilation/canon-federation/views/itc-ident.md Normal file
View file

File diff suppressed because it is too large Load diff

905
infospace/assimilation/canon-federation/views/itc-org.md Normal file
View file

@ -0,0 +1,905 @@
# itc-org provenance reading index
Historical input only. Current canon and ADR-006 override superseded assertions.
- [research/CorpusIndex.md](../source/research/CorpusIndex.md) — d110cd1f6653.
- [research/README.md](../source/research/README.md) — 1ab93b1176ac.
- [research/ResearchSeed.md](../source/research/ResearchSeed.md) — 1e432ff04d17.
- [research/authorization-relationships/cedar-principal-action-resource-context.md](../source/research/authorization-relationships/cedar-principal-action-resource-context.md) — 1932a8632dd3.
- [research/authorization-relationships/cerbos-abac-derived-roles.md](../source/research/authorization-relationships/cerbos-abac-derived-roles.md) — c35f15042d45.
- [research/authorization-relationships/openfga-modeling.md](../source/research/authorization-relationships/openfga-modeling.md) — e2d03ddfa7be.
- [research/authorization-relationships/zanzibar-rebac.md](../source/research/authorization-relationships/zanzibar-rebac.md) — 1f736195ab4b.
- [research/commercial-identity/beneficial-ownership-kyc-boi.md](../source/research/commercial-identity/beneficial-ownership-kyc-boi.md) — 602aad062291.
- [research/commercial-identity/commercial-identity-nuance-settlement.md](../source/research/commercial-identity/commercial-identity-nuance-settlement.md) — cabb54601ee7.
- [research/commercial-identity/commercial-identity-synthesis.md](../source/research/commercial-identity/commercial-identity-synthesis.md) — ac70ecdb2046.
- [research/commercial-identity/commercial-trust-binding-theory.md](../source/research/commercial-identity/commercial-trust-binding-theory.md) — fc7be6f0641b.
- [research/commercial-identity/crm-pipeline-commitment-threshold.md](../source/research/commercial-identity/crm-pipeline-commitment-threshold.md) — 459828097e09.
- [research/commercial-identity/duns-commercial-credit-identity.md](../source/research/commercial-identity/duns-commercial-credit-identity.md) — b33b789b047f.
- [research/commercial-identity/eidas-eudi-legal-person-wallet.md](../source/research/commercial-identity/eidas-eudi-legal-person-wallet.md) — be8b05990cd0.
- [research/commercial-identity/kyc-aml-commercial-identity-binding.md](../source/research/commercial-identity/kyc-aml-commercial-identity-binding.md) — 5d3f63465cd7.
- [research/commercial-identity/legal-person-agency-contract.md](../source/research/commercial-identity/legal-person-agency-contract.md) — c3110cc62b49.
- [research/commercial-identity/lei-gleif-legal-entity-identifier.md](../source/research/commercial-identity/lei-gleif-legal-entity-identifier.md) — ef2ba7156f6d.
- [research/commercial-identity/payment-credential-pci-boundary.md](../source/research/commercial-identity/payment-credential-pci-boundary.md) — bcacaee7090c.
- [research/commercial-identity/registry-identifier-subtypes.md](../source/research/commercial-identity/registry-identifier-subtypes.md) — 1a621787a869.
- [research/commercial-identity/reputation-assurance-gradient.md](../source/research/commercial-identity/reputation-assurance-gradient.md) — 0c992d05657d.
- [research/commercial-identity/salesforce-crm-commercial-record.md](../source/research/commercial-identity/salesforce-crm-commercial-record.md) — 52bf8c8dbbd7.
- [research/commercial-subscription/b2b-saas-subscriber-tenancy.md](../source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md) — 133bf4325a7c.
- [research/commercial-subscription/stripe-customer-billing.md](../source/research/commercial-subscription/stripe-customer-billing.md) — bb5c8fe3cab7.
- [research/identity-provisioning/keycloak-organizations.md](../source/research/identity-provisioning/keycloak-organizations.md) — 09c43cdc9ecf.
- [research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md](../source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md) — c3f3323a3f25.
- [research/identity-provisioning/ory-kratos-keto.md](../source/research/identity-provisioning/ory-kratos-keto.md) — 5cd12c38f8d3.
- [research/identity-provisioning/scim-rfc7643-rfc7644.md](../source/research/identity-provisioning/scim-rfc7643-rfc7644.md) — c5c03952ac2f.
- [research/identity-provisioning/zitadel-organizations-projects.md](../source/research/identity-provisioning/zitadel-organizations-projects.md) — f4b1b6f4cce3.
- [research/social-community-graphs/activitypub-actors-followers.md](../source/research/social-community-graphs/activitypub-actors-followers.md) — 8b28bfc385d1.
- [research/social-community-graphs/foaf-agent-person-group-onlineaccount.md](../source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md) — 4131e7685da5.
- [research/social-community-graphs/schema-org-person-organization-membership.md](../source/research/social-community-graphs/schema-org-person-organization-membership.md) — bc274f7cf1ff.
- [research/social-community-graphs/webid-solid-profile.md](../source/research/social-community-graphs/webid-solid-profile.md) — abf0c62e23b0.
- [research/verifiable-claims/did-core.md](../source/research/verifiable-claims/did-core.md) — cbe5fd46e093.
- [research/verifiable-claims/openid4vc.md](../source/research/verifiable-claims/openid4vc.md) — e6fcc0612146.
- [research/verifiable-claims/vc-data-model-2.md](../source/research/verifiable-claims/vc-data-model-2.md) — dae7bc679c6c.
- [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) — 400641667064.
- [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) — 06c8134a399a.
- [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) — 5d22816b0bfe.
## Shared terminology and scenario fragments
### S01. Single Person With One Local Account
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 13–24; SHA-256 `0040dd866009ad1199e89f89267e3aab86894859f6ae6d07f393e4f0b8cdb6f5`.
Historical wording; this is not a current model definition.
```text
## S01. Single Person With One Local Account
Expected representation: one Natural Person, one Account in an application
Scope, one local Identifier, one Profile, and one Membership or access
relationship if the account belongs to a group.
Checks:
- The person is not identical to the account.
- The profile is not the credential.
- Authorization can project the account or subject into a Principal.
```
### S02. Person With Multiple Accounts Across Scopes
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 25–35; SHA-256 `69cabdc1680936fffd25378d9a1fcaa129c258eeca03663a3c9e9718def6fd59`.
Historical wording; this is not a current model definition.
```text
## S02. Person With Multiple Accounts Across Scopes
Expected representation: one Natural Person, multiple Accounts, one Account
per Scope, and optional Synonymity Assertions linking account records.
Checks:
- Each account keeps its source and lifecycle state.
- Linking accounts does not merge them destructively.
- Different scopes can use different identifiers.
```
### S03. Enterprise With Sub-Organizations
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 36–47; SHA-256 `76282210f7df6bf26635ede205ed08215908eb82f8c84d411178bc01516a3f4d`.
Historical wording; this is not a current model definition.
```text
## S03. Enterprise With Sub-Organizations
Expected representation: Organization actors linked by structural
relationships, plus Accounts and Membership relationships scoped to relevant
systems.
Checks:
- Sub-organization is not automatically a tenant.
- Legal entity status is modeled separately.
- Membership and administration relationships are explicit.
```
### S04. Vendor Tenant Serving Customer Tenants
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 48–59; SHA-256 `f674aa6466c45664d941359e2016a5f43a9ef58f58f1299f1ecb39003ef9a0c3`.
Historical wording; this is not a current model definition.
```text
## S04. Vendor Tenant Serving Customer Tenants
Expected representation: Vendor and Customer relationship roles between
Organization actors; Tenant scopes for platform isolation; optional
Administration relationships for delegated support.
Checks:
- Customer is not collapsed into Tenant.
- Vendor is not collapsed into Realm.
- Cross-tenant administration is scoped and evidenced.
```
### S05. Customer Organization With Delegated Administrators
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 60–70; SHA-256 `40271bc925011808c60854faf342853ed48ff737afc7885921b62696b02c69d3`.
Historical wording; this is not a current model definition.
```text
## S05. Customer Organization With Delegated Administrators
Expected representation: Organization actor, Tenant scope, administrator
Accounts, Delegation and Administration relationships.
Checks:
- Admin rights are relationships, not just group names.
- Delegation has source, target, scope, and lifecycle state.
- Authorization projection can consume the relationship separately.
```
### S06. Family With Guardian And Dependent Accounts
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 71–82; SHA-256 `a3f0705f7168974632f544891e08403fdcdaa2b205f40ae899bc0483af445106`.
Historical wording; this is not a current model definition.
```text
## S06. Family With Guardian And Dependent Accounts
Expected representation: Family or Household collective actor, Natural Person
actors, guardian/dependent relationships, child Accounts, and privacy
constraints.
Checks:
- Guardian relationship is not generic membership.
- Household and legal family can differ.
- Privacy-sensitive links can be scoped.
```
### S07. Spontaneous Interest Group
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 83–93; SHA-256 `b4d3ed3df96d57dfc9defcb0395c134e500c79375972ccb978c2abfb64da7247`.
Historical wording; this is not a current model definition.
```text
## S07. Spontaneous Interest Group
Expected representation: Community or Group collective actor, Membership
relationships, optional moderator Administration relationships.
Checks:
- Informal group does not need legal entity or tenant semantics.
- Moderation is not the same as membership.
- Group identity can exist without strong real-world identity proofing.
```
### S08. Community With Members, Moderators, And Followers
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 94–105; SHA-256 `83de4820c3662f015970f7360ceb1278bca3fa8bf63037826316d63643e580ae`.
Historical wording; this is not a current model definition.
```text
## S08. Community With Members, Moderators, And Followers
Expected representation: Community actor; Membership relationships for
members; Administration or moderation relationships for moderators; Following
relationships for followers.
Checks:
- Follower is not a member unless the source says so.
- Moderator authority is explicit and scoped.
- Public profile can differ from account.
```
### S09. Social Media Follower Graph
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 106–116; SHA-256 `fd342efc3924c194784c48d937333426addcac7e8404a1834881e284937777b3`.
Historical wording; this is not a current model definition.
```text
## S09. Social Media Follower Graph
Expected representation: Actor or Persona profiles connected by Following
relationships in a social Scope.
Checks:
- Following is directed.
- Following does not imply affiliation, membership, trust, or authorization.
- Pseudonymous profiles can remain scoped.
```
### S10. Bot Or Service Account Acting For An Organization
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 117–127; SHA-256 `b7671fae9cd9c0c2070588558e72fc34e6a40a449b088738761253df23955228`.
Historical wording; this is not a current model definition.
```text
## S10. Bot Or Service Account Acting For An Organization
Expected representation: Artificial Agent actor, Service Account, Organization
actor, Representation or Delegation relationship, and Credential records.
Checks:
- Bot is not a natural person.
- Service account has an owner or responsible actor.
- Delegated authority has bounded scope and lifecycle.
```
### S11. AI Agent Acting Under Delegated Authority
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 128–139; SHA-256 `c26e3ad239e21e320a65dcee09b95260db582d26ff08c3b7cf537577c9501275`.
Historical wording; this is not a current model definition.
```text
## S11. AI Agent Acting Under Delegated Authority
Expected representation: Artificial Agent actor, Account or Service Account,
Delegation relationship from a Natural Person or Organization, and audit or
evidence references for actions.
Checks:
- Delegation identifies who granted authority.
- Agent actions can be attributed without treating the agent as the person.
- Authorization projection can include delegated context.
```
### S15. Organization Represented By A Legal Entity And Operational Tenants
Frozen source: [scenarios/ScenarioTests.md](../source/scenarios/ScenarioTests.md) lines 173–184; SHA-256 `a809f4bae8f243f9034887ad2c16903449999ae695c2fc1c4fc089cf9b7020a0`.
Historical wording; this is not a current model definition.
```text
## S15. Organization Represented By A Legal Entity And Operational Tenants
Expected representation: Organization actor, Legal Entity specialization or
relationship, one or more Tenant scopes, and Representation relationships for
authorized persons or agents.
Checks:
- Legal entity and tenant are separate model elements.
- Multiple tenants can relate to one organization.
- Representation authority is scoped and evidenced.
```
### Conflict: User
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 6–28; SHA-256 `03cc685a840d47b36bf124aa8c1465216dfcb1c463f911dbe5e934b7fa81e3b6`.
Historical wording; this is not a current model definition.
```text
## Conflict: User
Problem: `user` can mean a person, account, login credential holder,
application profile, authorization subject, or product-facing actor.
Source evidence:
- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
`zitadel-organizations-projects.md`)
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)
Canonical stance: do not use `user` as a root concept.
Current mapping rule:
- Provisioning record (SCIM/LDAP) → Identity Record
- Login-enabled product record → Account
- Public/local display → Profile
- Access evaluation → Principal or Authenticated Subject
- Human being → Natural Person
```
### Conflict: Account
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 44–59; SHA-256 `5bc5a473a54d20d4cbba778d5f4508e0655cb755d118583715873b2ca81533a2`.
Historical wording; this is not a current model definition.
```text
## Conflict: Account
Problem: account can mean login account, customer billing account, social
media handle, service account, or FOAF online presence.
Source evidence:
- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)
Canonical stance: Account is operational access record in a scope. Billing
records map to Commercial Record; commercial parties use Customer/Vendor roles
and Commercial Relationship.
```
### Conflict: Subject, Principal, Actor
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 60–79; SHA-256 `5f7282450703c7ab38c6d6b044bf99731c274974dd8ece1785de74bdc1365feb`.
Historical wording; this is not a current model definition.
```text
## Conflict: Subject, Principal, Actor
Problem: protocols, authorization engines, and social models overload these terms.
Source evidence:
- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)
Canonical stance:
- Actor = conceptual participant
- Authenticated Subject = issuer/protocol view
- Authorization Principal = decision-engine projection
```
### Conflict: Tenant, Realm, Organization, Customer
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 80–99; SHA-256 `3e920b787354989a9cce48cc7b45c915150b215b4fcdfe054b854d9cc9748191`.
Historical wording; this is not a current model definition.
```text
## Conflict: Tenant, Realm, Organization, Customer
Problem: multi-tenant products collapse isolation boundaries and commercial actors.
Source evidence:
- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)
Canonical stance:
- Tenant = administrative/isolation scope
- Realm = issuer/admin namespace (Scope specialization)
- Organization = collective actor
- Customer = commercial relationship role
Model relationships among them; do not synonymize.
```
### Conflict: Group, Role, Team, Community
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 100–119; SHA-256 `0a8cd0ebc16563b59014cbaf3e026ae6633f24aa8f26dabe1c2bfebf70b4f3d4`.
Historical wording; this is not a current model definition.
```text
## Conflict: Group, Role, Team, Community
Problem: IAM groups, collaboration teams, social communities, and authz member
relations use overlapping labels.
Source evidence:
- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes)
- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`)
- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`)
- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`)
- Schema.org Organization subtypes include SportsTeam (`schema-org` note)
Canonical stance:
- Group = named collection with membership
- Role = capability bundle or relationship label
- Team = collaboration group or org unit
- Community = participation-oriented collective actor
```
### Conflict: Member, Follower, Affiliate
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 120–133; SHA-256 `59c522c4fa0602246033c3d4bf91b91d718119bc116ad60df9f9c7fda616cefc`.
Historical wording; this is not a current model definition.
```text
## Conflict: Member, Follower, Affiliate
Problem: membership, following, affiliation, and authz member relations hide
distinct semantics behind `member`.
Source evidence:
- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`)
- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`)
- OpenFGA organization#member = authz projection (`openfga-modeling.md`)
- FOAF member = group membership; knows = acquaintance (`foaf` note)
Canonical stance: use typed relationships with scope and evidence.
```
### Conflict: Profile And Persona
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 134–149; SHA-256 `7e0380ec397e1c991a40391d366913e7087b4a3f45d416b92c068e34a71450b8`.
Historical wording; this is not a current model definition.
```text
## Conflict: Profile And Persona
Problem: profiles are account records, RDF documents, public pages, or VC subjects.
Source evidence:
- WebID profile document = RDF at URI (`webid-solid-profile.md`)
- Kratos traits often called profile informally (`ory-kratos-keto.md`)
- ActivityPub actor profile = public actor representation
- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes)
Canonical stance:
- Profile = presentation surface in scope
- Persona = deliberate contextual presentation with privacy boundaries
```
### Conflict: Synonymity, Linking, Matching, Merge
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 163–177; SHA-256 `a714d30d2c1bedfcfe3020fa277c5a6226ec408eebd65efc33aadcba9b825ddf`.
Historical wording; this is not a current model definition.
```text
## Conflict: Synonymity, Linking, Matching, Merge
Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.
Source evidence:
- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)
Canonical stance: synonymity is scoped, evidenced, revocable assertion.
```
### Conflict: Issuer
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 191–203; SHA-256 `e7ca901947a8931fb1c427fa217f22bac361c15aa6c57da67580d799676980a7`.
Historical wording; this is not a current model definition.
```text
## Conflict: Issuer
Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.
Source evidence:
- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
- VC issuer signs credential (`vc-data-model-2.md`)
- NIST CSP performs proofing (`nist-800-63-4.md`)
Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
role when mapping.
```
### Conflict: Customer Account
Frozen source: [terminology/TerminologyConflictMap.md](../source/terminology/TerminologyConflictMap.md) lines 204–222; SHA-256 `f88abdae039caa5135f7acfb7545747a141fe84703b23f45c918c209d1b73654`.
Historical wording; this is not a current model definition.
```text
## Conflict: Customer Account
Problem: `customer account` collapses login account, B2B subscriber organization,
Stripe billing customer, and CRM account into one product noun.
Source evidence:
- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)
Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:
- login/access → Account;
- subscribing company → Organization + Customer role + Tenant;
- billing/CRM → Commercial Record;
- vendor↔customer link → Commercial Relationship.
```
### actor
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 17–17; SHA-256 `6ceb7d60a09ca5471237860930d88dd8367e7bbda1cd4605eee58d89f9a5bd72`.
Historical wording; this is not a current model definition.
```text
| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. |
```
### natural person
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 18–18; SHA-256 `973e4a0177d5241ce7090eb6e36e29cb8036bd3b23c3c4b793bfdc476ccbbb39`.
Historical wording; this is not a current model definition.
```text
| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. |
```
### account
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 20–20; SHA-256 `1901d71fbc43e06b5134161854710bf0f653141bc626bf67d95d4cfd3db0e10f`.
Historical wording; this is not a current model definition.
```text
| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. |
```
### subject
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 25–25; SHA-256 `904b2af8c84d271ad315098c387b00d51eef6463d3d4343c16469844f65f9cd5`.
Historical wording; this is not a current model definition.
```text
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
```
### end-user
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 27–27; SHA-256 `74c3cc32b9d4ce44cf2b61a4673ea73073be69d31900f302937110ab74c43c4c`.
Historical wording; this is not a current model definition.
```text
| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. |
```
### agent
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 30–30; SHA-256 `30a826d21d04b01e4de5648711bdd38e1e106bbb25d2ab2f1f611912d0f7b3b1`.
Historical wording; this is not a current model definition.
```text
| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. |
```
### bot
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 31–31; SHA-256 `827962be82a98f1c17ffb62c4f4cd943a66a753d67e5cca0fc8ef77756e8ffad`.
Historical wording; this is not a current model definition.
```text
| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. |
```
### organization
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 34–34; SHA-256 `b3deaa2097bfa8f94206f0d599bf434e202e1a3a72ff5ff0ac556ab9ad00efe3`.
Historical wording; this is not a current model definition.
```text
| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. |
```
### legal entity
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 35–35; SHA-256 `da327d376e38707f55e5a1fbcdd4dee8f76bfc6cb4ec2e8468a90079f2ca1a5a`.
Historical wording; this is not a current model definition.
```text
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
```
### customer
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 36–36; SHA-256 `3e7b01c8abe4d58617b4902063eb4f5f14e7cac5da49a8ff778c33f9bc4716a9`.
Historical wording; this is not a current model definition.
```text
| customer | Customer (relationship role) | SaaS, vendor models | B2B subscriber org → Organization + Customer role + Tenant. Not Stripe Customer. |
```
### vendor
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 37–37; SHA-256 `68a088043e8cb63172b4c57325022708379566e12a9cf605400179c16a4f46b7`.
Historical wording; this is not a current model definition.
```text
| vendor | Vendor (relationship role) | SaaS, multi-vendor | Provider role; not realm or tenant. |
```
### subscriber
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 38–38; SHA-256 `3194121265ab0f7be752878e2168006b71c72b9f200f1e5e02aac4f078de5bf4`.
Historical wording; this is not a current model definition.
```text
| subscriber | Organization + Customer role | Auth0 B2B SaaS | Convenience label only; not canonical. |
```
### pan / cvv / chd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 42–42; SHA-256 `84eacf96d9ff1a172086a00c1ecf31e94f5b594ee4dce3559e8ccd2525ab6b9c`.
Historical wording; this is not a current model definition.
```text
| pan / cvv / chd | Out of canon | PCI DSS | Downstream PCI vault only. |
```
### beneficial owner
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 52–52; SHA-256 `5c1d61373f92b79b054fe3d605a5d8171b2af91ebc9b3636f7b07015b3ce85f0`.
Historical wording; this is not a current model definition.
```text
| beneficial owner | Beneficial Owner + Beneficial Ownership Relationship | KYC/AML, FinCEN CDD, FATF R24 | Natural person behind legal entity customer; dedicated relationship type with ownership/control prongs. |
```
### beneficial ownership
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 53–53; SHA-256 `8520301fabb9a30b9055f47f6b8b957636038fe4f6ec4a34761cfd233780d40a`.
Historical wording; this is not a current model definition.
```text
| beneficial ownership | Beneficial Ownership Relationship | FinCEN CDD, BOI, Open Ownership | Regulated Natural Person → Organization/Legal Entity linkage; not Ownership subtype. |
```
### iso 6523 / icd
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 59–59; SHA-256 `03da1b9755c903ab6c7d865a98c27223f9d7477629602c635394956f3404dc31`.
Historical wording; this is not a current model definition.
```text
| iso 6523 / icd | Registry Identifier scheme | ISO/IEC 6523, PEPPOL | ICD + organization identifier encoding. |
```
### legal person
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 60–60; SHA-256 `5138cf572034760b21f365bcae5e73346acf6d88c2f65cee751d6b02454d9766`.
Historical wording; this is not a current model definition.
```text
| legal person | Legal Person | eIDAS, civil law, agency | Natural or juridical person under law. |
```
### control_basis
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 71–71; SHA-256 `7923f00e6a10cdd05fd7b3bc8a5013fc837a36bd1f984fb84fc8f4447e147a7c`.
Historical wording; this is not a current model definition.
```text
| control_basis | Beneficial Ownership Relationship metadata | FinCEN CDD, EU AMLD | Settled role enum (chief_executive, managing_member, …). |
```
### fincen id
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 73–73; SHA-256 `f0bfb45e5363934041ff910a44cd0d69b578679f9c22719365fb0319b314fb78`.
Historical wording; this is not a current model definition.
```text
| fincen id | Registry Identifier (government_registry) | BOI | Natural person government registry ID. |
```
### person account
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 74–74; SHA-256 `b75fc9b5ca6ef2146e019e342f8565d138eeefccc4b2ee845f010c835d5567eb`.
Historical wording; this is not a current model definition.
```text
| person account | Natural Person + Commercial Record | Salesforce B2C | Adapter projection_mode person_account_combined only. |
```
### crm account
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 79–79; SHA-256 `9b1dcdfbe61b780895d51b439da2dffc0df0df7cc4dfb4d57de7dd3f8eb30d0e`.
Historical wording; this is not a current model definition.
```text
| crm account | Commercial Record | Salesforce | Company/household commercial record. |
```
### community
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 88–88; SHA-256 `0511a75af9b3a29cc2519527193f01cf70d04c0b0e04546127b14a7bd2ec5c8a`.
Historical wording; this is not a current model definition.
```text
| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. |
```
### family
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 89–89; SHA-256 `b1494107b59c6ed89546a86eeb073414ee575a2376f3c695ecb23b5c2668e32d`.
Historical wording; this is not a current model definition.
```text
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
```
### household
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 90–90; SHA-256 `0719bdf791feaaf5a70b1990b2ea38f730312c1addbbdd6562ddb0b7abbb75ed`.
Historical wording; this is not a current model definition.
```text
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
```
### group
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 91–91; SHA-256 `46830fccca86caeda6623d000dc25708edfbc3fbce2be1d4746a7b4d3482dd43`.
Historical wording; this is not a current model definition.
```text
| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. |
```
### team
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 92–92; SHA-256 `ad2667febbf25827e07ad34d4f413f4165078eda36f90fccd92361b88bc56737`.
Historical wording; this is not a current model definition.
```text
| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. |
```
### role
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 93–93; SHA-256 `bf4b3c078725e3a9b4c661c358df673204d21865de9386223c00682de7a76d2a`.
Historical wording; this is not a current model definition.
```text
| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. |
```
### grant
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 94–94; SHA-256 `ca2c9b2882bd176716d5f40b570f7d142e820881529353bdd9829ca2fff5acfd`.
Historical wording; this is not a current model definition.
```text
| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. |
```
### member
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 95–95; SHA-256 `a6600f7dd9604883a0c366467ad89a90ceee68aefbe6aca09067ada754baae23`.
Historical wording; this is not a current model definition.
```text
| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. |
```
### affiliation
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 96–96; SHA-256 `06170379083ad57eb7ec1dee172d3f2e370140f32c1e8b3ccf5a700c3fffdb66`.
Historical wording; this is not a current model definition.
```text
| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. |
```
### follower
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 97–97; SHA-256 `62256899610e66f10a97b6f7011d52ff02ce79f6d4060c0d403bc8a520f3e6ff`.
Historical wording; this is not a current model definition.
```text
| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. |
```
### policy
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 117–117; SHA-256 `13bcf330fb1989abf5ba4d7c673d2c3a646480236f81792abadb74afa660b983`.
Historical wording; this is not a current model definition.
```text
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
```
### subscriber
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 119–119; SHA-256 `778a574609c40787ae9fec045e791faafd3d39b49fd187b3c10bc6dad0133e4c`.
Historical wording; this is not a current model definition.
```text
| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. |
```
### holder
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 128–128; SHA-256 `1e57bb144bb8a072a4180be14a8a91f8126c4f958397a8fd62e12c63db8806b6`.
Historical wording; this is not a current model definition.
```text
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
```
### verifier
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 129–129; SHA-256 `d37d10d4b1113114369aa128754a243e56f9ee71e5f95d5d9f966d75fe94088b`.
Historical wording; this is not a current model definition.
```text
| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. |
```
### webid
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 131–131; SHA-256 `e08c6ed7932919efd4c8f8ae55161be7a02e983d667cf3359fcff0affde44a1b`.
Historical wording; this is not a current model definition.
```text
| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. |
```
### data subject
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 132–132; SHA-256 `2aae43d6df259e4678d0a2d27fcf4efd546ecd99201d1a3e573cef845e78a822`.
Historical wording; this is not a current model definition.
```text
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
```
### controller
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 134–134; SHA-256 `161324c016daae2806cd837b82beceffd4ea2b3ce981683b5ed39f58132b19e8`.
Historical wording; this is not a current model definition.
```text
| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. |
```
### derived role
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 137–137; SHA-256 `cbfaa9a627d2d32e194e4301e908fd193eb67c788ac3afad98079ce92e898fce`.
Historical wording; this is not a current model definition.
```text
| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. |
```
### contextual tuple
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 138–138; SHA-256 `5b1c5f8c2795fc54d61f319bd4c6238538588fa4026e779d0ed615e998133218`.
Historical wording; this is not a current model definition.
```text
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
```
### organizationrole
Frozen source: [terminology/TerminologyInventory.md](../source/terminology/TerminologyInventory.md) lines 140–140; SHA-256 `ca2eda7a31f21b54ff220456146ef06584ab01844034832e519a9c9c0febf576`.
Historical wording; this is not a current model definition.
```text
| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. |
```

185
infospace/indexes/artifact-tree.yaml
View file

@ -1,5 +1,5 @@
root: infospace
file_count: 215
file_count: 276
files:
- path: README.md
directory: .
@ -235,6 +235,189 @@ files:
- path: assimilation/README.md
directory: assimilation
name: README.md
- path: assimilation/canon-federation/ASSIMILATION.md
directory: assimilation/canon-federation
name: ASSIMILATION.md
- path: assimilation/canon-federation/README.md
directory: assimilation/canon-federation
name: README.md
- path: assimilation/canon-federation/assimilation.yaml
directory: assimilation/canon-federation
name: assimilation.yaml
- path: assimilation/canon-federation/comparison-matrix.md
directory: assimilation/canon-federation
name: comparison-matrix.md
- path: assimilation/canon-federation/distribution.json
directory: assimilation/canon-federation
name: distribution.json
- path: assimilation/canon-federation/extracted-concepts.yaml
directory: assimilation/canon-federation
name: extracted-concepts.yaml
- path: assimilation/canon-federation/mappings.yaml
directory: assimilation/canon-federation
name: mappings.yaml
- path: assimilation/canon-federation/open-questions.md
directory: assimilation/canon-federation
name: open-questions.md
- path: assimilation/canon-federation/proposed-changes.md
directory: assimilation/canon-federation
name: proposed-changes.md
- path: assimilation/canon-federation/source/research/CorpusIndex.md
directory: assimilation/canon-federation/source/research
name: CorpusIndex.md
- path: assimilation/canon-federation/source/research/README.md
directory: assimilation/canon-federation/source/research
name: README.md
- path: assimilation/canon-federation/source/research/ResearchSeed.md
directory: assimilation/canon-federation/source/research
name: ResearchSeed.md
- path: assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md
directory: assimilation/canon-federation/source/research/authentication-federation
name: nist-800-63-4.md
- path: assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md
directory: assimilation/canon-federation/source/research/authentication-federation
name: oidc-core-subject-identifiers.md
- path: assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md
directory: assimilation/canon-federation/source/research/authentication-federation
name: saml-nameid-federation.md
- path: assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md
directory: assimilation/canon-federation/source/research/authentication-federation
name: shared-signals-caep-risc.md
- path: assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md
directory: assimilation/canon-federation/source/research/authorization-relationships
name: cedar-principal-action-resource-context.md
- path: assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md
directory: assimilation/canon-federation/source/research/authorization-relationships
name: cerbos-abac-derived-roles.md
- path: assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md
directory: assimilation/canon-federation/source/research/authorization-relationships
name: openfga-modeling.md
- path: assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md
directory: assimilation/canon-federation/source/research/authorization-relationships
name: zanzibar-rebac.md
- path: assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: beneficial-ownership-kyc-boi.md
- path: assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: commercial-identity-nuance-settlement.md
- path: assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: commercial-identity-synthesis.md
- path: assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: commercial-trust-binding-theory.md
- path: assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: crm-pipeline-commitment-threshold.md
- path: assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: duns-commercial-credit-identity.md
- path: assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: eidas-eudi-legal-person-wallet.md
- path: assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: kyc-aml-commercial-identity-binding.md
- path: assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: legal-person-agency-contract.md
- path: assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: lei-gleif-legal-entity-identifier.md
- path: assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: payment-credential-pci-boundary.md
- path: assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: registry-identifier-subtypes.md
- path: assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: reputation-assurance-gradient.md
- path: assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md
directory: assimilation/canon-federation/source/research/commercial-identity
name: salesforce-crm-commercial-record.md
- path: assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md
directory: assimilation/canon-federation/source/research/commercial-subscription
name: b2b-saas-subscriber-tenancy.md
- path: assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md
directory: assimilation/canon-federation/source/research/commercial-subscription
name: stripe-customer-billing.md
- path: assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md
directory: assimilation/canon-federation/source/research/entity-resolution-privacy
name: deterministic-vs-probabilistic-matching.md
- path: assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md
directory: assimilation/canon-federation/source/research/entity-resolution-privacy
name: gdpr-pseudonymization.md
- path: assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md
directory: assimilation/canon-federation/source/research/entity-resolution-privacy
name: synonymity-assertions.md
- path: assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md
directory: assimilation/canon-federation/source/research/identity-provisioning
name: keycloak-organizations.md
- path: assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md
directory: assimilation/canon-federation/source/research/identity-provisioning
name: ldap-rfc4519-inetorgperson-rfc2798.md
- path: assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md
directory: assimilation/canon-federation/source/research/identity-provisioning
name: ory-kratos-keto.md
- path: assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md
directory: assimilation/canon-federation/source/research/identity-provisioning
name: scim-rfc7643-rfc7644.md
- path: assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md
directory: assimilation/canon-federation/source/research/identity-provisioning
name: zitadel-organizations-projects.md
- path: assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md
directory: assimilation/canon-federation/source/research/social-community-graphs
name: activitypub-actors-followers.md
- path: assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md
directory: assimilation/canon-federation/source/research/social-community-graphs
name: foaf-agent-person-group-onlineaccount.md
- path: assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md
directory: assimilation/canon-federation/source/research/social-community-graphs
name: schema-org-person-organization-membership.md
- path: assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md
directory: assimilation/canon-federation/source/research/social-community-graphs
name: webid-solid-profile.md
- path: assimilation/canon-federation/source/research/verifiable-claims/did-core.md
directory: assimilation/canon-federation/source/research/verifiable-claims
name: did-core.md
- path: assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md
directory: assimilation/canon-federation/source/research/verifiable-claims
name: openid4vc.md
- path: assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md
directory: assimilation/canon-federation/source/research/verifiable-claims
name: vc-data-model-2.md
- path: assimilation/canon-federation/source/scenarios/ScenarioTests.md
directory: assimilation/canon-federation/source/scenarios
name: ScenarioTests.md
- path: assimilation/canon-federation/source/terminology/TerminologyConflictMap.md
directory: assimilation/canon-federation/source/terminology
name: TerminologyConflictMap.md
- path: assimilation/canon-federation/source/terminology/TerminologyInventory.md
directory: assimilation/canon-federation/source/terminology
name: TerminologyInventory.md
- path: assimilation/canon-federation/source-summary.md
directory: assimilation/canon-federation
name: source-summary.md
- path: assimilation/canon-federation/views/family-area.md
directory: assimilation/canon-federation/views
name: family-area.md
- path: assimilation/canon-federation/views/itc-access.md
directory: assimilation/canon-federation/views
name: itc-access.md
- path: assimilation/canon-federation/views/itc-evid.md
directory: assimilation/canon-federation/views
name: itc-evid.md
- path: assimilation/canon-federation/views/itc-gov.md
directory: assimilation/canon-federation/views
name: itc-gov.md
- path: assimilation/canon-federation/views/itc-ident.md
directory: assimilation/canon-federation/views
name: itc-ident.md
- path: assimilation/canon-federation/views/itc-org.md
directory: assimilation/canon-federation/views
name: itc-org.md
- path: assimilation/emission-cadence/ASSIMILATION.md
directory: assimilation/emission-cadence
name: ASSIMILATION.md

6
infospace/indexes/concept-ownership.yaml
View file

@ -1,5 +1,9 @@
concept_count: 162
concept_count: 163
concepts:
- concept: Canon federation research provenance
owner: assimilation/canon-federation
path: assimilation/canon-federation/ASSIMILATION.md
source: artifact_title
- concept: "Assimilation \u2014 EmissionCadenceDeclaration handover"
owner: assimilation/emission-cadence
path: assimilation/emission-cadence/ASSIMILATION.md

13
infospace/indexes/import-matrix.yaml
View file

@ -1,4 +1,5 @@
artifacts:
- assimilation/canon-federation
- assimilation/emission-cadence
- assimilation/it-capability-canon
- benchmark/caring/kubernetes-rbac
@ -79,6 +80,18 @@ artifacts:
- standard/repository-layout
- standard/tagging
rows:
- artifact: assimilation/canon-federation
targets:
concept-area/family:
- uses
model/access-control:
- uses
model/evidence:
- uses
model/identity:
- uses
model/organization:
- uses
- artifact: assimilation/emission-cadence
targets:
kernel/itc-core:

3
infospace/views/by-concept.md
View file

@ -2,10 +2,11 @@
# By Concept
Concept count: **162**
Concept count: **163**
| Concept | Owner | Source |
| --- | --- | --- |
| Canon federation research provenance | `assimilation/canon-federation` | `artifact_title` |
| Assimilation — EmissionCadenceDeclaration handover | `assimilation/emission-cadence` | `artifact_title` |
| Assimilation — IT Capability Canon (ITCC) v0.1 | `assimilation/it-capability-canon` | `artifact_title` |
| CARING Kubernetes RBAC Benchmark | `benchmark/caring/kubernetes-rbac` | `artifact_title` |

5
infospace/views/by-mapping-target.md
View file

@ -41,6 +41,7 @@
## `concept-area/family`
- `assimilation/canon-federation` via `uses`
- `kernel/itc-kernel-map` via `maps`
## `concept-catalog/purpose-demand`
@ -106,6 +107,7 @@
## `model/access-control`
- `assimilation/canon-federation` via `uses`
- `benchmark/caring/kubernetes-rbac` via `stress_tests`
- `benchmark/caring/kubernetes-rbac/access-descriptors` via `uses`
- `benchmark/caring/kubernetes-rbac/caring-mapping` via `maps`
@ -156,6 +158,7 @@
## `model/evidence`
- `assimilation/canon-federation` via `uses`
- `kernel/itc-kernel-map` via `maps`
- `model/access-control` via `uses`
- `model/capability` via `uses`
@ -212,6 +215,7 @@
## `model/identity`
- `assimilation/canon-federation` via `uses`
- `kernel/itc-kernel-map` via `maps`
- `model/access-control` via `uses`
- `model/information-space` via `uses`
@ -270,6 +274,7 @@
## `model/organization`
- `assimilation/canon-federation` via `uses`
- `concept-area/family` via `uses`
- `evaluation/user-engine` via `uses`
- `evaluation/user-engine/questions` via `uses`

163
infospace/views/import-matrix.md
View file

@ -2,84 +2,85 @@
# Import Matrix
| Artifact | `assimilation/emission-cadence` | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `catalog/attribute-value-types` | `catalog/evidence-basis` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-area/family` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `example/emission-cadence/qonto-assistant` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/capability-anchors` | `mapping/emission-cadence-handover` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/evidence` | `model/governance` | `model/identity` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice-pattern/agentic-drives-functional` | `practice-pattern/interface-deprecation-strangler` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `scheme/practice-pattern` | `small-saas/capability-requirements/production` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/emission-cadence` | `standard/repository-layout` | `standard/tagging` |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| `assimilation/emission-cadence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | | `stress_tests` | | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` |
| `benchmark/caring/kubernetes-rbac/access-descriptors` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `benchmark/caring/kubernetes-rbac/caring-mapping` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | |
| `benchmark/caring/kubernetes-rbac/findings` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | |
| `benchmark/caring/kubernetes-rbac/native-concepts` | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | |
| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `catalog/attribute-value-types` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `catalog/evidence-basis` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` |
| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/frame` | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-area/family` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` |
| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | `maps` | | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | | | | `uses` | | | | | | `uses` | | | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `example/emission-cadence/qonto-assistant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | |
| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | `maps` | | | | | | | | | | | | | | `maps` | | | | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` |
| `mapping/capability-anchors` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `mapping/emission-cadence-handover` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/capability` | | `derived_from` | | | | | | `introduces` | | `uses` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `introduces` | | | | | | | `uses` | `uses` | | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/data` | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/evidence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/governance` | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/identity` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/purpose-demand-extension` | | | | | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `extends` | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `practice-pattern/agentic-drives-functional` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | `uses` | | | `related_to` | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | |
| `practice-pattern/interface-deprecation-strangler` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | |
| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `requires` | | `requires` | `requires` | | `requires` | | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | | | | | `requires` | | | `requires` |
| `review-kit/alignment` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `review-kit/alignment/model-selection-guide` | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` |
| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `scheme/practice-pattern` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/capability-requirements/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | `applies_to` | | | | | | | | | | |
| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | |
| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | |
| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | | | | | | | | | `instantiates` | | | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | |
| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | |
| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | `instantiates` | | | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | |
| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | |
| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | |
| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | |
| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | |
| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | |
| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | |
| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `imports` | | `imports` | `imports` | `uses` | `imports` | | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `imports` |
| `standard/emission-cadence` | `derived_from` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | | | | `imports` | | | `related_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Artifact | `assimilation/canon-federation` | `assimilation/emission-cadence` | `assimilation/it-capability-canon` | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `capability-catalog/itc-cap` | `catalog/attribute-value-types` | `catalog/evidence-basis` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-area/family` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `example/emission-cadence/qonto-assistant` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/capability-anchors` | `mapping/emission-cadence-handover` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/capability` | `model/data` | `model/devsecops` | `model/evidence` | `model/governance` | `model/identity` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `practice-pattern/agentic-drives-functional` | `practice-pattern/interface-deprecation-strangler` | `practice/intake-and-assimilation` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `scheme/practice-pattern` | `small-saas/capability-requirements/production` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/emission-cadence` | `standard/repository-layout` | `standard/tagging` |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| `assimilation/canon-federation` | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `assimilation/emission-cadence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `assimilation/it-capability-canon` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `benchmark/caring/kubernetes-rbac` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `stress_tests` | | | `stress_tests` | | `stress_tests` | | | | `stress_tests` | `stress_tests` | | | `stress_tests` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | `uses` |
| `benchmark/caring/kubernetes-rbac/access-descriptors` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `benchmark/caring/kubernetes-rbac/caring-mapping` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | |
| `benchmark/caring/kubernetes-rbac/findings` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | | | | | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | | |
| `benchmark/caring/kubernetes-rbac/native-concepts` | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | |
| `capability-catalog/itc-cap` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `catalog/attribute-value-types` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `catalog/evidence-basis` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/canon-benefit-analysis` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | `maps` | | | | | `maps` | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` |
| `comparison/repo-scoping/consumer-workplan-brief` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/extension-candidates` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `proposes` | | `proposes` | | | | | `proposes` | | `proposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/frame` | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `comparison/repo-scoping/report` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `compares` | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-area/family` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `concept-catalog/purpose-demand` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` |
| `conformance/railiance-fabric/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/entity-edge-capture-criteria` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/mapping-expectations` | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | `maps` | `maps` | | `maps` | | | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `conformance/railiance-fabric/visualization-examples` | | | | | | | | | | | | | | | | | | | `part_of` | | `illustrates` | `illustrates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `evaluation/user-engine/consumer-workplan-brief` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/interface-card-expectations` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `evaluation/user-engine/questions` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | `uses` | | | `uses` | | | | | | `uses` | `uses` | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `evaluation/user-engine/small-saas-alignment` | | | | | | | | | | | | | | | | | | | | | | | | `part_of` | | | | | | | | | | | | `uses` | | | | | `uses` | | | | | | `uses` | | | | | | | | `evaluates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `example/consumer-purpose-portfolio` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `illustrates` | | | `illustrates` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `example/emission-cadence/qonto-assistant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | |
| `kernel/itc-core` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `kernel/itc-kernel-map` | | | | | | | | | | | | | | | | | `maps` | | | | | | | | | | | | | | `maps` | | | | | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | | `maps` | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | `maps` |
| `mapping/capability-anchors` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `mapping/emission-cadence-handover` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | `maps` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | |
| `mapping/purpose-demand-governance-candidates` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `maps` | | | | | | | `maps` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/access-control` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/capability` | | | `derived_from` | | | | | | `introduces` | | `uses` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | `introduces` | | | | | | | `uses` | `uses` | | | `uses` | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/data` | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/devsecops` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/evidence` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/governance` | | | | | | | | | | | `introduces` | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/identity` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/information-space` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/landscape` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/network` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/observability` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/organization` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/purpose-demand-extension` | | | | | | | | | | | | | | | | | | `introduces` | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `extends` | | `uses` | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/security` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `uses` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `model/task` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `pattern/intent-scope-purposes` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `implements` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `practice-pattern/agentic-drives-functional` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | `uses` | | | | | `uses` | | | | `uses` | | | `related_to` | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | |
| `practice-pattern/interface-deprecation-strangler` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | `uses` | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | |
| `practice/intake-and-assimilation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `profile/small-saas` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `requires` | | `requires` | `requires` | | `requires` | | | `requires` | `requires` | `requires` | `requires` | | `requires` | `requires` | | | | | | | | | | | | | | | | | | | | | | | | | | | `requires` | | | `requires` |
| `review-kit/alignment` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | |
| `review-kit/alignment/model-selection-guide` | | | | `uses` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | `uses` | | `uses` | | | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | | | | | `uses` | `part_of` | | | | | | | | | | | | | | | | | | | | | `uses` | | | `uses` |
| `review-kit/alignment/schema` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/scorecard` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workflow` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `review-kit/alignment/workplan-template` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | `uses` | | | | | | `part_of` | | | | | | | | | | | | | | | | | | | | | | | | |
| `scheme/practice-pattern` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/capability-requirements/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | `applies_to` | | | | | | | | | | |
| `small-saas/control/namespace-per-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | | | | `evidenced_by` | | | | | | | | | | `uses` | | | |
| `small-saas/dataset/subscription-ledger` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | `owned_by` | | | | `partitioned_for` | `partitioned_for` | | | | | |
| `small-saas/deployment/production` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `uses` | | | | | | | | | | `instantiates` | | | | | | | | | `implements` | | | | | | `deploys` | | | | `separates` | `separates` | | | | | |
| `small-saas/evidence/access-review-2026-05` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/incident/cross-tenant-access-attempt` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | `instantiates` | | | | | | | | | `constrained_by` | | | `evidenced_by` | | | | | | | | | | | | | |
| `small-saas/policy/tenant-isolation` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | | | | `instantiates` | | | | | | | | | `requires` | | | `evidenced_by` | | | | | | | | | | | | | |
| `small-saas/service/billing-portal` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | `part_of` | | `owned_by` | | | | | | | |
| `small-saas/system/billing-system` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | `serves` | `serves` | | | | | |
| `small-saas/task/onboard-tenant` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | `instantiates` | | | | | | | | | | | | | | `governed_by` | | | | `owned_by` | `changes` | | | | | | |
| `small-saas/team/platform` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | | | | | | | | | | | | | | |
| `small-saas/tenant/acme` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | `represented_by` | | | | |
| `small-saas/tenant/globex` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | `isolated_by` | | | | | | | | | | | | | | | | |
| `small-saas/user/ada-admin` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `uses` | | | | | | | | | | | `uses` | | | | | | | | `instantiates` | | | | | | | | | | | | `access_evidenced_by` | | `has_access_under` | | | | `member_of` | | | | | | | |
| `standard/caring` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | `imports` | | `imports` | `imports` | `uses` | `imports` | | | | `imports` | `imports` | `imports` | | `imports` | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `imports` |
| `standard/emission-cadence` | | `derived_from` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | | | | `imports` | | | `related_to` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/repository-layout` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | | `imports` | | `imports` | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| `standard/tagging` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `conforms_to` | | | | | | | | | `uses` | | | | | | | | | | `imports` | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

6
infospace/views/kernel-overview.md
View file

@ -3,7 +3,7 @@
# Kernel Overview
- Infospace: `canon`
- Artifacts: 79
- Artifacts: 80
## Artifact Kinds
@ -12,7 +12,7 @@
- `alignment-review-schema`: 1
- `alignment-review-workflow`: 1
- `alignment-scorecard`: 1
- `assimilation`: 2
- `assimilation`: 3
- `benchmark-findings`: 1
- `benchmark-workspace`: 1
- `benefit-analysis`: 1
@ -81,4 +81,4 @@
- `separates`: 2
- `serves`: 2
- `stress_tests`: 6
- `uses`: 147
- `uses`: 152

63
infospace/views/repository-tree.md
View file

@ -2,7 +2,7 @@
# Repository Tree
File count: **215**
File count: **276**
- `README.md`
- `agent/README.md`
@ -82,6 +82,67 @@ File count: **215**
- `agent/templates/consumer-brief.template.md`
- `artifacts/index.yaml`
- `assimilation/README.md`
- `assimilation/canon-federation/ASSIMILATION.md`
- `assimilation/canon-federation/README.md`
- `assimilation/canon-federation/assimilation.yaml`
- `assimilation/canon-federation/comparison-matrix.md`
- `assimilation/canon-federation/distribution.json`
- `assimilation/canon-federation/extracted-concepts.yaml`
- `assimilation/canon-federation/mappings.yaml`
- `assimilation/canon-federation/open-questions.md`
- `assimilation/canon-federation/proposed-changes.md`
- `assimilation/canon-federation/source/research/CorpusIndex.md`
- `assimilation/canon-federation/source/research/README.md`
- `assimilation/canon-federation/source/research/ResearchSeed.md`
- `assimilation/canon-federation/source/research/authentication-federation/nist-800-63-4.md`
- `assimilation/canon-federation/source/research/authentication-federation/oidc-core-subject-identifiers.md`
- `assimilation/canon-federation/source/research/authentication-federation/saml-nameid-federation.md`
- `assimilation/canon-federation/source/research/authentication-federation/shared-signals-caep-risc.md`
- `assimilation/canon-federation/source/research/authorization-relationships/cedar-principal-action-resource-context.md`
- `assimilation/canon-federation/source/research/authorization-relationships/cerbos-abac-derived-roles.md`
- `assimilation/canon-federation/source/research/authorization-relationships/openfga-modeling.md`
- `assimilation/canon-federation/source/research/authorization-relationships/zanzibar-rebac.md`
- `assimilation/canon-federation/source/research/commercial-identity/beneficial-ownership-kyc-boi.md`
- `assimilation/canon-federation/source/research/commercial-identity/commercial-identity-nuance-settlement.md`
- `assimilation/canon-federation/source/research/commercial-identity/commercial-identity-synthesis.md`
- `assimilation/canon-federation/source/research/commercial-identity/commercial-trust-binding-theory.md`
- `assimilation/canon-federation/source/research/commercial-identity/crm-pipeline-commitment-threshold.md`
- `assimilation/canon-federation/source/research/commercial-identity/duns-commercial-credit-identity.md`
- `assimilation/canon-federation/source/research/commercial-identity/eidas-eudi-legal-person-wallet.md`
- `assimilation/canon-federation/source/research/commercial-identity/kyc-aml-commercial-identity-binding.md`
- `assimilation/canon-federation/source/research/commercial-identity/legal-person-agency-contract.md`
- `assimilation/canon-federation/source/research/commercial-identity/lei-gleif-legal-entity-identifier.md`
- `assimilation/canon-federation/source/research/commercial-identity/payment-credential-pci-boundary.md`
- `assimilation/canon-federation/source/research/commercial-identity/registry-identifier-subtypes.md`
- `assimilation/canon-federation/source/research/commercial-identity/reputation-assurance-gradient.md`
- `assimilation/canon-federation/source/research/commercial-identity/salesforce-crm-commercial-record.md`
- `assimilation/canon-federation/source/research/commercial-subscription/b2b-saas-subscriber-tenancy.md`
- `assimilation/canon-federation/source/research/commercial-subscription/stripe-customer-billing.md`
- `assimilation/canon-federation/source/research/entity-resolution-privacy/deterministic-vs-probabilistic-matching.md`
- `assimilation/canon-federation/source/research/entity-resolution-privacy/gdpr-pseudonymization.md`
- `assimilation/canon-federation/source/research/entity-resolution-privacy/synonymity-assertions.md`
- `assimilation/canon-federation/source/research/identity-provisioning/keycloak-organizations.md`
- `assimilation/canon-federation/source/research/identity-provisioning/ldap-rfc4519-inetorgperson-rfc2798.md`
- `assimilation/canon-federation/source/research/identity-provisioning/ory-kratos-keto.md`
- `assimilation/canon-federation/source/research/identity-provisioning/scim-rfc7643-rfc7644.md`
- `assimilation/canon-federation/source/research/identity-provisioning/zitadel-organizations-projects.md`
- `assimilation/canon-federation/source/research/social-community-graphs/activitypub-actors-followers.md`
- `assimilation/canon-federation/source/research/social-community-graphs/foaf-agent-person-group-onlineaccount.md`
- `assimilation/canon-federation/source/research/social-community-graphs/schema-org-person-organization-membership.md`
- `assimilation/canon-federation/source/research/social-community-graphs/webid-solid-profile.md`
- `assimilation/canon-federation/source/research/verifiable-claims/did-core.md`
- `assimilation/canon-federation/source/research/verifiable-claims/openid4vc.md`
- `assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md`
- `assimilation/canon-federation/source/scenarios/ScenarioTests.md`
- `assimilation/canon-federation/source/terminology/TerminologyConflictMap.md`
- `assimilation/canon-federation/source/terminology/TerminologyInventory.md`
- `assimilation/canon-federation/source-summary.md`
- `assimilation/canon-federation/views/family-area.md`
- `assimilation/canon-federation/views/itc-access.md`
- `assimilation/canon-federation/views/itc-evid.md`
- `assimilation/canon-federation/views/itc-gov.md`
- `assimilation/canon-federation/views/itc-ident.md`
- `assimilation/canon-federation/views/itc-org.md`
- `assimilation/emission-cadence/ASSIMILATION.md`
- `assimilation/emission-cadence/assimilation.yaml`
- `assimilation/emission-cadence/comparison-matrix.md`

2
tests/test_cli.py
View file

@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None:
assert exit_code == 0
payload = json.loads(capsys.readouterr().out)
assert payload["ok"] is True
assert payload["infospace"]["artifact_count"] == 79
assert payload["infospace"]["artifact_count"] == 80
def test_cli_missing_profile_uses_structured_error(capsys) -> None:

8
tests/test_service.py
View file

@ -25,11 +25,11 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
assert payload["ok"] is True
assert payload["infospace"]["slug"] == "canon"
assert payload["infospace"]["artifact_count"] == 79
assert payload["infospace"]["artifact_count"] == 80
assert payload["infospace"]["kinds"] == {
"access-descriptor-set": 1,
"alignment-review-kit": 1,
"assimilation": 2,
"assimilation": 3,
"alignment-review-schema": 1,
"alignment-review-workflow": 1,
"alignment-scorecard": 1,
@ -100,14 +100,14 @@ def test_validate_canon_passes_scaffold() -> None:
assert payload["ok"] is True
assert payload["errors"] == []
assert "warnings" in payload
assert payload["details"]["artifact_count"] == 79
assert payload["details"]["artifact_count"] == 80
def test_graph_exports_relationship_summary() -> None:
payload = artifact_graph()
assert payload["ok"] is True
assert payload["graph"]["node_count"] == 79
assert payload["graph"]["node_count"] == 80
assert payload["graph"]["edge_count"] > 15

62
workplans/INFO-WP-0024-corpus-provenance.md Normal file
View file

@ -0,0 +1,62 @@
---
id: INFO-WP-0024
type: workplan
title: "Federation corpus provenance distribution"
domain: infotech
repo: info-tech-canon
status: finished
owner: codex
topic_slug: canon
created: "2026-09-06"
updated: "2026-09-06"
state_hub_workstream_id: "3bea30f6-8640-5c16-b782-8258babdba35"
---
# Federation corpus provenance distribution
Implements CFED-WP-0001-T07; observe completed research without adopting new canon.
## Freeze and route the source material
```task
id: INFO-WP-0024-T01
status: done
priority: medium
state_hub_task_id: "6b5f14d1-0513-5ca0-a173-1daa5624da14"
```
Preserve originals and place destination snapshots with source Git revision and
hashes. Index sources by inherited concepts and retain context for shared notes.
## Split mixed material into traceable reading views
```task
id: INFO-WP-0024-T02
status: done
priority: medium
state_hub_task_id: "444d1943-60e4-5ef4-a0e5-d05e27cec81d"
```
Route exact terminology rows, conflict sections and scenarios by destination
interest. Mark historical conflicts and reuse accepted ownership mappings.
## Verify and reconcile
```task
id: INFO-WP-0024-T03
status: done
priority: medium
state_hub_task_id: "bd04a7b9-2b02-5e05-9991-e561f7622ae9"
```
Verify full corpus coverage, immutable copies and fragment hashes, local links,
assimilation metadata and repository checks. CFED T08/T09/T10 retain live interface,
fleet and residual work. No new model adoption is claimed.
## Verification — 2026-09-06
G6 validator passes: all 45 sources routed, 69 byte-identical destination copies,
153 exact fragments and 479 workspace links checked; originals unchanged.
InfoTechCanon make check passes all 46 tests plus generated, canon and profile
validation. Federation ownership validator passes.
See [project evidence](../../prj-canon-federation/docs/evidence/2026-09-06-corpus-distribution.md).

8
workplans/index.yaml
View file

@ -16,6 +16,14 @@ implementation_decisions:
consumer_workplans_live_in_consumer_repos: true
workplans:
- id: INFO-WP-0024
title: Federation corpus provenance distribution
status: finished
priority: medium
path: workplans/INFO-WP-0024-corpus-provenance.md
depends_on: [INFO-WP-0023]
produces: [frozen research snapshots, destination provenance indexes]
- id: INFO-WP-0023
title: Limited Family concept-area seed
status: finished