Draw the Real System Boundary

An architecture diagram can be accurate and still conceal the deployment.

It may show a user, an application, several services, and databases connected by arrows. The boxes can match the code. Yet the diagram may not say which team operates each service, which system owns a data claim, why one request is trusted, what happens when the arrow partially fails, who detects the failure, which state must be reconciled, or who may authorize recovery.

Forward deployed architecture begins where boxes and arrows stop.

The C4 model supplies useful hierarchical context and container abstractions and does not require a single notation or tool. This chapter uses those structural views and adds responsibility, trust, data, runtime, and failure annotations for deployment decisions. Those annotations are an original extension, not part of the formal C4 method. [CLM-034] [CLM-040]

Draw the boundary the outcome needs

Chapter 5 selected one Orchid path: a Region West cohort and equipment family moving from confirmed equipment match through visible evidence, bounded suggestion, deterministic eligibility, qualified approval, read-only inventory evidence, audit, fallback, signals, and support.

The architecture boundary must answer:

• Which actors and systems participate from trigger to supported resolution/escalation?
• Which runtime components belong to Orchid Assist?
• Which customer systems remain authoritative for which claims?
• Where do data and control cross organizational, regional, tenant, network, or trust boundaries?
• Which identity acts at each crossing?
• Which failure can propagate, and where can it be detected/contained?
• Which team operates, changes, supports, and approves each responsibility?
• Which assumption, dependency, and scope decision justifies the boundary?

Do not begin by selecting cloud services. Begin with responsibilities and constraints.

Build the context view

The context view should contain the smallest set of external actors and systems needed to explain the deployment.

For Orchid:

Actors

• technician using Orchid Assist;
• dispatcher/service coordinator;
• qualified approver/domain specialist;
• support/operator;
• customer engineer/release owner;
• security/privacy/regional decision owners where they interact with controls.

External customer systems

• ticketing/service-request system;
• equipment registry;
• inventory/ERP;
• curated manual/document source;
• identity provider and authorization sources;
• telemetry/operations platform;
• audit/record destination where distinct.

Orchid Assist

A bounded system that coordinates the selected workflow. It does not become the owner of every customer record or decision merely because it reads or displays them.

Write a relationship sentence for every arrow:

Orchid Assist reads selected equipment identity and status fields from the customer equipment registry using the approved workload identity to bind an eligible request; the registry remains authoritative for equipment record state; ambiguous matches enter a customer-owned reconciliation path and block suggestion.

“Uses equipment registry” is not enough.

Build the container view around responsibilities

Candidate Orchid Assist containers include:

• web/user experience;
• gateway/API and workflow coordinator;
• customer integration adapters;
• evidence retrieval/index component;
• deterministic eligibility/policy component;
• optional model interface with deterministic test double;
• qualified approval workflow;
• audit/event component;
• operational signal component;
• configuration/feature/cohort control;
• local or bounded workflow state store.

Container boundaries should reflect independent runtime, data, trust, change, scaling, failure, or ownership concerns. Do not create a service for every conceptual noun. A modular component inside one runtime may be easier to understand and operate for the bounded path.

For each container, record:

• purpose and explicit non-responsibility;
• runtime/environment/region/tenant;
• owner for code, operation, data, and decisions;
• identities/permissions;
• input/output contracts;
• state held and authority of that state;
• dependencies and failure behavior;
• signals/runbook/recovery;
• change/release path;
• build/buy/reuse decision.

Distinguish six boundaries

Structural boundary

Which component/system exists and which relationship connects it.

Runtime boundary

Where code executes, scales, restarts, persists state, and receives configuration. Two modules in one repository can have different runtimes; two services can share one failure domain.

Data boundary

Which data category crosses, where it is stored/cached/derived, who is authoritative, which region/tenant applies, and how retention/deletion/reconciliation works.

Trust boundary

Where identity and authorization must be evaluated. Network location alone is not sufficient trust. Protect resources with explicit authentication/authorization appropriate to the request. [CLM-036]

Failure boundary

Which failure can propagate together, which state can diverge, where detection/containment occurs, and what recovery changes.

Responsibility boundary

Who builds, operates, supports, changes, supplies evidence, and accepts consequence. “Shared” must be decomposed into actions.

A structural diagram does not establish the other five. [CLM-039]

Annotate trust per request

Avoid labels such as “trusted network” or “internal service” as conclusions.

For each material request:

• actor/workload identity;
• credential/token mechanism and lifecycle;
• resource and operation;
• tenant/region/context;
• authorization policy and decision point;
• data/action scope;
• audit evidence;
• denial/failure behavior;
• owner and review/revocation path.

Example:

A Region West technician identity requests evidence for an assigned eligible ticket. The gateway validates the user session and assignment/region context. The workflow service uses a bounded workload identity to read selected registry/manual/inventory fields. Safety-relevant approval requires a separately authorized qualified identity. No user identity is converted into unrestricted service access.

The exact identity mechanisms wait for Chapter 8. The architecture must reserve the decisions now.

Annotate data by proposition

Do not call an entire system “the source of truth.” Identify the proposition.

• Ticketing owns current request assignment/status under the agreed workflow definition.
• Equipment registry owns selected equipment record attributes, subject to data-quality exceptions.
• ERP owns reported inventory state and reservation/action state.
• Manual repository owns document versions/approval status.
• Orchid workflow state owns its processing, evidence references, recommendation, approval, fallback, and reconciliation status.
• Audit destination owns the retained decision/event record according to the operating policy.

The application can cache or derive data without becoming authoritative for the underlying proposition. Record freshness, provenance, invalidation, and disagreement behavior.

Use a diagram grammar reviewers can challenge

Architecture notation should reduce ambiguity rather than display tool skill.

Use a stable visual grammar:

• actor: rounded rectangle;
• system/container: squared rectangle;
• data store/artifact: cylinder or document;
• ownership boundary: labeled enclosure;
• trust/data/runtime boundary: distinct labeled line style;
• observed/approved relationship: solid;
• assumed/proposed relationship: dashed;
• external dependency: owner label plus link to dependency ID;
• failure path: warning marker and link to matrix row;
• control/approval: gate/shield marker;
• normal data/control flow: directional arrow with verb and proposition.

Color may reinforce the meaning but cannot carry it alone. Every boundary and arrow needs a text label. The web and print figure must remain legible in grayscale.

Relationship labels should answer “who does what to whom, why, with which identity/data, and under whose authority?” Examples:

• Technician submits supported decision and evidence references to Orchid Assist for the assigned ticket under their user identity.
• Orchid workflow reads selected equipment propositions from Registry under bounded workload identity; Registry owner supplies quality/availability evidence.
• Qualified approver accepts or rejects safety-relevant action through Approval using a role-authorized identity; Orchid records the result but does not define the rule.
• Orchid support inspects request correlation and dependency states through the operational plane; access excludes unrestricted content by default.

The diagram should contain stable component/boundary IDs so prose, interface catalog, risks, tests, signals, and runbooks can reference the same object.

Decompose responsibility beyond RACI shorthand

A RACI chart can be helpful, but “accountable” and “responsible” are often interpreted differently. For architecture, record concrete actions.

For each component/dependency:

• code owner: reviews and changes implementation;
• runtime operator: deploys, scales, patches, monitors, and restores runtime;
• data/proposition owner: defines meaning/quality/change for the relevant claim;
• interface owner: versions and communicates contract/error behavior;
• control owner: defines control objective and approves exception where authorized;
• support owner: receives user/system failure and coordinates response;
• decision owner: accepts material consequence or go/stop decision;
• FDE role: discover, design, implement, integrate, prepare evidence, recommend, stabilize, transfer, or escalate as named;
• consumer: depends on the capability and must handle its states.

One team may fill several actions. The decomposition prevents a shared service from being “everyone’s responsibility” and no one’s recovery task.

Example responsibility record:

CNT-ADAPTER-ERP

• Code owner: Orchid Assist delivery team during build; target customer/product owner at handoff.
• Runtime operator: Orchid platform operations.
• Interface owner: customer ERP team.
• Data/proposition owner: inventory operations for availability/reservation meaning.
• Support: first line Orchid support; ERP incidents escalated to ERP on-call.
• Decision owner: service/inventory owner for action semantics; security owner for access exception.
• FDE: build adapter, verify contract/failure/reconciliation evidence, prepare ownership transfer; no authority to redefine ERP or inventory policy.

If the target handoff owner is unknown, mark the architecture incomplete. Do not write “TBD” and then design a permanent component around FDE operation.

Run boundary walkthroughs

Validate architecture with scenarios, not only static inspection.

Request walkthrough

Take one eligible case. Trace user identity, request state, data propositions, dependencies, policy, suggestion, approval, audit, and user result. At each crossing ask who owns semantics and failure.

Denied request walkthrough

Use wrong region, tenant, assignment, or role. Confirm where denial happens, what the user sees, what is logged, which data did not cross, and who diagnoses a legitimate denial error.

Dependency outage walkthrough

Remove registry, manual, inventory, model, identity, audit, telemetry, or configuration plane one at a time. Ask whether the path blocks, falls back, degrades, queues, or continues; whether that behavior is allowed; and how recovery/reconciliation works.

Split-state walkthrough

Assume desired configuration is accepted on some runtimes but not others, or a migration partially completes. Identify independent health evidence, blast radius, safe operation, rollback/forward, and owner.

Ownership-loss walkthrough

The FDE leaves. Who can deploy, access logs, interpret alerts, rotate credentials, reconcile ERP state, update policy, and approve a risky change? Every “the team” answer needs a named operating role and evidence.

Regional-boundary walkthrough

A Region West request attempts to retrieve/copy evidence from another region. Show policy decision, data path, denial/fallback, audit, and formal exception owner. Do not assume network routing enforces every data rule.

Record walkthrough findings as architecture decisions, risks, or gaps. A review that produces no inspectable artifact is weak evidence.

Model correlated failure

Components drawn separately can share a failure domain:

• same runtime cluster or region;
• same identity provider or DNS/network path;
• same configuration/control plane;
• same database, queue, storage, or secret;
• same deployment artifact or change mechanism;
• same operator/on-call team;
• same upstream data-quality process;
• same capacity or rate limit.

Annotate these shared dependencies. Otherwise a diagram suggests redundancy that does not exist.

For Orchid, a manual fallback hosted behind the same unavailable identity and network path is not a fallback. A rollback tool that depends on the failed configuration store is not a recovery boundary. A second model endpoint using the same retrieval/index state may not protect evidence availability.

Ask for each critical promise:

Which independent capability must remain available to detect, decide, communicate, contain, and recover when the primary path fails?

Independence is contextual and costly. The architecture should justify where it is necessary rather than duplicate everything.

Trace architecture to outcomes and tests

Every material container or boundary should exist because of an outcome, guardrail, scope, or operating decision.

Architecture item	Upstream reason	Downstream evidence
equipment confirmation/reconciliation	wrong-asset consequence; scope must prove ambiguity	contract/exception tests, UAT, audit, match signal
visible provenance/retrieval	trust and evidence-complete outcome	retrieval/version tests, UAT, quality telemetry
deterministic eligibility	safety guardrail	rule tests, prohibited-case suite, approval evidence
qualified approval	formal authority boundary	authorization/audit/UAT/denial tests
cohort/feature control	bounded/reversible scope	rollout/config health and stop evidence
workflow state/reconciliation	partial failure/ambiguous completion	idempotency/recovery/runbook evidence
operational signals	support/ownership exit	SLO/alerts/diagnostic rehearsal

If a component has no upstream reason, challenge it. If an outcome/guardrail has no architecture item or accepted external owner, the design has a gap.

Map failure propagation and ownership

For every material dependency or container, complete a failure/ownership matrix:

Failure	User/workflow effect	Detect	Contain/fallback	Correct/reconcile	Owner
equipment registry unavailable	cannot confirm match	dependency signal + request state	block suggestion; manual approved path	restore/retry; no invented match	registry ops + Orchid support
multiple equipment matches	wrong evidence risk	validation rule	require confirmation/escalation	customer reconciliation	data/domain owner
manual retrieval stale/missing	incomplete evidence	version/provenance rule	show limitation; block affected action	source update/reindex	manual owner + retrieval owner
inventory timeout	current state uncertain	timeout + correlation	no automatic retry/action; show uncertain	status/reconcile	ERP owner + adapter owner
model unavailable/refuses	no suggestion	model-interface state	deterministic/manual evidence path	retry/change under policy	Orchid runtime owner
approval service/identity unavailable	action unauthorized	authorization failure	block/escalate	restore authorized path	identity/approval owners
telemetry unavailable	blind operation	self/independent health evidence	hold/ramp stop based on risk	restore evidence path	ops owner

The matrix exposes ownerless arrows. If the deployment has a fallback but no one can invoke it, the fallback is not operational.

Configured state is not operational state

A configuration API can accept a desired value while distributed runtime state differs. Health must not be inferred solely from successful configuration.

A first-party Cloudflare postmortem reports a 2026 outage in which configured and operational state diverged and recovery was complicated by different distributed states. The case is architecture-specific and self-reported, but the transferable lesson is useful: validate the operational effect, model divergent state, and design recovery for more than reapplying the previous configuration. [CLM-037]

For Orchid, ask:

• Did the feature/cohort policy reach every intended runtime?
• Is the identity/authorization rule active where requests execute?
• Did the manual/index version become available to all selected paths?
• Did a migration complete in every store/region?
• Can rollback operate when states differ?
• Which health evidence is independent of the control action?

The architecture should distinguish desired, accepted, applied, observed, and reconciled state.

Separate control plane and data plane carefully

Control/data separation can limit blast radius, but the control plane remains part of operation.

A first-party Cloudflare postmortem reports that control-plane and data-plane separation limited one class of customer traffic impact during a 2025 dashboard/API outage, while the unavailable API/dashboard still had operational consequence. [CLM-038]

For Orchid:

• data/workflow plane performs selected request/evidence/decision processing;
• control plane manages configuration, cohort/feature exposure, version, and perhaps deployment administration;
• operating plane supplies telemetry, alert, support, and recovery access.

Ask what happens if each plane fails alone and whether recovery of one depends on the failed plane. A feature-control service that cannot disable exposure during its own outage is a material boundary decision.

Make build, buy, and reuse a decision record

For each capability, compare:

• outcome/risk requirement;
• customer constraints;
• existing product/customer capability;
• alternatives including no new component;
• integration/identity/data fit;
• failure and recovery;
• security/privacy/governance evidence;
• operability/support/skills;
• cost and lock-in;
• migration/exit;
• reuse evidence versus customer specificity;
• owner and revisit trigger.

Example: evidence retrieval can use an existing product component if it supports approved regional storage, document provenance/version, access filters, failure signals, local testability, and an operating owner. Otherwise “reuse” may shift hidden work into customer-specific glue.

Do not build a custom component to demonstrate engineering depth. Do not buy a service because its diagram is polished. Select the boundary that makes the contracted path supportable.

Balance quality attributes explicitly

Provider architecture frameworks enumerate concerns such as operational excellence, security, reliability, performance, and cost. Use them as questions, not certification. [CLM-035]

An architecture decision record should state the trade:

Cache approved manual evidence inside the Region West boundary to meet low-connectivity latency. Accept additional freshness, storage, access, invalidation, and operating responsibilities. Do not cache unrestricted ticket notes. Validate version/freshness on request, expose provenance, and fall back safely when required evidence is unavailable. Regional data/security/operations owners approve the boundary and residual risk.

The decision does not claim maximum reliability or security. It names the consequence and owner.

Write architecture decisions so they can expire

An architecture decision record is not a defense of the selected option. It is a versioned explanation of why the option is currently justified and when it must be revisited.

Use these fields:

• decision ID, title, status, date, and owners;
• problem/outcome/guardrail/risk served;
• current evidence and constraints;
• alternatives, including no new component and reduced scope;
• selected option and rationale;
• quality/security/privacy/operating tradeoffs;
• affected boundaries, interfaces, data, identities, tests, signals, and owners;
• assumptions and evidence gaps;
• failure/recovery behavior;
• consequences and debt;
• validation evidence;
• revisit/expiry/rollback trigger;
• superseding record.

Example:

ADR-OA-006: keep inventory integration read-only in first path

Context. The outcome requires current inventory evidence. The customer requests automatic ordering, but write-completion semantics, intent identity, reconciliation, approval, compensation, fraud/abuse controls, and ownership are unresolved.

Decision. Read selected availability/status evidence. Do not create reservation/order through Orchid Assist. Preserve a separate adapter contract boundary so a later write path requires a new outcome/control decision.

Consequences. Technician continues the approved ordering process outside Orchid Assist; duplicate entry/burden must be measured. The first path cannot claim automated resolution. Data freshness/provenance and read availability remain material.

Revisit. Only after DEP-ERP-WRITE semantics/authority/recovery evidence and a separate guardrail/outcome contract pass review.

This record prevents “temporary” scope from turning into accidental architecture or an implied future commitment.

Transfer incident lessons without copying architecture

Public postmortems are useful when they change a question, not when their architecture is copied.

From the Cloudflare configured-versus-operational-state case, transfer questions such as:

• How does Orchid know a cohort/configuration change took effect on every relevant runtime?
• Can a health check validate the actual user path rather than the configuration API response?
• Can recovery handle mixed versions/state?
• Are snapshots/rollback tied to observed health and independently reachable?

Do not infer that Orchid has the same distributed design, cause, or remediation. The postmortem is first-party evidence about Cloudflare’s system. [CLM-037]

From the dashboard/API outage, transfer questions such as:

• Can a client loop/retry amplify demand?
• Are retries distinguishable from new requests?
• Does control-plane impairment block configuration, support, or recovery while workflow processing continues?
• Are capacity and rollout assumptions tested for the control/API path?

Again, do not claim the same failure. Use the case to challenge boundaries. [CLM-038]

This discipline avoids cargo-cult architecture: transplanting another organization’s services without its scale, constraints, or evidence.

Review the design with accountable owners

Architecture review needs several lenses:

• workflow/domain: do decisions, evidence, approval, and exceptions match actual work?
• data/interface: are propositions, semantics, lineage, quality, and change owners explicit?
• security/privacy/governance: are access, data handling, control, evidence, and formal decisions routed correctly?
• reliability/operations: can failures be detected, contained, diagnosed, recovered, and supported?
• customer environment: are identity, networking, region, capacity, configuration, and release assumptions real?
• product/engineering: are components maintainable, testable, reviewable, and appropriately reused?
• user/accessibility: can representative users perform the path and understand evidence/fallback?

Record reviewer scope and disposition: approved within boundary, approved with ownered conditions, revise, or blocked. Silence is not approval.

If reviewers disagree, locate the proposition: Is the dispute about a fact, constraint, risk appetite, authority, architecture trade, or missing evidence? Assign the next decision/test rather than averaging opinions.

The review output should update OA-05, ADRs, risks, dependencies, and downstream tests. A slide presentation with no decision record is not the gate.

Avoid architecture theater

Box ownership by assumption

The diagram labels “Customer IT” without a confirmed team/access/support path.

Repair: name responsibility actions and owner acceptance; unresolved ownership is a risk.

VPC equals trusted

Network placement substitutes for per-request identity and authorization.

Repair: annotate actor/workload/resource/operation/policy/audit/denial.

Arrow without semantics

“Calls ERP” hides timeout, intent, state, retry, and reconciliation.

Repair: link to an interface decision/gap; Chapter 7 completes the contract.

One source of truth

A system is labeled authoritative for every workflow claim.

Repair: assign authority by proposition and model disagreement.

Framework compliance

Completing provider review questions becomes proof of architecture quality.

Repair: map selected concerns to implementation/evidence/gaps; no certification claim.

Microservice reflex

Conceptual components become independently deployed services without operating justification.

Repair: choose runtime boundaries from change, scale, trust, data, failure, and ownership needs.

Product-logo architecture

Vendor names replace responsibilities and portability.

Repair: provider-neutral capability/contract first; label current implementations as replaceable.

Orchid OA-05 structural design

The first portion of OA-05 Deployment Design Dossier now contains:

Context. Technicians, dispatch, qualified approvers, support, customer engineers; ticketing, registry, ERP, manuals, identity, telemetry/audit; Orchid Assist bounded coordinator.

Containers. Web UX, gateway/workflow, adapters, retrieval, deterministic policy, optional model interface/test double, approval, audit, signals, feature/config, state.

Boundaries. Region West/tenant/data, human/workload identity, customer/product ownership, runtimes, external dependencies, failure/containment.

Proposition authority. Request, equipment, inventory, manual, workflow/approval, audit assigned separately.

Failure matrix. Registry, match, manual, inventory, model, approval/identity, telemetry paths with detect/contain/correct/owner.

Build/buy/reuse decisions. Required per capability; unresolved decisions remain explicit.

Deferred detail. Chapter 7 supplies interface/data contracts; Chapter 8 deployment/identity topology; Chapter 9 AI boundary; Chapter 10 control evidence.

No diagram implies that the FDE owns customer systems or accepts customer risk.

The Chapter 6 gate

Before designing interfaces, the architecture must show:

• context/container structure and relationship sentences;
• runtime, data, trust, failure, and responsibility annotations;
• proposition-specific authority;
• identity/resource/operation decision points;
• failure propagation, containment, correction, and owners;
• configured versus operational state;
• control/data/operating plane dependencies;
• build/buy/reuse records or explicit gaps;
• quality tradeoffs, assumptions, and revisit triggers;
• trace to OA-03 outcome/guardrails and OA-04 scope/dependencies.

The gate passes when a reviewer can identify what fails, who knows, what the user sees, what is safe, who acts, and which state must be reconciled. A polished diagram alone cannot pass.

Chapter 7, Make Interfaces and Data Explicit, will turn every material arrow and data claim into versioned semantics for schema, identity, ordering, timeout, retry, idempotency, quality, provenance, exceptions, and reconciliation.