Adopt SEC-DSM 1.0 as the secrets-practice standard.

Insert DevOps Secrets Management Canon v1.0 unchanged, with a placement preface that keeps shared roots upstream. Publish it on the federation card.

Assistant: grok
Assistant-Session: 01a12ce1-7ded-7e03-a845-2ece8a573af4

README.md

@@ -36,17 +36,23 @@ Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
 
 ## Status
 
-Draft. The Mode of Authority vocabulary is published as a canon artifact with
-machine-readable modes and dimensions; the v0.1 research draft is retained in
-`research/` as provenance. Stable promotion needs reviewed mappings and concrete
-consumer evidence. See
+Draft vocabulary, stable secrets standard. The Mode of Authority vocabulary is
+published as a canon artifact with machine-readable modes and dimensions; the
+v0.1 research draft is retained in `research/` as provenance. Stable promotion
+of that vocabulary needs reviewed mappings and concrete consumer evidence. See
 [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md).
 
+The [DevOps Secrets Management Standard](infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md)
+(`SEC-DSM` 1.0.0) is the normative secrets-practice guide. Gate House teaches it;
+ops-mason and ops-warden follow it. See
+[SECURITY-WP-0002](workplans/SECURITY-WP-0002-devops-secrets-management-standard.md).
+
 ## Orientation
 
 | Start here | For |
 | --- | --- |
 | [Vocabulary card](docs/vocabulary-card.md) | the seven modes and the notation, on one page |
 | [Mode of Authority](infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md) | the canon artifact |
+| [DevOps Secrets Management Standard](infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md) | the secrets-practice standard (`SEC-DSM` v1.0) |
 | [Disambiguation](docs/disambiguation.md) | *operator* or `OPERATE`? role, plane, or mode? |
 | [Mapping to InfoTechCanon](infospace/mappings/mode-of-authority-to-infotechcanon.md) | how it relates to the access-control model and CARING |

SCOPE.md

@@ -10,6 +10,11 @@ mappings and orientation surfaces. SECURITY-WP-0001 is finished. The retained
 v0.1 research draft is historical, not the current orientation artifact. There
 is no service code; SEC-ADR-001 keeps validation in InfoTechCanon's service.
 
+It also publishes the DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) at
+`infospace/standards/devops-secrets-management/`. That standard states the
+normative secrets-management practice. It does not operate custody, issue
+credentials, or decide authorization. SECURITY-WP-0002 records the insertion.
+
 ## Ownership and boundaries
 
 Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and
@@ -26,8 +31,9 @@ Out of scope, with the owner named:
 - security architecture and standards of record for the estate — NetKingdom
 - authorization decisions — access-engine (runtime/product flex-auth)
 - login, OIDC, MFA — key-cape / Keycloak
-- credential lifecycle — secrets-engine over OpenBao custody; operational
-  routing and SSH certificates — ops-warden
+- credential custody and issuance — secrets-engine over OpenBao; operational
+  routing and SSH certificates — ops-warden. The practice those systems follow
+  is this canon's DevOps Secrets Management Standard; the operation stays theirs
 - adversarial evidence and findings practice — whitehat-security
 - shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
 - consumer runtime state, enforcement, observation, and adoption evidence — the consumers
@@ -42,6 +48,7 @@ The near-term deliverable is the architecture-layer vocabulary, not a migration.
 | Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` |
 | Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` |
 | Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` |
+| DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) | `SECURITY-WP-0002` |
 
 InfoTechCanon artifacts this canon **references rather than absorbs**:
 

decisions/decisions.md

@@ -39,3 +39,28 @@ updated: '2026-09-20T20:20:00.000000Z'
 state_hub_decision_id: "054e60cc-c8df-4335-83d4-28fd438bb0a8"
 ```
 
+## SECURITY-DEC-2026-004 — Adopt the DevOps Secrets Management Canon v1.0 as SEC-DSM
+
+```yaml
+id: SECURITY-DEC-2026-004
+kind: decision
+title: 'Adopt DevOps Secrets Management Canon v1.0 as the SEC-DSM standard'
+status: accepted
+created: '2026-10-11T00:00:00.000000Z'
+updated: '2026-10-11T00:00:00.000000Z'
+```
+
+The repository owner supplied `DevOpsSecretsManagementCanon-v1.0.md` and asked
+that it be inserted as a standard. The body is stored unchanged at
+`infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md`,
+with a placement preface. Source SHA-256
+`ded46fc4ee657503f949dd223cb47d425dfa765c76f593775da8d3fb7a63c30f`.
+
+The standard is the secrets best-practice guide. It does not take custody,
+issuance, authorization, route construction, or lane operation away from their
+owners. Section 4 terms that InfoTechCanon already owns are practice language,
+not a second definition. Gate House, ops-mason, and ops-warden adopt it as
+their guide for secrets practice. Gate House's Active Secrets Management Canon
+v0.3 remains the estate doctrine for invariants, operating modes, and assurance
+tests that this standard does not replace.
+

infospace/interfaces/README.md

@@ -11,11 +11,13 @@ under [accepted ADR-006](../../../the-custodian/canon/architecture/adr-006-canon
 - [commerce-canon interface](../../../commerce-canon/infospace/interfaces/federation.yaml)
 - [the-custodian interface](../../../the-custodian/canon/interfaces/federation.yaml)
 
-SecurityCanon exports one surface, `sec-authority`: the architecture-layer
+SecurityCanon exports two surfaces. `sec-authority` is the architecture-layer
 [Mode of Authority](../vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
-vocabulary. It imports shared roots from InfoTechCanon and redefines none of
+vocabulary. `sec-dsm` is the
+[DevOps Secrets Management Standard](../standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md).
+It imports shared roots from InfoTechCanon and redefines none of
 them; the [pinned manifest](../vocabulary/mode-of-authority/imports.json) records
-each source path and content hash at the declared commit.
+each vocabulary source path and content hash at the declared commit.
 
 Reciprocal navigation does not imply reciprocal semantic imports. InfoTechCanon
 retains the shared roots, CARING, the access-control model and the identity

infospace/interfaces/concept-placement.md

@@ -143,3 +143,13 @@ No concept is contested and no semantic disposition changes.
   and non-breaking; no SecurityCanon declaration changes. The blank cell in the
   mapping table stands — InfoTechCanon's access-control model still has no
   on-behalf-of relation.
+
+### Amendment — 2026-10-11, SEC-DSM insertion (SECURITY-DEC-2026-004)
+
+`sec-dsm:DevOpsSecretsManagementStandard` is a SecurityCanon-owned standard. It
+owns the secrets-practice requirements, the preference hierarchy, and the
+decision procedure. It does not add Principal, Authority, Capability, or Scope
+to SecurityCanon's owned concepts. The body's section 4 uses those words as
+practice language; the standard's preface records the reading. Secret and
+Credential remain practice terms until an upstream artifact owns them. No row
+in the placement table changes.

infospace/interfaces/federation.yaml

@@ -1,9 +1,9 @@
 id: security-canon/federation-interface
 title: SecurityCanon Federation Interface Card
 consumer: security-canon
-canon_surfaces: [sec-authority]
+canon_surfaces: [sec-authority, sec-dsm]
 status: draft
-version: 0.1.0
+version: 0.2.0
 owner: security-canon
 scope: >-
   SECURITY-WP-0001-T04 federation boundary. Publishes the architecture-layer
@@ -54,6 +54,23 @@ exports:
     availability: >-
       draft reference; adoption requires consumer review. No consumer adoption
       is recorded.
+  - artifact: sec-dsm
+    ledger_model: sec-dsm
+    kind: standard
+    path: infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
+    status: stable
+    version: 1.0.0
+    concepts:
+      - SecretsPreferenceHierarchy
+      - DynamicCredential
+      - ProducerCredential
+      - SecretsDecisionProcedure
+      - SecretsException
+    availability: >-
+      Stable practice standard. Gate House adopts it as the secrets best-practice
+      guide. ops-mason and ops-warden follow it. Custody and issuance stay with
+      secrets-engine; lane operation stays with ops-warden; route construction
+      stays with ops-mason.
 imports:
   - repository: info-tech-canon
     artifacts: [itc-core, itc-access, itc-ident, itc-org, itc-purposes]
@@ -62,8 +79,13 @@ imports:
     concepts: [Actor, Subject, Principal, Scope, AccessOperations, PrincipalType, Purpose]
 source_of_truth:
   vocabulary: security-canon
+  secrets_practice: security-canon (SEC-DSM)
   shared_roots: info-tech-canon
   implementation_layer: info-tech-canon (CARING)
+  estate_doctrine: gate-house
+  credential_custody: secrets-engine
+  route_construction: ops-mason
+  lane_operation: ops-warden
 mapping_rules:
   - Shared concepts retain their InfoTechCanon owner and are imported, never redefined.
   - Where concepts genuinely differ across layers, the names must visibly differ.
@@ -84,6 +106,10 @@ known_deviations:
     The G7 validator in prj-canon-federation pins card paths for info-tech-canon,
     commerce-canon and the-custodian only. Registering this card there is
     prj-canon-federation's change to make.
+  - >-
+    Section 4 of SEC-DSM uses Principal, Capability, and Authority as practice
+    language. Those concepts stay owned upstream. The standard's preface records
+    the reading. It does not add them to owned_concepts.
 expectations:
   - Review source changes and retain commit and content-hash provenance.
   - >-

infospace/standards/README.md

@@ -0,0 +1,9 @@
+# Standards
+
+Tier-3 artifacts. A standard states what a practice must do. It imports shared
+roots and does not redefine them. See
+[SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md).
+
+| Standard | Path | Status |
+| --- | --- | --- |
+| DevOps Secrets Management (`SEC-DSM`) | [SecurityCanonDevOpsSecretsManagementStandard.md](devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md) | stable 1.0.0 |

workplans/SECURITY-WP-0002-devops-secrets-management-standard.md

@@ -0,0 +1,47 @@
+---
+id: SECURITY-WP-0002
+type: workplan
+title: "Insert the DevOps Secrets Management Standard and point the staff at it"
+domain: infotech
+repo: security-canon
+status: finished
+owner: grok
+topic_slug: security-canon
+created: "2026-10-11"
+updated: "2026-10-11"
+---
+
+# DevOps Secrets Management Standard
+
+The repository owner supplied `DevOpsSecretsManagementCanon-v1.0.md` and asked
+that it be inserted as a standard, and that gate-house use it as the
+best-practice guide for secrets practice, with ops-mason and ops-warden guided
+by it. Recorded as SECURITY-DEC-2026-004.
+
+## Insert the standard
+
+```task
+id: SECURITY-WP-0002-T01
+status: done
+priority: high
+```
+
+Place the source, unchanged, at
+`infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md`
+with canon frontmatter and a placement preface. Publish it on the federation
+card as `sec-dsm` 1.0.0. Do not claim ownership of Principal, Authority,
+Capability, or Scope.
+
+## Point the staff at it
+
+```task
+id: SECURITY-WP-0002-T02
+status: done
+priority: high
+```
+
+Gate House names SEC-DSM as the secrets best-practice guide and keeps ASM v0.3
+for estate invariants, operating modes, and assurance tests. ops-mason's
+construction plans answer the standard's decision procedure before proposing a
+new credential. ops-warden's routing guide follows the same hierarchy and does
+not take custody of static secrets.