Resolve the two senses of Authority and declare the unowned remainder (T05, T07)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s

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
This commit is contained in:
tegwick 2026-09-20 23:32:57 +02:00
parent 4a35bfe489
commit 5f652d200f
18 changed files with 326 additions and 17 deletions

View file

@ -7,6 +7,17 @@ version: RC1-seed
# Incremental machine-readable ownership for the social extension; existing
# organization concepts retain their definitions and ownership declarations below.
owned_concepts:
- Assignment
- Availability
- Capacity
- CollectiveActor
- Competence
- Group
- OrganizationEntity
- OrganizationalCapability
- Post
- ReportingLine
- Skill
- Accountability
- Actor
- Agent
@ -852,6 +863,12 @@ Profiles MAY require exactly one accountable actor per scope, but the core model
**Authority** is the recognized right to make decisions, allocate resources, approve changes, enforce rules, or direct action within a scope.
This is the concept SecurityCanon's Auth Mode qualifies: an auth mode describes
the relationship in which this right is exercised, not the right itself. It is
distinct from the CARING section 10.7 Authority exposure mode, which names an
external body compelling disclosure rather than a right held within the
organization.
Subtypes:
```text

View file

@ -0,0 +1,19 @@
# InfoTechCanon Organization Model concept boundary review — 2026-09-20
Authority: INFO-WP-0027-T02 and T07, which declared the concepts this model
defines, and T05, which resolved residual R-3 from the SecurityCanon boundary
review. No concept is renamed, moved or removed.
| Concept | Owner | Resolution | Decided by |
| --- | --- | --- | --- |
| `Authority` | model/organization | The recognized right to make decisions, allocate resources, approve changes, enforce rules or direct action within a scope. The CARING section 10.7 `Authority` exposure mode names an external body compelling disclosure, not a right; both sections now say so. SecurityCanon's `AuthMode` qualifies the exercise of this right and does not redefine it. | this review (R-3) |
| `Actor` | model/organization | Declared here under T02. ITC-ACCESS binds `Subject` as the access-control view of an actor; the identity model imports Actor; SecurityCanon imports it against a pinned hash. | kernel map |
| `Ownership` | model/organization | The kernel map assigns Ownership and Stewardship here. SecurityCanon's manifest pinned it to Core until the T04 name-resolution audit corrected it. | kernel map |
| `Capacity` | model/organization | The amount of work or responsibility an actor or group can realistically absorb in a period. The Capability Model's `Capacity behaviour` describes how a capability's supply responds to demand. Different questions, different names; no transfer. | this review |
| `OrganizationalCapability` | model/organization | The capacity of an organization to reliably perform a class of work. The Capability Model owns `Capability` as the canonical capability concept; this is the organizational reading of it and imports rather than competes. | this review |
| `CollectiveActor` | model/organization | A group-like actor that can hold responsibility or authority. Distinct from `Group`, which is structural, and from identity's collective concepts. | this review |
| `Person`, `Agent`, `Role`, `Membership`, `Responsibility`, `Accountability`, `Position`, `Team` | model/organization | Assigned here by the kernel map concept-owner table and declared under T02. | kernel map |
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.