diff --git a/infospace/interfaces/concept-placement.md b/infospace/interfaces/concept-placement.md index ba23b5a..04bdacb 100644 --- a/infospace/interfaces/concept-placement.md +++ b/infospace/interfaces/concept-placement.md @@ -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. diff --git a/infospace/mappings/infotechcanon-authority-survey.md b/infospace/mappings/infotechcanon-authority-survey.md new file mode 100644 index 0000000..199d797 --- /dev/null +++ b/infospace/mappings/infotechcanon-authority-survey.md @@ -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. diff --git a/infospace/vocabulary/mode-of-authority/dimensions.yaml b/infospace/vocabulary/mode-of-authority/dimensions.yaml index 19e78c7..3b247fe 100644 --- a/infospace/vocabulary/mode-of-authority/dimensions.yaml +++ b/infospace/vocabulary/mode-of-authority/dimensions.yaml @@ -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. diff --git a/infospace/vocabulary/mode-of-authority/imports.json b/infospace/vocabulary/mode-of-authority/imports.json index 23e193c..2e12f2f 100644 --- a/infospace/vocabulary/mode-of-authority/imports.json +++ b/infospace/vocabulary/mode-of-authority/imports.json @@ -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." } ] } diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md index 08059c2..8c47799 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md @@ -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.