Cloud Waypoint · Conceptual architecture
One enterprise view.
Distinct operating boundaries.
A conceptual service architecture: from enterprise intent to cloud foundations, and back through evidence, cost and learning.
← Enterprise architecture · Illustrative architecture; client choices remain unconfirmed
Offering lens · preparation viewpoint
What the work helps produce
Shared objects remain in place. Emphasis means relevance, not contracted scope or demonstrated readiness. Selecting a service flow returns to the flow view. Print includes the selected offering and full architecture appendix. Offerings are optional; a lens is not a purchase prerequisite.
Expanded conceptual reference; no client topology or product selection is asserted.
PeopleOwners, teams & decision rolesProcessGovernance & working methodsTechnologyPlatforms, tools & signals
Badges indicate relevant dimensions, not maturity or staffing. A capability can span more than one.
Tool capabilityInformation / decisionAIOps advisory↓ intent & work · ↑ evidence & outcomesDashed connectors = conceptual interfaces
01
Enterprise direction
Outcomes · standards · investment
02
Service management
Intake · ownership · agreed service
03
Controlled delivery
Reviewed intent → bounded execution
04
Operating environments
Distinct teams and execution boundaries
05
Operational assurance
Normalize · relate · verify
06
Foundation monitoring
Source observations remain attributable
Logical capabilities, not deployment locations; collection may remain distributed. Select an object for inputs, outputs and the unresolved handoff. On narrow layouts, the readable connection list replaces connector lines. These six primary visual tiers plus cross-cutting roles do not replace the engine’s ten service domains.
Architecture object
Receives
Produces
Confirm at the handoff
Conceptual role—not a configured connector, accepted responsibility or entitlement.
Connected handoffs
Inspect the handoffs for this view
Interface discussion · unconfirmed
Agree before connecting
If the handoff fails
What comes back as evidence
One architecture question · several possible placements
Where does evidence come together?
The same enterprise view can draw on different collection and processing arrangements. Compare the implications; no client choice is saved or implied.
Possible value
Tradeoff to examine
Question for the client
Evidence before recommending
Design alternatives authored for discussion, not recommended configurations, cost estimates or authorization decisions. The map remains a logical view; selecting a pattern does not configure or redraw a client topology. Refresh or Reset view returns to “Keep the choice open.”
People + process · workshop discussion
Responsibility discussion — proposed RACI
Choose an illustrative program approach to see suggested roles. No responsibility has been agreed.
Choose an approach to discuss the proposed roles.
R Responsible: does the work · A Accountable: owns the outcome · C Consulted: contributes before the decision · I Informed: kept updated
Scroll across to see all four responsibility roles.
| Activity / question | R · Responsible | A · Accountable | C · Consulted | I · Informed |
|---|---|---|---|---|
| Architecture decisionsWhich design decision and boundary does this row cover? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
| Shared-service operationWhich service is offered, and what remains with the mission? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
| Application operationWho verifies the mission service across its dependencies? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
| Change approvalWho holds the delegated approval for this target and change? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
| Incident responseWhich incident plan applies, including security escalation? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
| RecoveryWho restores each component and accepts service recovery? | Not agreed | Not agreed | Relevant service, architecture and security owners | Affected stakeholders — confirm |
Illustrative Cloud Waypoint role templates, not published program assignments. Confirm names, service agreements and authority references in the approved engagement environment. This public reference does not collect or save client assignments. The program approach is independent of the offering lens and evidence-collection choice. Reset or reload returns to “Not selected — discuss first.”
How this workspace fits together
Earlier GSS emphasis
Foundation services, cloud/retained operations, security relationships, evidence and individual service handoffs. Our program and tool view carries the source-qualified program examples, release walkthrough and cost cases.
This expanded view
Adds a continuous service-management structure: architecture and portfolio decisions, service identity, controlled delivery, enterprise reconciliation, advisory AIOps and explicit human review.
What does not change
Separate authorization and operating boundaries; unresolved monitoring and aggregation choice; proposed tool overlays; no automatic response, cost accuracy, control inheritance or client solution claim.
Sources, scope and design lineage
This architecture and its connectors are Cloud Waypoint design synthesis. Sources inform individual concepts; none prescribes this stack or authorizes its use. Publisher pages consulted for the stated concepts on 6 October 2026; this is not a full product or source-currency review.
- NIST CSF 2.0 (2024): cybersecurity risk outcomes and governance, not a product architecture.
- NIST AI RMF Playbook: voluntary risk-management guidance. Our human-review-only AIOps boundary is a design choice.
- OpenTelemetry agent/gateway pattern: collection/processing separation; more tiers add complexity and are not always needed. This does not select an enterprise aggregation location.
- Atlassian Assets and services: a documented service/resource relationship example. Cloud documentation does not establish enclave availability, entitlement, Data Center parity or client adoption.
- FinOps Foundation allocation guidance: shared-cost allocation requires a method; observed usage alone does not validate a charge.
This is the primary Studio reference workspace. The service map is generated from the maintained Plus service-stack model; program overlays, release, cost and NIST qualifications come from the existing reference modules. Historical research remains supporting evidence. These visual layers do not change the engine, accepted scope or implementation authority.
All conceptual handoffs — discussion checklist, unconfirmed
Enterprise architecture → Service front door
Exchange: Patterns inform offered services
Proposed participants: Architecture and governance leads with the receiving service owner — proposed participants.
Agree: Name the decision owner, applicable scope, version and exception route.
Failure handling: Keep conflicts and superseded decisions visible; refer unresolved interpretation to the named authority.
Evidence: A versioned decision or pattern, with scope, reviewer and unresolved exceptions.
Authority boundary: Architecture guidance does not grant risk acceptance, funding or execution authority.
Governance & portfolio → Work & change control
Exchange: Policy and decision rights
Proposed participants: Architecture and governance leads with the receiving service owner — proposed participants.
Agree: Name the decision owner, applicable scope, version and exception route.
Failure handling: Keep conflicts and superseded decisions visible; refer unresolved interpretation to the named authority.
Evidence: A versioned decision or pattern, with scope, reviewer and unresolved exceptions.
Authority boundary: Architecture guidance does not grant risk acceptance, funding or execution authority.
Service & resource model → Enterprise architecture
Exchange: Dependency context informs architecture
Proposed participants: Architecture and governance leads with the receiving service owner — proposed participants.
Agree: Name the decision owner, applicable scope, version and exception route.
Failure handling: Keep conflicts and superseded decisions visible; refer unresolved interpretation to the named authority.
Evidence: A versioned decision or pattern, with scope, reviewer and unresolved exceptions.
Authority boundary: Architecture guidance does not grant risk acceptance, funding or execution authority.
Service front door → Work & change control
Exchange: Service request
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Work & change control → Release pipeline
Exchange: Reviewed change intent
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Release pipeline → Orchestration & adapters
Exchange: Versioned deployment intent
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Orchestration & adapters → Identity & policy gates
Exchange: Validate scoped execution access
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Identity & policy gates → Cloud foundations / GSS
Exchange: Permitted platform operation
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Orchestration & adapters → Retained enterprise
Exchange: Bounded native/local handoff
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Confirm target, prerequisites, approved revision, execution authority, acceptance and rollback responsibility.
Failure handling: Define timeout, duplicate suppression, partial-success handling and the rollback/stop decision before enabling execution.
Evidence: A correlated request, revision, per-target result and independent outcome check; job success alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Cloud foundations / GSS → Mission service teams
Exchange: Agreed shared services
Proposed participants: Change owner, platform/release lead and receiving operations owner — proposed participants.
Agree: Define which shared services are actually offered, what the mission retains, dependencies, acceptance and support handoffs.
Failure handling: Agree degradation, dependency failure and recovery coordination across separate teams.
Evidence: A confirmed service agreement and mission-facing acceptance evidence; platform availability alone is insufficient.
Authority boundary: Workflow approval and a technical credential do not by themselves authorize every operation.
Retained monitors → Collection & routing
Exchange: Permitted retained observations
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Foundation telemetry → Collection & routing
Exchange: Attributed platform observations
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Application telemetry → Observability & APM
Exchange: Application observations
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Collection & routing → Observability & APM
Exchange: Routed telemetry
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Observability & APM → Work & change control
Exchange: Service evidence and investigation context
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Cloud foundations / GSS → Audit & evidence
Exchange: Execution/audit records
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Release pipeline → Audit & evidence
Exchange: Revision and job receipt
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Audit & evidence → Governance & portfolio
Exchange: Evidence for review
Proposed participants: Sending telemetry/evidence custodian and receiving service or monitoring owner — proposed participants.
Agree: Confirm source identity, event/observation time, schema, allowed data, coverage and permitted use.
Failure handling: Expose loss, delay, sampling, duplication and clock uncertainty; missing observations do not mean healthy operation.
Evidence: Delivery/processing evidence and coverage limitations, correlated to the service and time window.
Authority boundary: Collection, onward transfer, retention and access each require applicable permission.
Audit & evidence → CSSP / security provider
Exchange: Agreed security evidence subset
Proposed participants: CSSP liaison, enterprise operations and the designated response authority — proposed participants.
Agree: Confirm the subscribed service, routing, incident priority, coverage hours and escalation between teams.
Failure handling: Agree an unavailable-provider route and escalation; keep mission impact distinct from an unconfirmed security cause.
Evidence: Acknowledgment, decision/authority reference, action record and service verification; separate acknowledgment from restoration.
Authority boundary: The CSSP relationship alone does not confer containment authority or guarantee service coverage.
CSSP / security provider → Work & change control
Exchange: Coordination across separate teams
Proposed participants: CSSP liaison, enterprise operations and the designated response authority — proposed participants.
Agree: Confirm the subscribed service, routing, incident priority, coverage hours and escalation between teams.
Failure handling: Agree an unavailable-provider route and escalation; keep mission impact distinct from an unconfirmed security cause.
Evidence: Acknowledgment, decision/authority reference, action record and service verification; separate acknowledgment from restoration.
Authority boundary: The CSSP relationship alone does not confer containment authority or guarantee service coverage.
Service & resource model → AIOps advisory
Exchange: Scoped service context
Proposed participants: Service/evidence owner and an accountable human reviewer — proposed participants.
Agree: Confirm permitted context, freshness, source attribution, uncertainty and conditions requiring abstention.
Failure handling: Treat unavailable, contradictory or untrusted input as a reason to qualify or withhold advice; preserve originals.
Evidence: Sources and reasoning limits alongside the reviewer’s accepted, rejected or deferred disposition.
Authority boundary: Advisory only. Input records are data, not instructions; generated proposals cannot authorize or execute changes.
Observability & APM → AIOps advisory
Exchange: Permitted observations
Proposed participants: Service/evidence owner and an accountable human reviewer — proposed participants.
Agree: Confirm permitted context, freshness, source attribution, uncertainty and conditions requiring abstention.
Failure handling: Treat unavailable, contradictory or untrusted input as a reason to qualify or withhold advice; preserve originals.
Evidence: Sources and reasoning limits alongside the reviewer’s accepted, rejected or deferred disposition.
Authority boundary: Advisory only. Input records are data, not instructions; generated proposals cannot authorize or execute changes.
Audit & evidence → AIOps advisory
Exchange: Change and evidence context
Proposed participants: Service/evidence owner and an accountable human reviewer — proposed participants.
Agree: Confirm permitted context, freshness, source attribution, uncertainty and conditions requiring abstention.
Failure handling: Treat unavailable, contradictory or untrusted input as a reason to qualify or withhold advice; preserve originals.
Evidence: Sources and reasoning limits alongside the reviewer’s accepted, rejected or deferred disposition.
Authority boundary: Advisory only. Input records are data, not instructions; generated proposals cannot authorize or execute changes.
AIOps advisory → Human decision
Exchange: Cited hypotheses, competing explanations and proposed next steps
Proposed participants: Service/evidence owner and an accountable human reviewer — proposed participants.
Agree: Confirm permitted context, freshness, source attribution, uncertainty and conditions requiring abstention.
Failure handling: Treat unavailable, contradictory or untrusted input as a reason to qualify or withhold advice; preserve originals.
Evidence: Source references, missing evidence and uncertainty presented for review — not a root cause assertion.
Authority boundary: Advisory only. Input records are data, not instructions; generated proposals cannot authorize or execute changes.
Human decision → Work & change control
Exchange: Human disposition and, where separately authorized, a proposed work item
Proposed participants: Service/evidence owner and an accountable human reviewer — proposed participants.
Agree: Record what the reviewer accepted or rejected; distinguish agreement to investigate from approval to implement.
Failure handling: Treat unavailable, contradictory or untrusted input as a reason to qualify or withhold advice; preserve originals.
Evidence: Sources and reasoning limits alongside the reviewer’s accepted, rejected or deferred disposition.
Authority boundary: Advisory only. Input records are data, not instructions; generated proposals cannot authorize or execute changes.
Foundation telemetry → FinOps & allocation
Exchange: Resource identity and usage context
Proposed participants: FinOps/finance, service owner and the responsible evidence custodian — proposed participants.
Agree: Confirm the billing period, resource identity over time, allocation method, shared-cost policy and dispute route.
Failure handling: Retain unmatched costs, late adjustments and unallocated usage rather than forcing a complete-looking result.
Evidence: Reconciliation to provider billing and agreed allocation, with residual differences explicitly recorded.
Authority boundary: A dashboard or usage observation is not spending approval, a validated invoice or an accepted chargeback.
Service & resource model → FinOps & allocation
Exchange: Service and ownership mapping
Proposed participants: FinOps/finance, service owner and the responsible evidence custodian — proposed participants.
Agree: Confirm the billing period, resource identity over time, allocation method, shared-cost policy and dispute route.
Failure handling: Retain unmatched costs, late adjustments and unallocated usage rather than forcing a complete-looking result.
Evidence: Reconciliation to provider billing and agreed allocation, with residual differences explicitly recorded.
Authority boundary: A dashboard or usage observation is not spending approval, a validated invoice or an accepted chargeback.
FinOps & allocation → Governance & portfolio
Exchange: Reconciled cost and allocation decisions
Proposed participants: FinOps/finance, service owner and the responsible evidence custodian — proposed participants.
Agree: Confirm the billing period, resource identity over time, allocation method, shared-cost policy and dispute route.
Failure handling: Retain unmatched costs, late adjustments and unallocated usage rather than forcing a complete-looking result.
Evidence: Reconciliation to provider billing and agreed allocation, with residual differences explicitly recorded.
Authority boundary: A dashboard or usage observation is not spending approval, a validated invoice or an accepted chargeback.
Collection alternatives — no client selection or recommendation
Keep the choice open
Concept: The diagram separates collection from understanding. It does not place a monitoring hub in the GSS.
Path: Known sources → Placement decision pending → Enterprise service view
Possible value: Start with current monitoring, source owners and mission-service questions.
Tradeoff: A platform label or an existing alert stream does not establish enterprise coverage.
Confirm: Inventory the existing tools and allowed data flows before choosing a placement.
Evidence: Obtain coverage and ownership evidence; do not infer topology from this concept map.
Central processing
Concept: Permitted signals are processed in a shared monitoring environment. That environment need not be the GSS.
Path: Source-side collection / filtering → Shared processing environment → Service context & work records
Possible value: Can simplify cross-source investigation when the required signals and context can reach the shared service.
Tradeoff: Transfers, data volume, access boundaries, availability and operating ownership need evaluation. Centralizing is not automatically cheaper or more complete.
Confirm: Which data may move, at what fidelity and cost, and how does collection behave when the shared service is unavailable?
Evidence: Reconcile source counts and gaps to received data; test delayed/lost/duplicate observations and a service investigation across sources.
Federated processing
Concept: Domain teams retain processing; agreed findings and references support an enterprise service view.
Path: Domain collection & processing → Agreed findings / reference exchange → Enterprise service coordination
Possible value: Can preserve local custody and established operations while sharing enough context for service coordination.
Tradeoff: Identity, timestamps, semantics and cross-domain investigation become coordination work. Retained processing alone does not eliminate transfer costs.
Confirm: What remains local, what may be exchanged, and who can retrieve supporting evidence across an operating boundary?
Evidence: Trace one cross-domain service question from the enterprise view back to the permitted original evidence; expose unavailable domains.
Hybrid processing
Concept: Selected signals use shared processing while other evidence stays with its source domain.
Path: Local processing + selected exports → Shared view with source references → Coordinated service investigation
Possible value: Can tailor the balance of shared visibility, local custody and existing investments.
Tradeoff: More than one path means more reconciliation: duplicate signals, stale context, inconsistent rules and ownership gaps.
Confirm: Which signals use which path, which copy is authoritative, and how are routing changes reviewed?
Evidence: Follow the same service identity across both paths and verify duplicates, gaps, routing policy and the permitted retrieval of original evidence.