# Hybrid enterprise control plane

**Cloud Waypoint should expand the picture beyond GSS with an indicative enterprise systems/service-management umbrella.** Cloud/GSS services, retained enterprise services and optional third-party overlays can each roll up into common service definitions, governance conventions, observability and evidence while retaining their own execution authority. Its contribution is showing those relationships, not designing solutions for enterprise legacy. Retained on-premises services—including Solaris/SPARC—can be represented alongside cloud-native services through their existing ownership, change and evidence arrangements. Cloud/GSS services can benefit from integrated automation and frequent delivery; retained services with fewer or scheduled changes might need no additional automation. This does not make every cloud operation easier or every legacy operation deficient. The reference extends the GSS operating discussion without enlarging any authorization boundary. **Common intake/governance does not imply centralized execution authority, unified privileged access or a shared approval plane.** It belongs in optional technical reference material supporting the existing four reports, not a client solution, product rebuild or fifth core deliverable. Workflow examples illustrate responsibility seams and evidence handling, not a standard operating procedure. The accompanying local explorer lets Charlie select conceptual reference blocks and inspect their roll-up relationships; it does not configure solutions. Any later implementation would require configuration, compatibility validation and program authority.

Research basis: all four completed notes—*north-stars*, *oem-cloud-patterns*, *legacy-to-automation* and *report-reference-design*—accessed by their researchers on **3 October 2026**, plus the earlier *Client contextual reporting review* as reporting background. This synthesis performs no new live research. Dates and verification limits are inherited from those notes; “current” is not independently revalidated. Architecture, archetypes, walkthroughs and recommendations below are **our inference**, not observed client operations or official program designs.

## Shared governance joins distinct operational boundaries

“Hybrid enterprise control plane” is **our architectural framing** for service intake, decision routing, configuration automation, legacy adapters, telemetry and operational assurance across an enterprise. Actual cloud, network and Kubernetes control planes remain distinct technical systems. The catalog expresses intent; workflow records decisions; an executor invokes privileged interfaces; observation establishes what happened. None substitutes for another. Kubernetes explicitly identifies its API server, state store, scheduler and controllers; that definition should not be stretched to make an enterprise service desk a Kubernetes-style controller. ([Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/))

DISA terminology needs particular care. The DISN Connection Process Guide uses **“externally connected CSO management plane”** in its Internal Cloud Access Point definition. A historical SCCA overview identifies TCCM as a **Privileged Access Management Service**, including credentials, sessions and bastion access. These sources describe narrower management and privileged-access functions; they do not establish an official “service management control plane” term. Current SCCA functional requirements were CAC-gated; their exact plane definitions and requirement identifiers were not retrieved. The guide’s revision history includes March 2023; later overall currency was not independently established. The SCCA overview is dated May 2018 and is historical program evidence. ([DISN guide, glossary and C.7](https://dl.dod.cyber.mil/wp-content/uploads/connect/CPG/ConnProcGuide.html); [SCCA overview, slides 2–7](https://www.disa.mil/-/media/Files/DISA/News/Events/Symposium/Secure-Cloud-Computing-Architecture-May-2018.pdf))

A common front door does not absorb connected workloads into a GSS authorization boundary, confer common-control inheritance, approve interconnections, or admit data. FedCiv, DoD and IC applicability must remain distinct. NIST control selection and tailoring depend on the applicable regime; an IC element’s requirements cannot be inferred from a DoD example. ICD 503 distinguishes authorization reciprocity from data reciprocity and assigns authorization to designated officials. The retrieved replacement text supersedes the July 2015 directive, but its signature/effective date was not verified. ([NIST SP 800-53, CA-6](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf); [ICD 503, C and D](https://www.dni.gov/files/documents/ICD/ICD-503.pdf))

| Evidence class | What it supports | What it cannot establish |
| --- | --- | --- |
| **Normative, conditionally applicable** | Selected NIST controls; DISN connection procedures in scope; ICD 503 within its applicability | A universal stack, selected baseline or client approval |
| **Product capability / implementation guidance** | Documented interfaces, behaviors, support restrictions and architecture examples | Government admission, entitlement, interoperability or feature parity |
| **Program description** | What a named program publicly describes, with source date and scope | Another tenant’s service coverage or present authorization |
| **Our inference** | Proposed connections, archetypes, responsibilities and consultative interpretation | An implemented integration, assigned owner or accepted client finding |

The useful common framework is therefore an **interface agreement**, not a universal controller. Each connection needs a stable service identifier, resource identifiers, bounded execution identities, permitted operation, responsible handoff, decision reference, evidence receipt and failure disposition. Here, service identity means the stable identifier for the offered/operated service, not the privileged identity used to execute changes. “Plug-and-play” in the explorer means rearrangeable conceptual roles. It does not mean installed connectors, schema compatibility or automatic trust. Visibility and execution permission must remain separate, including when one product spans several layers.

## Enterprise roll-up preserves different operating rhythms

Solaris 11.4 documents native diagnostic, isolation, repair and notification behaviors that can support lights-out operations. Oracle’s Solaris 11.4 fault-management documentation describes diagnosis, isolation and repair, integrates the fault manager with SMF, and documents SMTP/SNMP notifications. Its audit guidance separately covers audit-service health, active plugins and administrative rights. These are November 2020, version-specific capabilities, not evidence of a supported target estate today. A repaired fault is not application acceptance, and a successful orchestration job does not prove auditing worked. ([Oracle FMA, pp. 13–20](https://docs.oracle.com/cd/E37838_01/pdf/E61036.pdf); [Oracle audit troubleshooting](https://docs.oracle.com/cd/E37838_01/html/E61027/audittask-84.html))

The reference should first show how existing native supervision and permitted observations roll up into enterprise service records and evidence. A procedure wrapper is only an optional illustration where demonstrated change demand warrants one, subject to exact target support, interpreter/collection behavior and estate-specific recovery validation. Fewer or scheduled legacy changes can remain entirely within existing operator procedures; no adapter implementation or replacement is recommended here. Validate actual SPARC hardware/firmware, Solaris release/SRU, zones, libraries, interpreters, application certification and recovery. Red Hat separates Ansible platform, execution environment, interpreter, collection and target support; Solaris was not explicitly named in the inspected other-OS table. That neither proves automation impossible nor establishes supported Solaris modules. No Solaris/SPARC OpenTelemetry compatibility was verified. ([Red Hat support policy, tables 1.2–1.4](https://access.redhat.com/support/policy/updates/ansible-automation-platform))

ServiceNow or Jira can each provide intake/record functions in different ways, but the cited sources do not establish equivalent governance, gating or deployment parity. ServiceNow catalog criteria do not govern every access path; item visibility is insufficient execution authorization. Its DevOps change flows support manual decisions and callbacks to orchestration. IRE identifies configuration items and governs authoritative attribute writers; it does not independently establish factual truth. Jira Service Management Cloud links Assets objects and changes, but that source establishes neither equivalent gating nor Data Center parity. These are optional implementations requiring configuration and entitlement checks. ([Catalog criteria](https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/t_AppUserCritItemsCat.html); [change flows](https://www.servicenow.com/docs/r/it-service-management/devops-change-velocity/using-dev-ops-model-change-flow.html); [IRE](https://www.servicenow.com/docs/r/servicenow-platform/configuration-management-database-cmdb/c_CompsandProcessIDandReconcil.html); [Jira Assets](https://support.atlassian.com/jira-service-management-cloud/docs/connect-assets-schemas-with-changes/))

| Record | Authoritative question to designate | Required distinction |
| --- | --- | --- |
| Catalog / service record | What is offered, supported and owned? | Availability of an item versus entitlement to execute |
| Change / decision | Who approved which targets, window and procedure? | Request approval, change approval, acceptance and AO authorization |
| Versioned IaC / configuration | What state was intended and reviewed? | Desired state versus observed reality |
| CMDB / discovery | Which service and resource identities, relationships and observations apply? | Planned versus observed attributes; conflicting writers and timestamps |
| Job / native audit | What action was requested/recorded to have run, as whom, against which targets? | Dispatch/API success versus completed per-target execution |
| Health / recovery evidence | Did the service work and recover within the observed scope? | Infrastructure restoration versus application/data validation |

Cloud-native mechanisms offer useful but bounded contrasts. AWS LZA provides configuration-driven foundations and explicitly disclaims making an organization compliant. Azure landing-zone deployment assets require sovereign-cloud adaptation; standard deployments were documented as unsupported out of the box there. Google’s foundation blueprint combines preventive and detective controls; OCI supplies compartment ownership and modular Terraform foundations. Neither establishes four-cloud government parity. ([AWS LZA](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-architecture-dod/lza-overview.html); [Azure deployment](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy); [Google blueprint](https://docs.cloud.google.com/architecture/blueprints/security-foundations); [OCI foundation](https://docs.oracle.com/en-us/iaas/Content/cloud-adoption-framework/oci-core-landing-zone.htm))

AWS Systems Manager documents hybrid managed nodes, IAM, CloudTrail and execution notifications. GovCloud documentation excludes Change Manager and Incident Manager and limits other functions; commercial recipes cannot simply be copied. Azure Machine Configuration distinguishes audit, apply-and-monitor and automatic correction on supported machines. Arc’s overview records retirement of an indirectly connected mode in September 2025; that is not a universal conclusion about every Arc product or offline scenario. CloudFormation drift also excludes unsupported properties/resources; even an `IN_SYNC` result can lack meaningful coverage. ([SSM hybrid](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-hybrid-multicloud.html); [GovCloud limits](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-ssm.html); [Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview/01-overview-concepts); [Arc](https://learn.microsoft.com/en-us/azure/azure-arc/overview); [drift scope](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html))

GitHub Actions is another **conditional execution example**, not adoption of a repository pipeline. Environments support reviewers and branch restrictions, with configurable self-review prevention and default administrator bypass. OIDC issues credentials according to provider trust; it is not human change approval. Attestations require verification and do not guarantee security. A self-hosted runner does not establish an approved control/evidence boundary. Azure Pipelines separately documents externally owned checks and a ServiceNow extension; government availability remains unverified. ([GitHub environments](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments); [OIDC](https://docs.github.com/en/actions/concepts/security/openid-connect); [attestations](https://docs.github.com/en/actions/concepts/security/artifact-attestations); [Azure checks](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops))

## Four archetypes make shared governance and different execution visible

These small **analyst examples** describe useful operational arrangements, not complete architectures or mutually exclusive product bundles. The explorer highlights applicable logical connections and explains configuration gaps. Its choices do not calculate readiness, select vendors or authorize deployment.

| Archetype | Operational arrangement and handoff | Evidence / countercase |
| --- | --- | --- |
| **A · Shared foundation** | Catalog request → delegated review → provider-specific IaC → platform-to-workload handover. Platform owner maintains shared services; workload owner retains application duties. | Link template revision, actual resource IDs, observed baseline and handover. Retain an existing supported foundation where it meets demand. AWS/Azure examples above support the mechanism. |
| **B · Federated hybrid** | Common service taxonomy and governance conventions; distinct cloud execution and retained Solaris runbooks/adapters. Service owner coordinates platform and supplier operators. | Correlate change, native fault/audit, discovery and incident records. An unreachable adapter remains unknown. Improve a failed handoff before replacing tools. Oracle/SSM examples support separate mechanisms, not their compatibility. |
| **C · Governed delivery** | Reviewed source/artifact → approved deployment → observed runtime → corrective change. Kubernetes/GitOps is optional; VM delivery can follow the same governance logic with different tooling and state/recovery mechanics. | Preserve digest, provenance, gate decision and deployed-state observation. A Git revert does not restore database state. Retain effective existing delivery. [Argo CD](https://argo-cd.readthedocs.io/en/stable/) documents manual/automatic reconciliation. |
| **D · Separate enclaves** | Local catalog, approval, executor and evidence in each boundary; separately approved artifact/metadata exchange. Receiving operator verifies before local promotion. | Transfer receipt, receiving verification and local decision remain distinct. No cross-domain product or transfer permission is selected. Use only for evidenced isolation needs; [ICD 503](https://www.dni.gov/files/documents/ICD/ICD-503.pdf) does not equate data and authorization reciprocity. |

### A shared change pattern can branch into two execution paths

The following fictional flow is an optional illustration of enterprise roll-up, not an engineering plan, executable runbook or recommendation to automate retained systems. Assume a retained Solaris application service needs a reviewed configuration update, while a cloud application needs a versioned release. They share decision and evidence conventions; they do not share an atomic transaction, rollback mechanism or automatically permitted connection.

| Stage / handoff | Retained Solaris change | Cloud-native change | Failure branch |
| --- | --- | --- | --- |
| Request → service owner | Identify service, host/zone, dependency and supported procedure | Identify workload, environment, artifact and support owner | Missing scope or catalog coverage → return or explicit exception |
| Review → change delegate | Verify maintenance window, privileges, native prechecks and recovery | Review IaC plan/artifact, policy, deployment strategy and dependencies | Missing/expired delegation or changed targets → hold dispatch |
| Authorize → execution owner | Authorized operator or validated adapter invokes versioned runbook | Approved executor obtains scoped identity and applies reviewed revision | Duplicate callback → reconcile prior attempt; revoked identity or bad provenance → stop |
| Execute → configuration owner | Capture per-host result, SMF/FMA and audit status | Capture provider/cluster receipt and actual resource/deployed version | Partial success → stop dependent steps; reconcile actual state before retry |
| Observe → receiving operator | Validate application behavior and retained dependencies | Validate service behavior, rollout health and configuration coverage | Telemetry loss → evidence degraded; CMDB write failure → preserve receipt, do not reprovision |
| Respond → incident authority | Use separately authorized restoration; validate application/data consistency | Stop promotion or use compatible rollback/restore; validate dependencies | Incompatible recovery or suspected compromise → designated incident/security authority |
| Review → acceptance/evidence owners | Retain observations, native evidence, residual issues and decision | Retain revision, execution, health, recovery and decision links | Missing evidence or unaccepted outcome → unresolved status; closure is not AO authorization |

The flow synthesizes the ServiceNow approval/reconciliation, Oracle native operations and cloud execution sources above. Configure callback authentication, replay handling, cancellation, approval expiry, target binding and partial-failure reconciliation explicitly. A queued task must recheck its window before executing; a wait timer is not a maintenance calendar. Manual execution and manual approval remain valid when supported by dependable procedures and evidence.

Progressive deployment is target-specific. A ring is a selected cohort; a canary limits exposure; blue/green switches between environments. A patch cohort is not automatically traffic shifting. CodeDeploy supports in-place EC2/on-premises deployment, but its blue/green option in that platform applies to EC2 only; Lambda/ECS have their own traffic-shifting options. No zero-downtime, universal rollback or on-premises blue/green guarantee follows. ([CodeDeploy deployment types](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html))

Operational assurance spans more than dashboards. Application Insights documents APM investigation and supported instrumentation; OpenTelemetry collects/exports signals rather than supplying the whole backend. Collector queues can overflow, so collection health itself needs observation. As a practical operating principle **(our synthesis)**, CSSP or other designated security-provider duties require an actual agreement specifying sources, coverage, custody, triage, escalation and containment authority. An availability incident is not automatically a cyber incident; sampled APM is not a substitute for security audit. ([Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview); [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/); [collector failure behavior](https://opentelemetry.io/docs/collector/resiliency/))

Evidence should relate service → request/change → revision → execution → observed state → incident/recovery → review, retaining source and receipt times, scope, gaps and controlled custody. NIST CM-3, AU-9, CA-7 and IR-4 support change records, audit protection, monitoring and response when applicable. AWS Backup distinguishes restore execution from optional validation; neither a successful backup nor infrastructure restoration demonstrates whole-service recovery. CISA’s June 2022 TRA similarly warns against assuming automatic agency-data backup. ([NIST control text](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf); [restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html); [CISA TRA, §§5.2–5.3](https://www.cisa.gov/sites/default/files/2023-05/Cloud%20Security%20Technical%20Reference%20Architecture%20v2.pdf))

## Ownership and adoption determine whether the framework works

Organizational change develops people’s ability to operate the method; ITSM change governance authorizes specific technical changes. Train and rehearse across that distinction. Pair retained-platform specialists with automation engineers to practice prechecks, stopping, reconciliation, recovery and evidence retrieval. Preserve Solaris diagnosis/audit skills while adding version control, declarative-state reasoning, interpreter/collection troubleshooting, scoped identities and provenance verification. These are proposed capabilities, not a staffing estimate, certification requirement or proof of skill shortage.

| Decision / work | Proposed R / A split; no assignment accepted | Agreement and adoption evidence |
| --- | --- | --- |
| Define offering and demand | Service designer performs; service owner accountable | Customer outcome, exclusions, supported request and self-help instructions |
| Engineer and operate execution | Automation/platform/legacy specialists perform; engineering and operations owners accountable for their respective decisions | Tested procedure, support matrix, alternate operator and recovery rehearsal |
| Approve scoped change | Coordinator prepares; designated change delegate decides | Approved targets/window, exception and emergency route |
| Maintain records and telemetry | Discovery/observability teams perform; configuration and monitoring owners accountable | Writer precedence, service identity, freshness, missing-signal treatment |
| Respond and preserve evidence | Operators/security responders perform; designated incident authority decides containment | CSSP/supplier handoffs, evidence access, custody and escalation |
| Accept service / authorize risk | Validators prepare; named acceptance authority and AO make separate decisions | Scoped acceptance versus applicable authorization record |

A customer SLA defines the promised service relationship; interteam OLAs define supporting handoffs; supplier contracts underpin delivery. ServiceNow’s definitions support this distinction, but a record type does not negotiate an agreement. Set support hours, maintenance exclusions, clock rules, escalation, recovery expectations and dependency ownership through actual agreement. An internal queue pause must not silently erase customer impact. No response duration, availability objective, staffing reduction or financial benefit is inferred here. ([SLA/OLA definitions](https://www.servicenow.com/docs/r/application-development/servicenow-sdk/fluent-sla-api.html))

### Five consultative observations grounded in the completed research

These are actual observations **about the cited research evidence**, with proposed engagement questions. They are not invented observations of a client estate. Each has an explicit owner status and falsifier or uncertainty.

| Fact | Implication → question / next decision | Owner status → uncertainty |
| --- | --- | --- |
| The 2025 CNAP transition notice routes authentication cases to P1 Jira and authorization-service cases to Cloud One ServiceNow. [Notice, p.2](https://repo1.dso.mil/platform-one/bullhorn-delivery-static-assets/-/raw/master/p1/Cloud%20Native%20Access%20Point%20%28CNAP%29%20Transition%20to%20Cloud%20One%20-%2006_03_2025.pdf) | In this example, resolver ownership can matter more than a single intake portal. Trace a service case across the actual desk/operator seam before proposing consolidation. | Proposed service owner and desk leads; unaccepted. Notice does not prove current routing or enterprise provisioning. CNAP authorization is access-service authorization, not ATO. |
| Oracle documents native repair and audit checks; Red Hat’s inspected table does not establish Solaris target support. [Oracle](https://docs.oracle.com/cd/E37838_01/pdf/E61036.pdf); [Red Hat](https://access.redhat.com/support/policy/updates/ansible-automation-platform) | Preserve native automation. First determine whether existing scheduled procedures already meet demand; only if a demonstrated gap warrants automation would an optional wrapper require exact support/recovery validation. | Proposed legacy and automation leads; unaccepted. Actual estate/support unknown; an unsupported combination reverses the adapter choice. |
| IRE governs attribute writers; CloudFormation drift can exclude resources/properties. [IRE](https://www.servicenow.com/docs/r/servicenow-platform/configuration-management-database-cmdb/c_CompsandProcessIDandReconcil.html); [drift](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) | A populated CMDB or green drift summary is insufficient. Designate desired/actual assertions and inspect one discrepancy with coverage visible. | Proposed configuration owner; unaccepted. Existing reconciliation might already satisfy demand; no replacement justified without a gap. |
| Documented GovCloud SSM excludes Change Manager/Incident Manager; Azure standard landing-zone assets need sovereign adaptation. [AWS](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-ssm.html); [Azure](https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy) | Choose the operating pattern before naming an implementation. Validate exact offering, partition, version and integration path. | Proposed platform/security leads; data/authorization decisions stay with designated authorities. No procurement or government-parity conclusion. |
| OTel can lose telemetry; AWS restore completion and validation are separate. [OTel](https://opentelemetry.io/docs/collector/resiliency/); [AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html) | Demonstrate evidence degradation and application recovery, not just healthy dashboards. Identify who can decide to continue when evidence is missing. | Proposed operations, evidence and incident owners; unaccepted. Coverage, retention and recovery objectives remain unknown. |

## Reference material fits the existing four reports

Recommend **one maintained optional reference attachment**, with concise authored interpretation where relevant. Report 1 carries only the decision implication/link; Report 2 frames foundation alternatives and residual responsibilities; Report 3 links the selected capability question and existing guideposts; Report 4 explains service handoff, response, recovery and evidence ownership. Existing CONOPS boundary/operating/service/evidence sections and Annexes A/B/D/E/F can accommodate selected narrative. This is proposed editorial use, not implemented export packaging, adopted client text or a new deliverable.

The completed reference-design note verified these exact domain strings and selected workstream IDs against `FND_DOMAINS` and `CW_WORKSTREAMS` at local HEAD `8a7c58b239f761a68e6b132965d943f3647a2d6c`. This synthesis relies on that snapshot, not a fresh repository or remote-drift check. They are **reference associations, not certified control mappings, scored dependencies or assigned work**.

| Verified domain | Existing workstreams | Reference purpose |
| --- | --- | --- |
| Governance & mission ownership | GOV-1, GOV-2, GOV-3, GOV-5 | Decisions, roles and policy |
| Application dependency visibility | ADV-1, ADV-4, ADV-5 | Service/resource identity and crossings |
| Platform / landing zone | PLZ-1, PLZ-4, PLZ-5, PLZ-7 | Foundations, identity, automation; PLZ-7 conditional DoD context |
| Security control inheritance | SCI-1, SCI-2, SCI-3, SCI-4 | Responsibility, secrets and evidence of inheritance |
| Authorization evidence (RMF) | ATO-1, ATO-2, ATO-4, ATO-6 | Evidence ownership and monitoring; no cATO promise |
| DevSecOps / IaC / CaC | DSO-1, DSO-2, DSO-3, DSO-4, DSO-5, DSO-6 | Delivery, gates, configuration and provenance |
| Operations / observability | OPS-1, OPS-2, OPS-3, OPS-5, OPS-6 | Recovery, ownership, drift and health |
| ITIL service practices | ITL-1, ITL-2, ITL-3, ITL-4 | Incident, request, change and delegated execution |
| FinOps / service catalog | FIN-1, FIN-2, FIN-3 | Acquisition and attribution; no savings inference |
| Migration execution readiness | MIG-3, MIG-4 | Promotion/recovery and retained boundaries |

Preserve **30 requests / 51 positions / 10 domains / 53 canonical workstreams**. Existing advisory anchors include ITL-2.A, ITL-3.B.1/.2, DSO-2.1, OPS-5.A and ATO-4.2; L2/L3 is activity depth, not maturity. Use current authored fields and source notes; distinguish publication, access and engagement receipt dates. Viewing a reference must never create an inheritance receipt, current-service inventory, accepted owner, score or status. No engine, schema, scheduling, deliverable-ID or production change is recommended.

### Source appendix: North Stars demonstrate different scopes

| Program description / implementation example | Transferable lesson | Date and retained limit |
| --- | --- | --- |
| [ECMA / cARMY](https://www.army.mil/ecma) | Separate onboarding, common-service operations, cybersecurity and resource management | Undated; technical catalog CAC-gated. No verified full stack, SLA or CSSP allocation; provider impact-level claims cannot be generalized. |
| [Cloud One](https://www.aflcmc.af.mil/NEWS/Article-Display/Article/3903974/cloud-one-expands-in-midst-of-great-power-competition/) | Hosting, monitoring and sustainment extend beyond migration | 12 September 2024; official indexed text, direct fetch failed. Future initiatives are not completed-state evidence; AO signoff still matters. |
| [P1 / Big Bang](https://docs-bigbang.dso.mil/latest/docs/concepts/architecture/) | Versioned platform, ingress boundaries and log/metric flows | Footer 12 August 2026; mutable, unpinned and mixed version notes. CNI outside scope; baseline is not managed operations or CSSP coverage. |
| [Navy Black Pearl](https://blackpearl.navy.mil/) | Factory enablement, shared development service and reusable runtime baseline differ | Undated; RAISE designation claims conflict within site. Do not choose the favorable statement or infer tenant entitlement. |
| [VAEC PIA](https://department.va.gov/privacy/wp-content/uploads/sites/5/2026/06/FY26VAECAWSGovCloudHighAssessingPIA.pdf) | Operator, Entra identity input and audit-to-CSOC handoff; named tools include Splunk, Dynatrace, BigFix and Turbot | Submitted 30 April 2026; footer 1 October 2024. Listed authorization termination 27 June 2026 cannot prove current authorization; renewal or unauthorized status cannot be inferred. |
| [cloud.gov pipeline](https://github.com/cloud-gov/terraform-provision) / [assessor guidance](https://docs.cloud.gov/platform/compliance/assessor-overview/) | Terraform/BOSH/Concourse, reviewed plan and manual apply; explicit customer application duties | Undated/unpinned; historical cleanup notes. Published example is not verified production inventory, DoD CSSP coverage or portable authorization. |

### Source appendix: unresolved authority and implementation qualifications

| Source family | Supported basis and qualification |
| --- | --- |
| [NIST 800-53 publication](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) | September/December 2020 text; separate release 5.2.0 notice dated 27 August 2025. CM-3 pp.98–99, AU-9 p.74, CA-6 p.89, CA-7 pp.90–91, IR-4 p.152 are printed-page locators. Adoption/tailoring unknown. |
| [SSDF final](https://csrc.nist.gov/pubs/sp/800/218/final) / [1.2 draft](https://csrc.nist.gov/pubs/sp/800/218/r1/ipd) | Final 1.1, February 2022 supports toolchain/evidence practices; 1.2 was verified only as December 2025 initial public draft, not an adopted replacement. |
| [DoD 2021 reference design](https://raw.githubusercontent.com/presidential-innovation-fellows/OSD_DSO_refernce_design_ver2/main/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v2.0%20-%20CNCF%20Kubernetes%20signed.pdf) | Archival government-published v2.0 example, local repository §3.3 and operational feedback §§5.1.4–5.2.1. Current lifecycle unverified. |
| [DoD Fundamentals v2.5](https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Fundamentals%20v2.5.pdf) / [cATO guide](https://dodcio.defense.gov/Portals/0/Documents/Library/DoDCIO-ContinuousAuthorizationImplementationGuide.pdf) / [memo](https://media.defense.gov/2022/Feb/03/2002932852/-1/-1/0/CONTINUOUS-AUTHORIZATION-TO-OPERATE.PDF) | Body retrieval blocked by 403. Follow-up locators only; no detailed criteria, supersession or mandatory applicability asserted. |
| ServiceNow / GitHub sources cited above | ServiceNow opened Brazil documentation updated 10 September 2026 despite older search labels. GitHub rolling docs/plan limits; custom protection rules preview; OIDC subject change after 15 July 2026 excludes Enterprise Server. Attestation destinations need handling review. |
| [Azure ITSM integration](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/itsmc-overview) | October 2025 page retains legacy recipes amid deprecation notices. Do not recommend legacy connector setup as a current greenfield path. |
| [Army catalog account](https://www.army.mil/article/273239/netcom_it_team_supports_army_digital_transformation) / [AESMP account](https://www.lineofdeparture.army.mil/Journals/Army-Communicator/Archive/Summer-2025/AESMP/) | January 2024 catalog-to-resolver pattern; June 2025 ServiceNow corroboration search-index-only, direct fetch forbidden/PDF too large. Catalog completion and integrations unverified. |

No complete public North Star chain, full government service/version matrix, cross-domain workflow, actual SLA/OLA, target inventory, approved connector set or client authority record was established. The explorer therefore displays **hypotheses and handoffs**, never fabricated metrics or automatic readiness. Its HTML/CSS/JavaScript runs locally without runtime dependencies or network requests; source links are optional reader navigation. It is a Studio-library concept for local research review, not a deployed Studio feature.

## Conclusion

The useful reference distinction is how cloud/GSS, retained enterprise services and optional third-party overlays roll up into enterprise service management while execution stays locally owned. Make that seam visible first: a stable service identifier, bounded execution identities, different supported procedures, and evidence that preserves disagreement or failure. Retain this reference only while it helps a practitioner ask a sharper question; any client-specific engineering or adoption belongs to separately scoped work with the actual operating and authorization owners.