{"id":"security-and-governance-unified-across-all-topologies","text":"OpenShift enforces both software delivery governance (build→operator→console pipeline) and security enforcement (FIPS, TLS, SCCs, admission) as topology-invariant properties: whether the cluster is standalone HA, hosted control plane, or single-node edge, the same governance pipeline delivers software and the same security stack constrains it","truth_value":"IN","source":"","source_url":"","source_hash":"","justifications":[{"type":"SL","antecedents":["platform-delivers-software-under-governance-across-topologies","security-invariant-across-topology-variants"],"outlist":[],"label":"depth-7 — the two independent d6 invariants (delivery governance + security enforcement) both hold across topologies, establishing that topology only affects operations, never governance or security"}],"dependents":[],"metadata":{},"explanation":{"steps":[{"node":"security-and-governance-unified-across-all-topologies","truth_value":"IN","reason":"SL justification valid","antecedents":["platform-delivers-software-under-governance-across-topologies","security-invariant-across-topology-variants"],"label":"depth-7 — the two independent d6 invariants (delivery governance + security enforcement) both hold across topologies, establishing that topology only affects operations, never governance or security"},{"node":"platform-delivers-software-under-governance-across-topologies","truth_value":"IN","reason":"SL justification valid","antecedents":["platform-model-with-topology-variants","complete-software-delivery-from-build-to-console","platform-governance-from-identity-to-node"],"label":"depth-6 synthesis — the three pillars (topology model, delivery, governance) are not independent; delivery and governance must adapt to topology"},{"node":"platform-model-with-topology-variants","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-driven-immutable-platform-model","alternative-topologies-diverge-from-standard-operations"],"label":"depth-4 core model + depth-4 divergent topologies combine into a unified platform model with recognized variants (depth-5)"},{"node":"operator-driven-immutable-platform-model","truth_value":"IN","reason":"SL justification valid","antecedents":["immutable-nodes-with-singleton-operator-control","operator-delivery-through-console-integration"],"label":"depth-3 — both platform delivery and node management converge on operators as the universal control plane"},{"node":"immutable-nodes-with-singleton-operator-control","truth_value":"IN","reason":"SL justification valid","antecedents":["node-config-immutable-delivery-pipeline","singleton-resource-naming-convention","mco-rollout-process"],"label":"The MCO pipeline delivers changes to immutable nodes, and the singleton pattern ensures exactly one configuration authority — together they prevent configuration drift and split-brain"},{"node":"node-config-immutable-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","image-mirror-configuration-pipeline"],"label":"Both OS updates and registry configuration use the same MCO-mediated immutable delivery pattern"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"image-mirror-configuration-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["oc-mirror-generates-idms","mirror-config-applied-via-mco-registries-conf","icsp-deprecated-in-favor-of-idms"],"label":"End-to-end mirror configuration from generation to node application"},{"node":"oc-mirror-generates-idms","truth_value":"IN","reason":"premise"},{"node":"mirror-config-applied-via-mco-registries-conf","truth_value":"IN","reason":"premise"},{"node":"icsp-deprecated-in-favor-of-idms","truth_value":"IN","reason":"premise"},{"node":"singleton-resource-naming-convention","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","flowcollector-must-be-named-cluster","clusterautoscaler-singleton-named-default","storage-operator-singleton-named-cluster","powermonitor-must-be-named-power-monitor"],"label":"A recurring platform pattern worth capturing as a cross-cutting architectural constraint"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"flowcollector-must-be-named-cluster","truth_value":"IN","reason":"premise"},{"node":"clusterautoscaler-singleton-named-default","truth_value":"IN","reason":"premise"},{"node":"storage-operator-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"powermonitor-must-be-named-power-monitor","truth_value":"IN","reason":"premise"},{"node":"mco-rollout-process","truth_value":"IN","reason":"premise"},{"node":"operator-delivery-through-console-integration","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-catalog-to-deployment-pipeline","console-plugin-integration-model"],"label":"OLM is the shared dependency — it drives both operator deployment and console plugin registration, revealing OLM as the universal operator delivery bus"},{"node":"operator-catalog-to-deployment-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-modernizes-operator-catalog-format","olm-full-lifecycle-chain"],"label":"FBC defines the catalog format; OLM defines the installation chain — together they form the complete operator delivery pipeline"},{"node":"fbc-modernizes-operator-catalog-format","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-default-since-ocp-411-sqlite-deprecated","opm-validate-checks-catalog","fbc-skiprange-prunes-update-graph"],"label":"FBC as the complete modern catalog toolchain"},{"node":"fbc-default-since-ocp-411-sqlite-deprecated","truth_value":"IN","reason":"premise"},{"node":"opm-validate-checks-catalog","truth_value":"IN","reason":"premise"},{"node":"fbc-skiprange-prunes-update-graph","truth_value":"IN","reason":"premise"},{"node":"olm-full-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["olm-resource-chain","olm-subscription-tracks-channel","subscription-triggers-installplan-then-csv","installplan-required-spec-fields"],"label":"End-to-end OLM lifecycle with each resource's role clarified"},{"node":"olm-resource-chain","truth_value":"IN","reason":"premise"},{"node":"olm-subscription-tracks-channel","truth_value":"IN","reason":"premise"},{"node":"subscription-triggers-installplan-then-csv","truth_value":"IN","reason":"premise"},{"node":"installplan-required-spec-fields","truth_value":"IN","reason":"premise"},{"node":"console-plugin-integration-model","truth_value":"IN","reason":"SL justification valid","antecedents":["consoleplugin-backend-must-use-https","console-plugins-registered-via-olm","console-config-singleton-named-cluster","consoleplugin-compat-level-1"],"label":"Console plugin architecture with security, registration, and stability guarantees"},{"node":"consoleplugin-backend-must-use-https","truth_value":"IN","reason":"premise"},{"node":"console-plugins-registered-via-olm","truth_value":"IN","reason":"premise"},{"node":"console-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"alternative-topologies-diverge-from-standard-operations","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-requires-distinct-operational-playbook","edge-fleet-management-pipeline"],"label":"depth-3 — non-standard topologies share the property of diverging from the default operational model"},{"node":"hcp-requires-distinct-operational-playbook","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-diverges-from-standalone-machine-and-provisioning","hcp-clusterversion-ignored","hcp-web-console-limitations","hcp-force-rollout-restart-date-annotation"],"label":"Each HCP divergence point invalidates a standalone operational procedure — together they demonstrate that HCP needs its own runbook, not adaptations of standalone procedures"},{"node":"hcp-diverges-from-standalone-machine-and-provisioning","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-differs-from-standalone-in-machine-management","bare-metal-provisioning-architecture"],"label":"Machine lifecycle management is architecturally split between HCP and standalone patterns"},{"node":"hcp-differs-from-standalone-in-machine-management","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-nodepool-autorepair-spec","hcp-nodepool-upgrade-types-replace-inplace","hcp-nodepool-spec-config-vs-tuningconfig","hcp-managed-via-hypershift-operator"],"label":"HCP centralizes machine lifecycle into the NodePool abstraction"},{"node":"hcp-nodepool-autorepair-spec","truth_value":"IN","reason":"premise"},{"node":"hcp-nodepool-upgrade-types-replace-inplace","truth_value":"IN","reason":"premise"},{"node":"hcp-nodepool-spec-config-vs-tuningconfig","truth_value":"IN","reason":"premise"},{"node":"hcp-managed-via-hypershift-operator","truth_value":"IN","reason":"premise"},{"node":"bare-metal-provisioning-architecture","truth_value":"IN","reason":"SL justification valid","antecedents":["bare-metal-ipi-uses-bmc","bmh-rootdevicehints-model-vendor-substring","provisioning-consumed-by-cluster-baremetal-operator","provisioning-ip-inside-subnet-outside-dhcp"],"label":"Full bare metal provisioning stack from BMC through metal3"},{"node":"bare-metal-ipi-uses-bmc","truth_value":"IN","reason":"premise"},{"node":"bmh-rootdevicehints-model-vendor-substring","truth_value":"IN","reason":"premise"},{"node":"provisioning-consumed-by-cluster-baremetal-operator","truth_value":"IN","reason":"premise"},{"node":"provisioning-ip-inside-subnet-outside-dhcp","truth_value":"IN","reason":"premise"},{"node":"hcp-clusterversion-ignored","truth_value":"IN","reason":"premise"},{"node":"hcp-web-console-limitations","truth_value":"IN","reason":"premise"},{"node":"hcp-force-rollout-restart-date-annotation","truth_value":"IN","reason":"premise"},{"node":"edge-fleet-management-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["ztp-pattern-edge-fleet-management","talm-canary-failure-stops-update","sno-reduced-capability-profile","vdu-firmware-cstates-c0-c1-only"],"label":"ZTP provisioning, TALM updates, SNO topology, and vDU constraints form a complete edge lifecycle"},{"node":"ztp-pattern-edge-fleet-management","truth_value":"IN","reason":"premise"},{"node":"talm-canary-failure-stops-update","truth_value":"IN","reason":"premise"},{"node":"sno-reduced-capability-profile","truth_value":"IN","reason":"SL justification valid","antecedents":["ocpvirt-sno-no-live-migration-ha","sriov-sno-disable-drain","sno-worker-requires-ocp-411"],"label":"SNO trades operational features for minimal footprint"},{"node":"ocpvirt-sno-no-live-migration-ha","truth_value":"IN","reason":"premise"},{"node":"sriov-sno-disable-drain","truth_value":"IN","reason":"premise"},{"node":"sno-worker-requires-ocp-411","truth_value":"IN","reason":"premise"},{"node":"vdu-firmware-cstates-c0-c1-only","truth_value":"IN","reason":"premise"},{"node":"complete-software-delivery-from-build-to-console","truth_value":"IN","reason":"SL justification valid","antecedents":["image-supply-chain-end-to-end","operator-delivery-through-console-integration"],"label":"depth-3 image supply chain + depth-3 operator delivery pipeline converge at the console UI layer, revealing a unified delivery model"},{"node":"image-supply-chain-end-to-end","truth_value":"IN","reason":"SL justification valid","antecedents":["build-and-image-delivery-pipeline","operator-catalog-to-deployment-pipeline"],"label":"depth-3 — application and operator image delivery are structurally parallel managed pipelines"},{"node":"build-and-image-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["build-system-openshift-native-duality","imagestream-controlled-access-model","image-registry-external-access-model"],"label":"Build systems, ImageStream access control, and registry exposure form a complete image delivery chain"},{"node":"build-system-openshift-native-duality","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-two-build-systems-shipwright-buildconfig","ocp-buildconfigs-not-in-upstream-k8s","imagestream-buildconfig-openshift-native"],"label":"The build system is entirely OpenShift-native — both build mechanisms and their image output target (ImageStream) have no K8s equivalents"},{"node":"ocp-two-build-systems-shipwright-buildconfig","truth_value":"IN","reason":"premise"},{"node":"ocp-buildconfigs-not-in-upstream-k8s","truth_value":"IN","reason":"premise"},{"node":"imagestream-buildconfig-openshift-native","truth_value":"IN","reason":"premise"},{"node":"imagestream-controlled-access-model","truth_value":"IN","reason":"SL justification valid","antecedents":["image-objects-immutable-content-addressed","end-users-access-images-via-imagestreamtag-or-imagestreamimage","imagestream-pull-requires-get-layers-permission","ocp-imagestreammapping-privileged-only"],"label":"Four beliefs collectively enforce a layered access control model over image content"},{"node":"image-objects-immutable-content-addressed","truth_value":"IN","reason":"premise"},{"node":"end-users-access-images-via-imagestreamtag-or-imagestreamimage","truth_value":"IN","reason":"premise"},{"node":"imagestream-pull-requires-get-layers-permission","truth_value":"IN","reason":"premise"},{"node":"ocp-imagestreammapping-privileged-only","truth_value":"IN","reason":"premise"},{"node":"image-registry-external-access-model","truth_value":"IN","reason":"SL justification valid","antecedents":["image-registry-default-route-true-exposes-externally","default-route-uses-reencrypt","registry-credential-secret-name","image-registry-storage-backends"],"label":"Four beliefs that together describe how the registry is configured, secured, and exposed"},{"node":"image-registry-default-route-true-exposes-externally","truth_value":"IN","reason":"premise"},{"node":"default-route-uses-reencrypt","truth_value":"IN","reason":"premise"},{"node":"registry-credential-secret-name","truth_value":"IN","reason":"premise"},{"node":"image-registry-storage-backends","truth_value":"IN","reason":"premise"},{"node":"operator-catalog-to-deployment-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-modernizes-operator-catalog-format","olm-full-lifecycle-chain"],"label":"FBC defines the catalog format; OLM defines the installation chain — together they form the complete operator delivery pipeline"},{"node":"fbc-modernizes-operator-catalog-format","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-default-since-ocp-411-sqlite-deprecated","opm-validate-checks-catalog","fbc-skiprange-prunes-update-graph"],"label":"FBC as the complete modern catalog toolchain"},{"node":"fbc-default-since-ocp-411-sqlite-deprecated","truth_value":"IN","reason":"premise"},{"node":"opm-validate-checks-catalog","truth_value":"IN","reason":"premise"},{"node":"fbc-skiprange-prunes-update-graph","truth_value":"IN","reason":"premise"},{"node":"olm-full-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["olm-resource-chain","olm-subscription-tracks-channel","subscription-triggers-installplan-then-csv","installplan-required-spec-fields"],"label":"End-to-end OLM lifecycle with each resource's role clarified"},{"node":"olm-resource-chain","truth_value":"IN","reason":"premise"},{"node":"olm-subscription-tracks-channel","truth_value":"IN","reason":"premise"},{"node":"subscription-triggers-installplan-then-csv","truth_value":"IN","reason":"premise"},{"node":"installplan-required-spec-fields","truth_value":"IN","reason":"premise"},{"node":"operator-delivery-through-console-integration","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-catalog-to-deployment-pipeline","console-plugin-integration-model"],"label":"OLM is the shared dependency — it drives both operator deployment and console plugin registration, revealing OLM as the universal operator delivery bus"},{"node":"operator-catalog-to-deployment-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-modernizes-operator-catalog-format","olm-full-lifecycle-chain"],"label":"FBC defines the catalog format; OLM defines the installation chain — together they form the complete operator delivery pipeline"},{"node":"fbc-modernizes-operator-catalog-format","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-default-since-ocp-411-sqlite-deprecated","opm-validate-checks-catalog","fbc-skiprange-prunes-update-graph"],"label":"FBC as the complete modern catalog toolchain"},{"node":"fbc-default-since-ocp-411-sqlite-deprecated","truth_value":"IN","reason":"premise"},{"node":"opm-validate-checks-catalog","truth_value":"IN","reason":"premise"},{"node":"fbc-skiprange-prunes-update-graph","truth_value":"IN","reason":"premise"},{"node":"olm-full-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["olm-resource-chain","olm-subscription-tracks-channel","subscription-triggers-installplan-then-csv","installplan-required-spec-fields"],"label":"End-to-end OLM lifecycle with each resource's role clarified"},{"node":"olm-resource-chain","truth_value":"IN","reason":"premise"},{"node":"olm-subscription-tracks-channel","truth_value":"IN","reason":"premise"},{"node":"subscription-triggers-installplan-then-csv","truth_value":"IN","reason":"premise"},{"node":"installplan-required-spec-fields","truth_value":"IN","reason":"premise"},{"node":"console-plugin-integration-model","truth_value":"IN","reason":"SL justification valid","antecedents":["consoleplugin-backend-must-use-https","console-plugins-registered-via-olm","console-config-singleton-named-cluster","consoleplugin-compat-level-1"],"label":"Console plugin architecture with security, registration, and stability guarantees"},{"node":"consoleplugin-backend-must-use-https","truth_value":"IN","reason":"premise"},{"node":"console-plugins-registered-via-olm","truth_value":"IN","reason":"premise"},{"node":"console-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"platform-governance-from-identity-to-node","truth_value":"IN","reason":"SL justification valid","antecedents":["governance-spans-identity-resources-and-namespaces","immutable-nodes-with-singleton-operator-control"],"label":"depth-3 identity/resource governance + depth-3 node/singleton governance combine into a complete governance stack from user login to node OS"},{"node":"governance-spans-identity-resources-and-namespaces","truth_value":"IN","reason":"SL justification valid","antecedents":["authorization-and-resource-governance-model","openshift-identity-lifecycle-chain","project-self-provisioning-governance"],"label":"Depth-3 — the three governance layers (identity, resource, namespace) interact: project self-provisioning is constrained by both identity chain and resource quotas"},{"node":"authorization-and-resource-governance-model","truth_value":"IN","reason":"SL justification valid","antecedents":["openshift-extends-k8s-authorization-model","quota-forces-complete-resource-declarations"],"label":"Authorization gates who can act; quotas gate how much — both enforce strictness"},{"node":"openshift-extends-k8s-authorization-model","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-two-authorization-api-groups","openshift-has-own-authorization-api","scc-api-group-security-openshift","default-clusterroles-list"],"label":"Parallel authorization APIs reflect OpenShift's extension of Kubernetes security model"},{"node":"ocp-two-authorization-api-groups","truth_value":"IN","reason":"premise"},{"node":"openshift-has-own-authorization-api","truth_value":"IN","reason":"premise"},{"node":"scc-api-group-security-openshift","truth_value":"IN","reason":"premise"},{"node":"default-clusterroles-list","truth_value":"IN","reason":"premise"},{"node":"quota-forces-complete-resource-declarations","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-quota-forces-explicit-resource-specs","ocp-extended-resources-no-overcommit"],"label":"Quotas enforce exhaustive resource declarations with no implicit defaults"},{"node":"ocp-quota-forces-explicit-resource-specs","truth_value":"IN","reason":"premise"},{"node":"ocp-extended-resources-no-overcommit","truth_value":"IN","reason":"premise"},{"node":"openshift-identity-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","oauth-requires-integratedoauth-type","user-api-group-user-openshift-io","useridentitymapping-maps-user-to-identity","oauthclientauthorization-delete-revokes"],"label":"Five resources form a directed chain from authentication config to session lifecycle"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"oauth-requires-integratedoauth-type","truth_value":"IN","reason":"premise"},{"node":"user-api-group-user-openshift-io","truth_value":"IN","reason":"premise"},{"node":"useridentitymapping-maps-user-to-identity","truth_value":"IN","reason":"premise"},{"node":"oauthclientauthorization-delete-revokes","truth_value":"IN","reason":"premise"},{"node":"project-self-provisioning-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-admin-can-disable-self-provisioning","ocp-disable-self-provisioning-two-steps","project-request-template-in-openshift-config-ns","project-request-message-shown-when-denied"],"label":"Four beliefs describe the complete self-provisioning governance lifecycle"},{"node":"ocp-admin-can-disable-self-provisioning","truth_value":"IN","reason":"premise"},{"node":"ocp-disable-self-provisioning-two-steps","truth_value":"IN","reason":"premise"},{"node":"project-request-template-in-openshift-config-ns","truth_value":"IN","reason":"premise"},{"node":"project-request-message-shown-when-denied","truth_value":"IN","reason":"premise"},{"node":"immutable-nodes-with-singleton-operator-control","truth_value":"IN","reason":"SL justification valid","antecedents":["node-config-immutable-delivery-pipeline","singleton-resource-naming-convention","mco-rollout-process"],"label":"The MCO pipeline delivers changes to immutable nodes, and the singleton pattern ensures exactly one configuration authority — together they prevent configuration drift and split-brain"},{"node":"node-config-immutable-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","image-mirror-configuration-pipeline"],"label":"Both OS updates and registry configuration use the same MCO-mediated immutable delivery pattern"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"image-mirror-configuration-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["oc-mirror-generates-idms","mirror-config-applied-via-mco-registries-conf","icsp-deprecated-in-favor-of-idms"],"label":"End-to-end mirror configuration from generation to node application"},{"node":"oc-mirror-generates-idms","truth_value":"IN","reason":"premise"},{"node":"mirror-config-applied-via-mco-registries-conf","truth_value":"IN","reason":"premise"},{"node":"icsp-deprecated-in-favor-of-idms","truth_value":"IN","reason":"premise"},{"node":"singleton-resource-naming-convention","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","flowcollector-must-be-named-cluster","clusterautoscaler-singleton-named-default","storage-operator-singleton-named-cluster","powermonitor-must-be-named-power-monitor"],"label":"A recurring platform pattern worth capturing as a cross-cutting architectural constraint"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"flowcollector-must-be-named-cluster","truth_value":"IN","reason":"premise"},{"node":"clusterautoscaler-singleton-named-default","truth_value":"IN","reason":"premise"},{"node":"storage-operator-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"powermonitor-must-be-named-power-monitor","truth_value":"IN","reason":"premise"},{"node":"mco-rollout-process","truth_value":"IN","reason":"premise"},{"node":"security-invariant-across-topology-variants","truth_value":"IN","reason":"SL justification valid","antecedents":["security-and-governance-unified-enforcement-stack","platform-model-with-topology-variants"],"label":"Combines security stack (depth-5) with topology model (depth-5) — security is topology-independent"},{"node":"security-and-governance-unified-enforcement-stack","truth_value":"IN","reason":"SL justification valid","antecedents":["unified-security-from-install-through-api-governance","platform-governance-from-identity-to-node"],"label":"Depth-4 security enforcement and depth-4 governance enforcement are complementary views of one unified stack — combining reveals that every layer (identity, API, runtime, node) enforces both security and governance simultaneously."},{"node":"unified-security-from-install-through-api-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["api-governance-enforces-stability-and-immutability","security-enforced-at-install-runtime-and-api-boundary"],"label":"depth-3 API governance (stability+immutability) and depth-2 security enforcement (install+runtime+API) together show that security is not layered independently but forms a single enforcement chain where install-time decisions constrain what runtime and API governance must enforce"},{"node":"api-governance-enforces-stability-and-immutability","truth_value":"IN","reason":"SL justification valid","antecedents":["api-governance-spans-stability-and-admission","immutability-enforced-at-resource-and-platform-levels"],"label":"depth-2 API stability/admission + depth-2 immutability enforcement combine into a comprehensive API governance model"},{"node":"api-governance-spans-stability-and-admission","truth_value":"IN","reason":"SL justification valid","antecedents":["api-stability-tiered-guarantee-model","webhook-admission-enforcement-model"],"label":"depth-2 — API governance has both a temporal dimension (stability tiers) and a runtime dimension (admission enforcement)"},{"node":"api-stability-tiered-guarantee-model","truth_value":"IN","reason":"SL justification valid","antecedents":["compatibility-level-1-stable-12-months","compatibility-level-definitions","consoleplugin-compat-level-1","image-content-source-policy-v1alpha1-level4","api-tier3-default-for-unassigned-groups"],"label":"API consumers can assess migration risk by checking compatibility level"},{"node":"compatibility-level-1-stable-12-months","truth_value":"IN","reason":"premise"},{"node":"compatibility-level-definitions","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"image-content-source-policy-v1alpha1-level4","truth_value":"IN","reason":"premise"},{"node":"api-tier3-default-for-unassigned-groups","truth_value":"IN","reason":"premise"},{"node":"webhook-admission-enforcement-model","truth_value":"IN","reason":"SL justification valid","antecedents":["webhook-communication-requires-tls","webhook-max-timeout-13-seconds","webhook-never-invoked-on-own-kind","webhook-required-fields"],"label":"These four constraints collectively define the safety envelope for admission webhooks — TLS for integrity, timeout cap for availability, self-exclusion for stability, required fields for correctness"},{"node":"webhook-communication-requires-tls","truth_value":"IN","reason":"premise"},{"node":"webhook-max-timeout-13-seconds","truth_value":"IN","reason":"premise"},{"node":"webhook-never-invoked-on-own-kind","truth_value":"IN","reason":"premise"},{"node":"webhook-required-fields","truth_value":"IN","reason":"premise"},{"node":"immutability-enforced-at-resource-and-platform-levels","truth_value":"IN","reason":"SL justification valid","antecedents":["resource-field-immutability-pattern","install-time-irreversible-constraints"],"label":"depth-2 — immutability operates at both the resource field level and the cluster-wide level"},{"node":"resource-field-immutability-pattern","truth_value":"IN","reason":"SL justification valid","antecedents":["route-host-immutable","ingress-domain-field-immutable-unique","ingressclass-controller-immutable"],"label":"Three independent immutable-field constraints form a write-once identity pattern"},{"node":"route-host-immutable","truth_value":"IN","reason":"premise"},{"node":"ingress-domain-field-immutable-unique","truth_value":"IN","reason":"premise"},{"node":"ingressclass-controller-immutable","truth_value":"IN","reason":"premise"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"security-enforced-at-install-runtime-and-api-boundary","truth_value":"IN","reason":"SL justification valid","antecedents":["encryption-and-tls-infrastructure-model","webhook-admission-enforcement-model","install-time-irreversible-constraints"],"label":"depth-2 synthesis — three distinct enforcement points (install, runtime, API) form a unified security posture"},{"node":"encryption-and-tls-infrastructure-model","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-tls-four-profile-types","ipsec-cipher-aes-gcm-16-256","ipsec-pod-to-pod-transport-mode","ocp-410-san-certificate-requirement"],"label":"Four base beliefs about TLS/IPsec/certificates combine into a layered encryption model"},{"node":"ocp-tls-four-profile-types","truth_value":"IN","reason":"premise"},{"node":"ipsec-cipher-aes-gcm-16-256","truth_value":"IN","reason":"premise"},{"node":"ipsec-pod-to-pod-transport-mode","truth_value":"IN","reason":"premise"},{"node":"ocp-410-san-certificate-requirement","truth_value":"IN","reason":"premise"},{"node":"webhook-admission-enforcement-model","truth_value":"IN","reason":"SL justification valid","antecedents":["webhook-communication-requires-tls","webhook-max-timeout-13-seconds","webhook-never-invoked-on-own-kind","webhook-required-fields"],"label":"These four constraints collectively define the safety envelope for admission webhooks — TLS for integrity, timeout cap for availability, self-exclusion for stability, required fields for correctness"},{"node":"webhook-communication-requires-tls","truth_value":"IN","reason":"premise"},{"node":"webhook-max-timeout-13-seconds","truth_value":"IN","reason":"premise"},{"node":"webhook-never-invoked-on-own-kind","truth_value":"IN","reason":"premise"},{"node":"webhook-required-fields","truth_value":"IN","reason":"premise"},{"node":"install-time-irreversible-constraints","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-security-fips-install-time-only","cpu-partitioning-install-time-only","network-plugin-selected-at-install-time"],"label":"Three independent install-time-only constraints form a coherent class of irreversible cluster decisions"},{"node":"ocp-security-fips-install-time-only","truth_value":"IN","reason":"premise"},{"node":"cpu-partitioning-install-time-only","truth_value":"IN","reason":"premise"},{"node":"network-plugin-selected-at-install-time","truth_value":"IN","reason":"premise"},{"node":"platform-governance-from-identity-to-node","truth_value":"IN","reason":"SL justification valid","antecedents":["governance-spans-identity-resources-and-namespaces","immutable-nodes-with-singleton-operator-control"],"label":"depth-3 identity/resource governance + depth-3 node/singleton governance combine into a complete governance stack from user login to node OS"},{"node":"governance-spans-identity-resources-and-namespaces","truth_value":"IN","reason":"SL justification valid","antecedents":["authorization-and-resource-governance-model","openshift-identity-lifecycle-chain","project-self-provisioning-governance"],"label":"Depth-3 — the three governance layers (identity, resource, namespace) interact: project self-provisioning is constrained by both identity chain and resource quotas"},{"node":"authorization-and-resource-governance-model","truth_value":"IN","reason":"SL justification valid","antecedents":["openshift-extends-k8s-authorization-model","quota-forces-complete-resource-declarations"],"label":"Authorization gates who can act; quotas gate how much — both enforce strictness"},{"node":"openshift-extends-k8s-authorization-model","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-two-authorization-api-groups","openshift-has-own-authorization-api","scc-api-group-security-openshift","default-clusterroles-list"],"label":"Parallel authorization APIs reflect OpenShift's extension of Kubernetes security model"},{"node":"ocp-two-authorization-api-groups","truth_value":"IN","reason":"premise"},{"node":"openshift-has-own-authorization-api","truth_value":"IN","reason":"premise"},{"node":"scc-api-group-security-openshift","truth_value":"IN","reason":"premise"},{"node":"default-clusterroles-list","truth_value":"IN","reason":"premise"},{"node":"quota-forces-complete-resource-declarations","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-quota-forces-explicit-resource-specs","ocp-extended-resources-no-overcommit"],"label":"Quotas enforce exhaustive resource declarations with no implicit defaults"},{"node":"ocp-quota-forces-explicit-resource-specs","truth_value":"IN","reason":"premise"},{"node":"ocp-extended-resources-no-overcommit","truth_value":"IN","reason":"premise"},{"node":"openshift-identity-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","oauth-requires-integratedoauth-type","user-api-group-user-openshift-io","useridentitymapping-maps-user-to-identity","oauthclientauthorization-delete-revokes"],"label":"Five resources form a directed chain from authentication config to session lifecycle"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"oauth-requires-integratedoauth-type","truth_value":"IN","reason":"premise"},{"node":"user-api-group-user-openshift-io","truth_value":"IN","reason":"premise"},{"node":"useridentitymapping-maps-user-to-identity","truth_value":"IN","reason":"premise"},{"node":"oauthclientauthorization-delete-revokes","truth_value":"IN","reason":"premise"},{"node":"project-self-provisioning-governance","truth_value":"IN","reason":"SL justification valid","antecedents":["ocp-admin-can-disable-self-provisioning","ocp-disable-self-provisioning-two-steps","project-request-template-in-openshift-config-ns","project-request-message-shown-when-denied"],"label":"Four beliefs describe the complete self-provisioning governance lifecycle"},{"node":"ocp-admin-can-disable-self-provisioning","truth_value":"IN","reason":"premise"},{"node":"ocp-disable-self-provisioning-two-steps","truth_value":"IN","reason":"premise"},{"node":"project-request-template-in-openshift-config-ns","truth_value":"IN","reason":"premise"},{"node":"project-request-message-shown-when-denied","truth_value":"IN","reason":"premise"},{"node":"immutable-nodes-with-singleton-operator-control","truth_value":"IN","reason":"SL justification valid","antecedents":["node-config-immutable-delivery-pipeline","singleton-resource-naming-convention","mco-rollout-process"],"label":"The MCO pipeline delivers changes to immutable nodes, and the singleton pattern ensures exactly one configuration authority — together they prevent configuration drift and split-brain"},{"node":"node-config-immutable-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","image-mirror-configuration-pipeline"],"label":"Both OS updates and registry configuration use the same MCO-mediated immutable delivery pattern"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"image-mirror-configuration-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["oc-mirror-generates-idms","mirror-config-applied-via-mco-registries-conf","icsp-deprecated-in-favor-of-idms"],"label":"End-to-end mirror configuration from generation to node application"},{"node":"oc-mirror-generates-idms","truth_value":"IN","reason":"premise"},{"node":"mirror-config-applied-via-mco-registries-conf","truth_value":"IN","reason":"premise"},{"node":"icsp-deprecated-in-favor-of-idms","truth_value":"IN","reason":"premise"},{"node":"singleton-resource-naming-convention","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","flowcollector-must-be-named-cluster","clusterautoscaler-singleton-named-default","storage-operator-singleton-named-cluster","powermonitor-must-be-named-power-monitor"],"label":"A recurring platform pattern worth capturing as a cross-cutting architectural constraint"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"flowcollector-must-be-named-cluster","truth_value":"IN","reason":"premise"},{"node":"clusterautoscaler-singleton-named-default","truth_value":"IN","reason":"premise"},{"node":"storage-operator-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"powermonitor-must-be-named-power-monitor","truth_value":"IN","reason":"premise"},{"node":"mco-rollout-process","truth_value":"IN","reason":"premise"},{"node":"platform-model-with-topology-variants","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-driven-immutable-platform-model","alternative-topologies-diverge-from-standard-operations"],"label":"depth-4 core model + depth-4 divergent topologies combine into a unified platform model with recognized variants (depth-5)"},{"node":"operator-driven-immutable-platform-model","truth_value":"IN","reason":"SL justification valid","antecedents":["immutable-nodes-with-singleton-operator-control","operator-delivery-through-console-integration"],"label":"depth-3 — both platform delivery and node management converge on operators as the universal control plane"},{"node":"immutable-nodes-with-singleton-operator-control","truth_value":"IN","reason":"SL justification valid","antecedents":["node-config-immutable-delivery-pipeline","singleton-resource-naming-convention","mco-rollout-process"],"label":"The MCO pipeline delivers changes to immutable nodes, and the singleton pattern ensures exactly one configuration authority — together they prevent configuration drift and split-brain"},{"node":"node-config-immutable-delivery-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-immutable-update-model","image-mirror-configuration-pipeline"],"label":"Both OS updates and registry configuration use the same MCO-mediated immutable delivery pattern"},{"node":"rhcos-immutable-update-model","truth_value":"IN","reason":"SL justification valid","antecedents":["rhcos-nodes-immutable","rhcos-rpm-ostree-updates","image-layering-verify-rpm-ostree-status"],"label":"Three facets of the same immutable-OS operational model"},{"node":"rhcos-nodes-immutable","truth_value":"IN","reason":"premise"},{"node":"rhcos-rpm-ostree-updates","truth_value":"IN","reason":"premise"},{"node":"image-layering-verify-rpm-ostree-status","truth_value":"IN","reason":"premise"},{"node":"image-mirror-configuration-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["oc-mirror-generates-idms","mirror-config-applied-via-mco-registries-conf","icsp-deprecated-in-favor-of-idms"],"label":"End-to-end mirror configuration from generation to node application"},{"node":"oc-mirror-generates-idms","truth_value":"IN","reason":"premise"},{"node":"mirror-config-applied-via-mco-registries-conf","truth_value":"IN","reason":"premise"},{"node":"icsp-deprecated-in-favor-of-idms","truth_value":"IN","reason":"premise"},{"node":"singleton-resource-naming-convention","truth_value":"IN","reason":"SL justification valid","antecedents":["oauth-config-singleton-named-cluster","flowcollector-must-be-named-cluster","clusterautoscaler-singleton-named-default","storage-operator-singleton-named-cluster","powermonitor-must-be-named-power-monitor"],"label":"A recurring platform pattern worth capturing as a cross-cutting architectural constraint"},{"node":"oauth-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"flowcollector-must-be-named-cluster","truth_value":"IN","reason":"premise"},{"node":"clusterautoscaler-singleton-named-default","truth_value":"IN","reason":"premise"},{"node":"storage-operator-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"powermonitor-must-be-named-power-monitor","truth_value":"IN","reason":"premise"},{"node":"mco-rollout-process","truth_value":"IN","reason":"premise"},{"node":"operator-delivery-through-console-integration","truth_value":"IN","reason":"SL justification valid","antecedents":["operator-catalog-to-deployment-pipeline","console-plugin-integration-model"],"label":"OLM is the shared dependency — it drives both operator deployment and console plugin registration, revealing OLM as the universal operator delivery bus"},{"node":"operator-catalog-to-deployment-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-modernizes-operator-catalog-format","olm-full-lifecycle-chain"],"label":"FBC defines the catalog format; OLM defines the installation chain — together they form the complete operator delivery pipeline"},{"node":"fbc-modernizes-operator-catalog-format","truth_value":"IN","reason":"SL justification valid","antecedents":["fbc-default-since-ocp-411-sqlite-deprecated","opm-validate-checks-catalog","fbc-skiprange-prunes-update-graph"],"label":"FBC as the complete modern catalog toolchain"},{"node":"fbc-default-since-ocp-411-sqlite-deprecated","truth_value":"IN","reason":"premise"},{"node":"opm-validate-checks-catalog","truth_value":"IN","reason":"premise"},{"node":"fbc-skiprange-prunes-update-graph","truth_value":"IN","reason":"premise"},{"node":"olm-full-lifecycle-chain","truth_value":"IN","reason":"SL justification valid","antecedents":["olm-resource-chain","olm-subscription-tracks-channel","subscription-triggers-installplan-then-csv","installplan-required-spec-fields"],"label":"End-to-end OLM lifecycle with each resource's role clarified"},{"node":"olm-resource-chain","truth_value":"IN","reason":"premise"},{"node":"olm-subscription-tracks-channel","truth_value":"IN","reason":"premise"},{"node":"subscription-triggers-installplan-then-csv","truth_value":"IN","reason":"premise"},{"node":"installplan-required-spec-fields","truth_value":"IN","reason":"premise"},{"node":"console-plugin-integration-model","truth_value":"IN","reason":"SL justification valid","antecedents":["consoleplugin-backend-must-use-https","console-plugins-registered-via-olm","console-config-singleton-named-cluster","consoleplugin-compat-level-1"],"label":"Console plugin architecture with security, registration, and stability guarantees"},{"node":"consoleplugin-backend-must-use-https","truth_value":"IN","reason":"premise"},{"node":"console-plugins-registered-via-olm","truth_value":"IN","reason":"premise"},{"node":"console-config-singleton-named-cluster","truth_value":"IN","reason":"premise"},{"node":"consoleplugin-compat-level-1","truth_value":"IN","reason":"premise"},{"node":"alternative-topologies-diverge-from-standard-operations","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-requires-distinct-operational-playbook","edge-fleet-management-pipeline"],"label":"depth-3 — non-standard topologies share the property of diverging from the default operational model"},{"node":"hcp-requires-distinct-operational-playbook","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-diverges-from-standalone-machine-and-provisioning","hcp-clusterversion-ignored","hcp-web-console-limitations","hcp-force-rollout-restart-date-annotation"],"label":"Each HCP divergence point invalidates a standalone operational procedure — together they demonstrate that HCP needs its own runbook, not adaptations of standalone procedures"},{"node":"hcp-diverges-from-standalone-machine-and-provisioning","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-differs-from-standalone-in-machine-management","bare-metal-provisioning-architecture"],"label":"Machine lifecycle management is architecturally split between HCP and standalone patterns"},{"node":"hcp-differs-from-standalone-in-machine-management","truth_value":"IN","reason":"SL justification valid","antecedents":["hcp-nodepool-autorepair-spec","hcp-nodepool-upgrade-types-replace-inplace","hcp-nodepool-spec-config-vs-tuningconfig","hcp-managed-via-hypershift-operator"],"label":"HCP centralizes machine lifecycle into the NodePool abstraction"},{"node":"hcp-nodepool-autorepair-spec","truth_value":"IN","reason":"premise"},{"node":"hcp-nodepool-upgrade-types-replace-inplace","truth_value":"IN","reason":"premise"},{"node":"hcp-nodepool-spec-config-vs-tuningconfig","truth_value":"IN","reason":"premise"},{"node":"hcp-managed-via-hypershift-operator","truth_value":"IN","reason":"premise"},{"node":"bare-metal-provisioning-architecture","truth_value":"IN","reason":"SL justification valid","antecedents":["bare-metal-ipi-uses-bmc","bmh-rootdevicehints-model-vendor-substring","provisioning-consumed-by-cluster-baremetal-operator","provisioning-ip-inside-subnet-outside-dhcp"],"label":"Full bare metal provisioning stack from BMC through metal3"},{"node":"bare-metal-ipi-uses-bmc","truth_value":"IN","reason":"premise"},{"node":"bmh-rootdevicehints-model-vendor-substring","truth_value":"IN","reason":"premise"},{"node":"provisioning-consumed-by-cluster-baremetal-operator","truth_value":"IN","reason":"premise"},{"node":"provisioning-ip-inside-subnet-outside-dhcp","truth_value":"IN","reason":"premise"},{"node":"hcp-clusterversion-ignored","truth_value":"IN","reason":"premise"},{"node":"hcp-web-console-limitations","truth_value":"IN","reason":"premise"},{"node":"hcp-force-rollout-restart-date-annotation","truth_value":"IN","reason":"premise"},{"node":"edge-fleet-management-pipeline","truth_value":"IN","reason":"SL justification valid","antecedents":["ztp-pattern-edge-fleet-management","talm-canary-failure-stops-update","sno-reduced-capability-profile","vdu-firmware-cstates-c0-c1-only"],"label":"ZTP provisioning, TALM updates, SNO topology, and vDU constraints form a complete edge lifecycle"},{"node":"ztp-pattern-edge-fleet-management","truth_value":"IN","reason":"premise"},{"node":"talm-canary-failure-stops-update","truth_value":"IN","reason":"premise"},{"node":"sno-reduced-capability-profile","truth_value":"IN","reason":"SL justification valid","antecedents":["ocpvirt-sno-no-live-migration-ha","sriov-sno-disable-drain","sno-worker-requires-ocp-411"],"label":"SNO trades operational features for minimal footprint"},{"node":"ocpvirt-sno-no-live-migration-ha","truth_value":"IN","reason":"premise"},{"node":"sriov-sno-disable-drain","truth_value":"IN","reason":"premise"},{"node":"sno-worker-requires-ocp-411","truth_value":"IN","reason":"premise"},{"node":"vdu-firmware-cstates-c0-c1-only","truth_value":"IN","reason":"premise"}]}}