R-3 is resolved by disambiguation without a rename. CARING section 10.7 now says its Authority exposure mode names a demanding party rather than a right, links to ITC-ORG section 10.17, and notes that such an Authority holds no organizational authority over the system it compels. ITC-ORG carries the reciprocal sentence and records that SecurityCanon's AuthMode qualifies the exercise of the right rather than redefining it. The seventeen concepts no artifact declared are now declared: eleven to the Organization Model, four to CARING and two to the Capability Model. Capacity in the Organization Model and Capacity behaviour in the Capability Model are two concepts, not one, and neither moves. Two of CARING's four turned out not to be new concepts at all but the prose spellings of CaringCapabilityProfile and CaringDerivedCapability; both spellings are declared to the same owner so the name a reader meets resolves. Effective Access and Declared Access were genuinely undeclared. Three boundary reviews are added for organization, caring and capability, bringing the count to fourteen. The concept_defined_without_owner warning is at zero, and the test that asserted it fires now proves it on a modified corpus instead of on the live one. make check passes with 54 tests, clean validation, no warnings, no stale assets. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
2.4 KiB
2.4 KiB
CARING access governance concept boundary review — 2026-09-20
Authority: INFO-WP-0027-T07, which declared the concepts CARING defines, T05, which resolved residual R-3, and ADHOC-2026-09-20-T01, which bound the Scope dimension to one definition. No concept is renamed, moved or removed.
| Concept | Owner | Resolution | Decided by |
|---|---|---|---|
Effective Access |
standard/caring | CARING's central distinction, with Declared Access. Declared here under T07; the Kubernetes RBAC benchmark depends on it. |
this review |
Declared Access |
standard/caring | As above. Access Control owns the authorization mechanisms; CARING owns the declared-against-effective analysis over them. | this review |
Capability Profile |
standard/caring | The prose spelling of the declared CaringCapabilityProfile. Both spellings are declared so that the name a reader meets in the text resolves; one owner, no conflict. |
this review |
Derived Capability |
standard/caring | As above, for CaringDerivedCapability. |
this review |
Authority |
model/organization | CARING section 10.7 names a legal, regulatory or institutional body with exceptional access claims — a demanding party, not a right. ITC-ORG section 10.17 owns Authority as the right itself. Both sections now carry the disambiguation. |
this review (R-3) |
Scope |
model/identity | ITC-IDENT section 2.10 owns the general boundary. CARING section 21 ranges over its instances and its ladder is a value set, not a second definition. ITC-ACCESS ResourceScope refines the same concept. |
ADHOC-2026-09-20-T01 |
Environment |
model/landscape | The kernel map assigns Environment to Landscape. CARING section 21.5 enumerates values for it; SecurityCanon imports it from Landscape. | kernel map |
Subject |
model/access-control | ITC-ACCESS owns Subject as the access-control view of an actor. CARING analyses subjects and imports. | this review |
Canonical Role, Plane, Condition |
standard/caring | CARING's own dimensions. Operator the role is not OPERATE the SecurityCanon auth mode, and Condition is not Activation; both pairs are recorded as distinct in the SecurityCanon boundary. |
SECURITY-DEC-2026-003 |
Concepts this artifact declares are listed in its frontmatter. An overlap recorded here means another artifact defines the same name; where the owner is another artifact, this one imports the definition rather than restating it.