Survey where InfoTechCanon already speaks about authority (T03)
Fifty-two InfoTechCanon files mention authority; twenty are live canon and thirty-two are preserved assimilation source. The survey separates three senses of the word already in use — the right itself (itc-org:Authority, ITC-ORG 10.17), an external body compelling disclosure (CARING 10.7 exposure mode), and the relationship in which authority is exercised (sec-authority:AuthMode) — and records, per artifact, how SecurityCanon must reference rather than restate them. Two corrections follow, applied through the amendment procedure SECURITY-DEC-2026-003 requires. itc-org:Authority is a live concept that no owned_concepts declaration lists, so the boundary review's conflict check could not see it; it becomes a declared import on the existing organization-model entry, whose pinned hash is unchanged. Environment was listed as SecurityCanon-owned but CARING 21.5 already defines it, which the decision forbids; InfoTechCanon owns it, SecurityCanon imports it with a newly pinned CARING hash, and the RECOVERY value is carried as an upstream value proposal. The declared import list goes from ten concepts to twelve. Two findings need no change here. CARING's Authority exposure mode against itc-org:Authority becomes residual R-3, InfoTechCanon-internal. itc-ident:Realm against AuthorityRealm owes the disambiguation page a line but no rename. AuthorityContext, AuthorityProvenance, Activation, EvidenceBoundary and AccessSituation collide with nothing in the live corpus. No InfoTechCanon file is changed by this survey. 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:
parent
67f7c2e614
commit
c7482c6823
5 changed files with 172 additions and 9 deletions
|
|
@ -28,6 +28,9 @@ Pinned import source: info-tech-canon at
|
|||
| Scope | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | ITC-ACCESS is the single definition. See residual R-1. |
|
||||
| AccessOperations | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | Orthogonal to Auth Mode: `read + USE` and `read + OBSERVE` share an operation. |
|
||||
| Purpose | InfoTechCanon | Purpose and Demand extension | ITC → SC (import) | Resolves to the extension, not to a SecurityCanon definition. |
|
||||
| Authority | InfoTechCanon | Organization Model (ITC-ORG 10.17) | ITC → SC (import) | The recognized right itself. AuthMode qualifies its exercise and never redefines it. Added by T03 (F-1). |
|
||||
| Environment | InfoTechCanon | CARING 21.5 | ITC → SC (import) | Corrected by T03 (F-3); the SecurityCanon `RECOVERY` value is an upstream proposal. |
|
||||
| Realm | InfoTechCanon | Identity Model (ITC-IDENT 2.12) | ITC-only | Adjacent to `AuthorityRealm`, not the same question; disambiguation owed, no rename. |
|
||||
| Canonical Role | InfoTechCanon | CARING | ITC-only | `Operator` the role and `OPERATE` the auth mode are different axes; neither is renamed. |
|
||||
| Plane | InfoTechCanon | CARING | ITC-only | Names a surface. `Build Plane` and `CONSTRUCT` stay distinct. |
|
||||
| Condition | InfoTechCanon | CARING | ITC-only | Overlaps `Activation` in intent; both stand, neither is aliased. |
|
||||
|
|
@ -40,10 +43,9 @@ Pinned import source: info-tech-canon at
|
|||
| Activation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | `STANDING`, `JIT`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY`. |
|
||||
| EvidenceBoundary | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | "Can the observed actor alter, suppress or bypass its own evidence?" |
|
||||
| AccessSituation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | |
|
||||
| Environment | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | |
|
||||
| Time | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | Dimension slot only; no upstream time model is claimed. |
|
||||
|
||||
**Declared imports are closed at this list.** The ten InfoTechCanon concepts
|
||||
**Declared imports are closed at this list.** The twelve InfoTechCanon concepts
|
||||
marked `ITC → SC` are exactly those in `imports.json`. Any further InfoTechCanon
|
||||
concept SecurityCanon comes to need must be added there with a pinned blob hash
|
||||
before it is used, not referenced informally.
|
||||
|
|
@ -86,12 +88,27 @@ with SECURITY-WP-0001-T05, the migration handoff, having been cancelled.
|
|||
settled by SECURITY-DEC-2026-002. SecurityCanon renamed its own dimension to
|
||||
`AuthorityContext`; CARING is not rewritten.
|
||||
|
||||
## Amendments
|
||||
|
||||
- **2026-09-20, SECURITY-WP-0001-T03.** The reference-impact survey
|
||||
(`infospace/mappings/infotechcanon-authority-survey.md`) found two corrections.
|
||||
`itc-org:Authority` is a live InfoTechCanon concept that no `owned_concepts`
|
||||
declaration lists, so neither the boundary review nor this table saw it; it is
|
||||
now the eleventh declared import. `Environment` was listed as
|
||||
SecurityCanon-owned but is already defined in CARING section 21.5, so it moves
|
||||
to imported and becomes the twelfth. Both are recorded in `imports.json`
|
||||
through the amendment procedure this decision requires.
|
||||
|
||||
## Residuals
|
||||
|
||||
- **R-1 — CARING `Scope` and ITC-ACCESS `Scope`.** The review found two
|
||||
definitions of one concept inside InfoTechCanon. This record names ITC-ACCESS
|
||||
as the owner; reconciling CARING's wording to it is an InfoTechCanon-internal
|
||||
change and is not made here.
|
||||
- **R-3 — CARING `Authority` exposure mode against `itc-org:Authority`.** One
|
||||
word, two live InfoTechCanon senses: a right held by an actor (ITC-ORG 10.17)
|
||||
and an external body compelling disclosure (CARING 10.7). Disambiguation is
|
||||
InfoTechCanon-internal and is not made here.
|
||||
- **R-2 — CARING section 32 generalisation.** Referenced by SecurityCanon,
|
||||
explicitly not accepted by the InfoTechCanon-side boundary review. It remains
|
||||
an InfoTechCanon proposal requiring its own review.
|
||||
|
|
|
|||
90
infospace/mappings/infotechcanon-authority-survey.md
Normal file
90
infospace/mappings/infotechcanon-authority-survey.md
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
# Reference-impact survey — where InfoTechCanon already speaks about authority
|
||||
|
||||
Status: survey complete, 2026-09-20 (SECURITY-WP-0001-T03).
|
||||
Survey base: info-tech-canon at `e1f98da015f32545254747c8e9f59b780c423d5b`,
|
||||
the revision pinned by `imports.json`.
|
||||
|
||||
Purpose: publish the Mode of Authority vocabulary *against* what InfoTechCanon
|
||||
already says rather than beside it. With migration off the table
|
||||
(SECURITY-DEC-2026-003), this is a survey for correct referencing and
|
||||
non-collision, not a migration sizing exercise.
|
||||
|
||||
Method: every InfoTechCanon file mentioning "authorit*" was enumerated — 52
|
||||
files, of which 20 lie outside `infospace/assimilation/` and are live canon
|
||||
rather than preserved source. Each SecurityCanon concept was then checked by
|
||||
name against the live corpus.
|
||||
|
||||
## 1. Three senses of "authority" already in use
|
||||
|
||||
The word carries three distinct meanings across the two canons. None is wrong;
|
||||
they must simply never be conflated.
|
||||
|
||||
| Sense | Where | Meaning |
|
||||
| --- | --- | --- |
|
||||
| **A — a right held by an actor** | `itc-org:Authority`, ITC-ORG §10.17 | "The recognized right to make decisions, allocate resources, approve changes, enforce rules, or direct action within a scope." Subtypes: Decision, Approval, Budget, Operational, Technical, Policy, Emergency. |
|
||||
| **B — an external demanding party** | CARING §10.7 exposure mode | `Authority LegalDemand`, `Authority AuditDemand`, `Authority DisclosureDemand` — an outside body compelling disclosure, modelled as an exposure event. |
|
||||
| **C — the relationship of exercise** | `sec-authority:AuthMode` | In what relationship to the system authority is exercised: USE, OBSERVE, OPERATE, CONSTRUCT, GOVERN. |
|
||||
|
||||
Sense C qualifies the exercise of sense A. It does not define, replace or
|
||||
subsume it. Sense B is unrelated to both and is the one most likely to be
|
||||
misread.
|
||||
|
||||
## 2. Where authority appears in live InfoTechCanon
|
||||
|
||||
| Artifact | How authority appears | Referencing rule for SecurityCanon |
|
||||
| --- | --- | --- |
|
||||
| Organization Model (ITC-ORG) | Owns `Authority` (§10.17), Actor, Role, Responsibility, Accountability, Delegation entry point (§10.18). 55 mentions — the densest surface. | **Import `itc-org:Authority`.** AuthMode qualifies its exercise; never redefine it. |
|
||||
| CARING standard | 36 mentions. §10.7 Authority exposure mode (sense B); §21.5 Environment; Canonical Role, Plane, Condition, Capability. | Cite by section. `Authority` in CARING is sense B — say so wherever both appear. |
|
||||
| Governance Model | 15 mentions; references `itc-org:Authority` by qualified id; owns the rules that direct and review authorities. | Governance owns the *rules*; SecurityCanon owns neither. |
|
||||
| Task Model | 11 mentions; `AuthorityRequirement`, reachability requiring "sufficient authority". | A work item's authority requirement may cite an AuthMode; the requirement stays task-owned. |
|
||||
| Kernel map | Assigns `Authority → Organization` (line 306), `Authority source → Governance` (line 716). | The kernel map is the arbiter of sense A's owner. |
|
||||
| Access Control Model (ITC-ACCESS) | `DelegatedAccess` "delegates access authority"; Subject, Principal, Scope, AccessOperations. | Already imported. AuthMode is orthogonal to AccessOperations. |
|
||||
| Identity Model (ITC-IDENT) | Owns `Realm` (§2.12), Delegation Relationship, Representation Relationship, Administration Relationship. | See F-4. Delegation is the granting mechanism; AuthorityProvenance records *that* a grant happened. |
|
||||
| AgenticDrivesFunctional pattern | "must not invent authority"; "no call transfers authority the caller does not hold". | The strongest existing consumer of sense A. AuthMode gives it vocabulary; the pattern's rules are unchanged. |
|
||||
| Evidence Model, evidence-basis, Landscape, Network, Tagging, Purpose-Demand | Incidental single mentions. | No referencing obligation. |
|
||||
| `infospace/assimilation/**` | 32 files, preserved source and research. | Out of scope — not live canon. |
|
||||
|
||||
## 3. Findings
|
||||
|
||||
- **F-1 — `itc-org:Authority` is a live concept that no `owned_concepts`
|
||||
declaration lists.** The boundary review's conflict check compared
|
||||
SecurityCanon's seven concepts against `owned_concepts` frontmatter, so it
|
||||
could not have seen it. There is no collision — SecurityCanon names nothing
|
||||
bare `Authority` — but three of its concepts sit directly adjacent to it.
|
||||
*Action taken:* `Authority` added to the existing InfoTechCanonOrganizationModel
|
||||
entry in `imports.json`; the file and its pinned hash are unchanged, so no new
|
||||
pin was needed.
|
||||
- **F-2 — CARING's `Authority` exposure mode is a third sense inside
|
||||
InfoTechCanon itself.** Sense A and sense B share a word across two live
|
||||
artifacts. Recorded as residual **R-3**; it is an InfoTechCanon-internal
|
||||
disambiguation and is not made here.
|
||||
- **F-3 — `Environment` is defined in both canons.** CARING §21.5 already lists
|
||||
development, test, staging, production, sandbox, demo and customer-managed
|
||||
instance as a scope dimension; the SecurityCanon dimension set defines
|
||||
`Environment` with DEVELOPMENT, TEST, STAGING, PRODUCTION, RECOVERY. This is
|
||||
one concept with two definitions — exactly what SECURITY-DEC-2026-003 forbids.
|
||||
*Action taken:* the placement table is corrected — InfoTechCanon owns
|
||||
`Environment` via CARING §21.5 and SecurityCanon imports it. The `RECOVERY`
|
||||
value has no CARING counterpart and is carried as an upstream value proposal,
|
||||
not a local redefinition.
|
||||
- **F-4 — `itc-ident:Realm` is adjacent to `AuthorityRealm`.** ITC-IDENT §2.12
|
||||
defines Realm as an issuer/administrative namespace modelled as a Scope
|
||||
specialization; AuthorityRealm names the realm within which authority is
|
||||
sovereign. Different questions, different names, no rename needed — but the
|
||||
disambiguation page owes them a line, as it already does for Operator/OPERATE.
|
||||
- **No collision** for `AuthorityContext`, `AuthorityProvenance`, `Activation`,
|
||||
`EvidenceBoundary` or `AccessSituation`. `EvidenceBoundary` and
|
||||
`AccessSituation` appear nowhere in the live corpus; `Activation` appears once
|
||||
and not as a concept; InfoTechCanon's provenance concept is `itc-core:ProvenanceRecord`,
|
||||
a Core-owned record of how an artifact came to be, not how authority was granted.
|
||||
|
||||
## 4. Consequences
|
||||
|
||||
Two amendments to SECURITY-DEC-2026-003 follow from this survey and are applied
|
||||
in `infospace/interfaces/concept-placement.md`: `Authority` becomes an eleventh
|
||||
declared import, and `Environment` moves from SecurityCanon-owned to imported.
|
||||
The amendment procedure the decision requires — add to `imports.json` with a
|
||||
pinned hash before use — was exercised as written.
|
||||
|
||||
Residual R-3 is added for InfoTechCanon. No InfoTechCanon file is changed by
|
||||
this survey.
|
||||
|
|
@ -45,6 +45,7 @@ owned:
|
|||
orthogonal_to: AuthMode
|
||||
|
||||
- id: Environment
|
||||
owner: InfoTechCanonCaringAccessGovernanceStandard
|
||||
definition: The environment in which the authority applies.
|
||||
values: [DEVELOPMENT, TEST, STAGING, PRODUCTION, RECOVERY]
|
||||
note: Especially significant for CONSTRUCT authority.
|
||||
|
|
|
|||
|
|
@ -5,37 +5,62 @@
|
|||
"source_repository": "info-tech-canon",
|
||||
"source_commit": "e1f98da015f32545254747c8e9f59b780c423d5b",
|
||||
"pinned_at": "2026-09-20",
|
||||
"note": "Concepts imported, not redefined. SHA-256 values are of the Git blob at source_commit.",
|
||||
"note": "Concepts imported, not redefined. SHA-256 values are of the Git blob at source_commit. Amended 2026-09-20 by SECURITY-WP-0001-T03: Authority and Environment added as declared imports.",
|
||||
"imports": [
|
||||
{
|
||||
"artifact": "InfoTechCanonCore",
|
||||
"path": "infospace/kernel/InfoTechCanonCore.md",
|
||||
"sha256": "74661caea603876f71b4258963bd11a338cba63ef57a00fb8c41e2e51d07742c",
|
||||
"concepts": ["Artifact", "Ownership", "Relationship"]
|
||||
"concepts": [
|
||||
"Artifact",
|
||||
"Ownership",
|
||||
"Relationship"
|
||||
]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonAccessControlModel",
|
||||
"path": "infospace/models/access-control/InfoTechCanonAccessControlModel.md",
|
||||
"sha256": "456e2534264b806098ac7be85d25e5e1cd1150b1e34934b07f46dabd909343bf",
|
||||
"concepts": ["Subject", "Principal", "Scope", "AccessOperations"]
|
||||
"concepts": [
|
||||
"Subject",
|
||||
"Principal",
|
||||
"Scope",
|
||||
"AccessOperations"
|
||||
]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonIdentityModel",
|
||||
"path": "infospace/models/identity/InfoTechCanonIdentityModel.md",
|
||||
"sha256": "20bc844d9de07041c40009cc5e3d6eeb42aeb7adcbb86b0194d4b2517aa23f32",
|
||||
"concepts": ["PrincipalType"]
|
||||
"concepts": [
|
||||
"PrincipalType"
|
||||
]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonOrganizationModel",
|
||||
"path": "infospace/models/organization/InfoTechCanonOrganizationModel.md",
|
||||
"sha256": "bdb1277e78c3a0802f8ea08e058be093452390e61ca0f7e979051e48680fe6c3",
|
||||
"concepts": ["Actor"]
|
||||
"concepts": [
|
||||
"Actor",
|
||||
"Authority"
|
||||
]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonPurposeDemandExtension",
|
||||
"path": "infospace/models/governance/InfoTechCanonPurposeDemandExtension.md",
|
||||
"sha256": "74637a7ed997691abf2c1370fffaa173010939a070d69853dc1f0a86cc8343bb",
|
||||
"concepts": ["Purpose"]
|
||||
"concepts": [
|
||||
"Purpose"
|
||||
]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonCaringAccessGovernanceStandard",
|
||||
"path": "infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md",
|
||||
"sha256": "7f751f9f3ec486d1e1a3d92501f6921df8a64f6ced1663f66a86fc281a4bce69",
|
||||
"concepts": [
|
||||
"Environment"
|
||||
],
|
||||
"note": "Environment is CARING section 21.5. The RECOVERY value is carried as an upstream value proposal, not a local redefinition."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ answers as a decision, since they bind both canons.
|
|||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T03
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472"
|
||||
```
|
||||
|
|
@ -302,3 +302,33 @@ remains an unaccepted InfoTechCanon proposal.
|
|||
Limits. This is an agent decision recorded on the SecurityCanon side and
|
||||
reflected in InfoTechCanon's accepted boundary; it is not separate human
|
||||
sign-off, and it records no consumer adoption or conformance claim.
|
||||
|
||||
## Result — 2026-09-20 (T03)
|
||||
|
||||
Survey at `infospace/mappings/infotechcanon-authority-survey.md`, against
|
||||
info-tech-canon `e1f98da`. Fifty-two InfoTechCanon files mention authority, of
|
||||
which twenty are live canon and thirty-two are preserved assimilation source.
|
||||
|
||||
The survey separates three senses of the word already in use: a right held by an
|
||||
actor (`itc-org:Authority`, ITC-ORG 10.17), an external body compelling
|
||||
disclosure (CARING 10.7 exposure mode), and the relationship in which authority
|
||||
is exercised (`sec-authority:AuthMode`). Sense C qualifies sense A and subsumes
|
||||
nothing.
|
||||
|
||||
Four findings. F-1: `itc-org:Authority` is a live concept that no
|
||||
`owned_concepts` declaration lists, so the boundary review's conflict check
|
||||
could not see it — no collision, but three SecurityCanon concepts sit adjacent
|
||||
to it, and it is now a declared import on the existing organization-model entry
|
||||
with its pinned hash unchanged. F-3: `Environment` was defined in both canons,
|
||||
which SECURITY-DEC-2026-003 forbids; InfoTechCanon owns it via CARING 21.5,
|
||||
SecurityCanon imports it, and the `RECOVERY` value is carried as an upstream
|
||||
value proposal. F-2 and F-4 need no change here: CARING's Authority exposure
|
||||
mode against `itc-org:Authority` becomes residual R-3, and `itc-ident:Realm`
|
||||
against `AuthorityRealm` owes the disambiguation page a line but no rename.
|
||||
AuthorityContext, AuthorityProvenance, Activation, EvidenceBoundary and
|
||||
AccessSituation collide with nothing in the live corpus.
|
||||
|
||||
The two amendments are applied to the placement table and to `imports.json`
|
||||
through the procedure SECURITY-DEC-2026-003 requires, taking the declared import
|
||||
list from ten concepts to twelve. No InfoTechCanon file is changed by this
|
||||
survey; R-3 is InfoTechCanon-internal work.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue