docs(canon): reconcile workload and tenant grouping semantics
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
This commit is contained in:
parent
ad2057acff
commit
bee22db620
21 changed files with 1118 additions and 59 deletions
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0006
|
||||
type: architecture-decision-record
|
||||
title: "Recursive Multi-Tenant Identity and Authorization Architecture"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-17"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0006 - Recursive Multi-Tenant Identity and Authorization Architecture
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0007
|
||||
type: architecture-decision-record
|
||||
title: "Security Orchestration Boundary"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-18"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0007 - Security Orchestration Boundary
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0008
|
||||
type: architecture-decision-record
|
||||
title: "Object Storage STS Credential Vending Boundary"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-18"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0008 - Object Storage STS Credential Vending Boundary
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0010
|
||||
type: architecture-decision-record
|
||||
title: "Orchestration vs Dependency, and Self-Coherent Intent"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-21"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0010 - Orchestration vs Dependency, and Self-Coherent Intent
|
||||
|
||||
**Status:** Accepted (repo classification subject to ongoing refinement)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0011
|
||||
type: architecture-decision-record
|
||||
title: "NetKingdom IAM Profile Ownership And Version Governance"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-22"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0011 - NetKingdom IAM Profile Ownership And Version Governance
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0012
|
||||
type: architecture-decision-record
|
||||
title: "Playbook Capability Contract Ownership"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-05-22"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0012 - Playbook Capability Contract Ownership
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,7 +1,20 @@
|
|||
---
|
||||
id: NK-ADR-0013
|
||||
type: architecture-decision-record
|
||||
title: "Tenant Onboarding Grouping Taxonomy"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "2"
|
||||
decided: "2026-07-23"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0013 - Tenant Onboarding Grouping Taxonomy
|
||||
|
||||
**Status:** Accepted
|
||||
**Date:** 2026-07-23
|
||||
**Amended:** 2026-08-22 (current classification versus historical identifier segment)
|
||||
**Deciders:** Bernd Worsch, Codex
|
||||
|
||||
## Context
|
||||
|
|
@ -54,12 +67,26 @@ association - a legal association of people
|
|||
agentic - financially enabled AI entities
|
||||
```
|
||||
|
||||
This grouping is deliberately **orthogonal to capability role**
|
||||
(`PLTF`/`IAM`/`VEN`/`CUS`, still unratified): the grouping describes *what
|
||||
kind of entity a tenant is and how it was onboarded*; role describes *what
|
||||
it does on the platform*. Both may need to be carried as tenant metadata,
|
||||
but never conflated into one identifier segment — that conflation is exactly
|
||||
what this ADR avoids.
|
||||
The taxonomy has two deliberately different uses:
|
||||
|
||||
- At creation, the identifier's grouping segment records the tenant's
|
||||
onboarding-time classification. The complete identifier is immutable, so
|
||||
this segment is historical after creation.
|
||||
- The tenant record's `grouping` field records current classification. It may
|
||||
change as the entity changes and is authoritative for present-day policy,
|
||||
including guardrails and spend ceilings.
|
||||
|
||||
No consumer may parse the identifier's middle segment and treat it as current
|
||||
grouping. Consumers needing current grouping MUST read it from `tenant-engine`.
|
||||
Identifier creation still validates the segment against this vocabulary;
|
||||
historical does not mean free-form or optional.
|
||||
|
||||
Grouping is deliberately **orthogonal to capability role**
|
||||
(`PLTF`/`IAM`/`VEN`/`CUS`, subsequently ratified by ADR-0014): grouping
|
||||
describes *what kind of entity a tenant is and its current onboarding-risk
|
||||
classification*; role describes *what it does on the platform*. Both are
|
||||
carried as tenant metadata, but never conflated into the immutable identifier
|
||||
segment — that conflation is exactly what this ADR avoids.
|
||||
|
||||
`tenant:platform` and `tenant:coulomb` remain **reserved, ungrouped
|
||||
identifiers outside this taxonomy**: `tenant:platform` is the control-plane
|
||||
|
|
@ -101,10 +128,15 @@ section — not a new versioned profile document.
|
|||
already reflects this decision (`tenant:friendly:binky`).
|
||||
- Future tenant onboarding work should classify a tenant against this list
|
||||
before minting an identifier, rather than reaching for a role word.
|
||||
- The capability-role model (`PLTF`/`IAM`/`VEN`/`CUS`) remains a separate,
|
||||
still-unratified dimension; this ADR does not ratify that model, only
|
||||
avoids colliding with it. If/when it is ratified, role metadata should be
|
||||
carried alongside — not instead of — the grouping segment decided here.
|
||||
- Tenant identifiers never change when current grouping changes. The middle
|
||||
segment is creation-time history; `tenant-engine` is authoritative for the
|
||||
current grouping value.
|
||||
- Policy and commercial consumers, including spend-ceiling resolution, MUST
|
||||
query `tenant-engine` and MUST NOT derive current grouping by splitting a
|
||||
tenant identifier.
|
||||
- The capability-role model (`PLTF`/`IAM`/`VEN`/`CUS`) remains a separate
|
||||
dimension, now ratified by ADR-0014. Role metadata is carried alongside —
|
||||
not instead of — current grouping and the historical identifier segment.
|
||||
- `tenant:platform` and `tenant:coulomb` are reserved outside the taxonomy,
|
||||
pending Bernd's explicit confirmation (see Decision).
|
||||
|
||||
|
|
@ -138,6 +170,8 @@ resolved before the first non-Coulomb tenant goes live, not after.
|
|||
reviewable change).
|
||||
- Confirm the `tenant:platform`/`tenant:coulomb` reserved/ungrouped
|
||||
treatment explicitly.
|
||||
- If/when the `PLTF`/`IAM`/`VEN`/`CUS` capability-role model is ratified,
|
||||
define how role metadata is carried alongside the grouping segment
|
||||
decided here.
|
||||
- ADR-0014 and the Tenant Engine Boundary Contract define how capability-role
|
||||
metadata is carried alongside grouping.
|
||||
- Keep `tenant-engine`'s identifier parser vocabulary-validating for creation
|
||||
and lookup compatibility, but do not expose parsed grouping as current
|
||||
classification.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0014
|
||||
type: architecture-decision-record
|
||||
title: "Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-07-23"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0014 - Tenant Capability Roles, Carrying Mechanism, and Tenant-Engine Ownership
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
|
|
@ -1,3 +1,15 @@
|
|||
---
|
||||
id: NK-ADR-0015
|
||||
type: architecture-decision-record
|
||||
title: "NetKingdom Railiance Workload Packaging and Relational Platform"
|
||||
status: accepted
|
||||
owner: net-kingdom
|
||||
revision: "1"
|
||||
decided: "2026-08-11"
|
||||
last_reviewed: "2026-08-22"
|
||||
review_interval: 12m
|
||||
---
|
||||
|
||||
# ADR-0015 - NetKingdom Railiance Workload Packaging and Relational Platform
|
||||
|
||||
**Status:** Accepted
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue