Context Diagram: Platform, Users, Enterprise Data, AI Providers, and AWS Boundaries

Good to see you again. In the previous lesson, you translated the evidence assistant’s business case and risk register into measurable quality attributes: authorization integrity, grounded citations, responsiveness, freshness, auditability, and recoverability.

Now you will turn those commitments into a one-page system context diagram for the enterprise intelligence platform. It will make clear who uses the platform, which enterprise systems supply information, which AI providers it depends on, and where the AWS boundary sits. This is deliberately a high-level architecture view: it should help an executive sponsor, data owner, security reviewer, and delivery team agree on scope before discussing microservices, databases, or Kubernetes.

---

What a system context diagram is—and is not

A system context diagram is the widest useful view of an architecture. In C4 terminology, it is a Level 1 diagram: it places the software system being built at the center, then shows the people and external software systems with which it directly interacts.

It answers four executive-level questions:

1. What is the system of interest?
2. Who uses it, and for what purpose?
3. What existing enterprise systems and third parties does it depend on?
4. Where are the important ownership, cloud, and trust boundaries?

It does not answer questions such as:

• Which FastAPI endpoints exist?
• Whether retrieval uses PostgreSQL, OpenSearch, or another vector store.
• Whether an API runs in ECS or EKS.
• Which queues, services, tables, prompts, or internal modules are involved.

Those are valuable questions, but they belong in later container, deployment, data-flow, and sequence diagrams. A context diagram is a map, not an implementation blueprint.

The banking example gives the essential pattern:

• one clearly named system of interest;
• named people with a short description;
• named external software systems with a short responsibility statement;
• relationships labeled with meaningful verbs.

A useful test is whether a stakeholder can read the diagram aloud as a set of clear sentences. For example:

An eligible analyst uses the Enterprise Intelligence Platform to obtain cited answers from approved knowledge sources. The platform delegates identity verification to the enterprise identity provider and invokes approved AI model providers under governed controls.

If that sentence is unclear, the diagram will be unclear too.

---

Start with the architecture story, not AWS icons

The capstone system can be framed as:

Enterprise Intelligence Platform: a governed application that helps authorized analysts prepare decision support using cited evidence from approved enterprise sources.

That sentence becomes the description inside the central box. It also sets a discipline: the system is not “an AWS account,” “a chatbot,” or “a vector database.” It is a business-facing platform with a defined purpose.

Your earlier artifacts provide the raw material for the diagram:

Earlier artifact	Context-diagram implication
Primary user and problem statement	Show the analyst or decision-support user as a person.
Stakeholder map	Include direct operational actors, such as a data steward, only if they interact with the platform. Keep sponsors and funders in the stakeholder map unless they actually use it.
Authorization and privacy risks	Show the enterprise identity provider and approved data-source systems.
Groundedness and citation requirements	Show enterprise knowledge sources as systems distinct from the platform.
Model-provider and third-party risks	Show managed and external AI providers as dependencies.
AWS deployment intent	Draw an AWS account and Region boundary around the platform’s hosting environment.

At this level, avoid representing every repository separately. A good initial diagram might distinguish only the data categories that have different owners, permissions, or interaction patterns:

• Enterprise knowledge sources: approved policies, procedures, research, and document repositories used as cited evidence.
• Systems of record: operational databases or business applications that provide narrowly permitted contextual facts.
• Enterprise identity provider: the system that authenticates users and supplies claims used for authorization.
• AI model providers: managed AWS models, external providers, or both.

A shared enterprise data lake remains an external system if another organization owns it and the platform consumes governed data from it. Conversely, a data store owned exclusively by the platform belongs inside a later container diagram, not here.

The distinction between semantic and situational data is useful even before you select a retrieval technology. Semantic context is typically derived from documents and other content that users need to search and cite. Situational context is a current, structured fact about a user, request, or workflow. Both may be relevant, but they carry different privacy and authorization obligations.

---

Use boundaries to communicate responsibility

For this capstone, a conventional C4 context diagram needs one deliberate extension: an AWS boundary. C4 context diagrams normally minimize technology detail, but cloud location is materially relevant here because of privacy, provider risk, network exposure, data residency, and operational ownership.

Use three distinct boundary concepts.

1. Platform boundary

The Enterprise Intelligence Platform is the system boundary. It represents the product your team is accountable for delivering: the user experience, retrieval behavior, model invocation policy, citation rendering, and audit behavior.

At context level, it is one box. Do not break it into a web application, API, retrieval service, gateway, and database yet.

2. AWS account and Region boundary

Draw a labelled boundary around the platform to state its intended hosting environment, for example:

AWS account and chosen Region

This says that platform-operated compute and managed AWS dependencies are expected to run there. It does not guarantee that all data remains in that Region, nor does it demonstrate compliance. Those claims require later evidence about provider configuration, logging, backups, cross-Region services, and contractual data handling.

Amazon Bedrock can appear inside this AWS boundary as a managed AI service dependency, while still being external to the platform. The platform invokes it; it is not code owned by the platform team.

3. External enterprise and provider boundaries

Enterprise source systems, the identity provider, and non-AWS model providers should remain outside the AWS boundary unless their actual ownership and location are known. This avoids accidentally implying that the platform owns those systems or that all data is copied into AWS.

The AWS reference architecture below is intentionally more detailed than your context diagram. It shows distribution, container orchestration, secrets, databases, and several model-provider routes. Those implementation details are appropriate when planning deployment, but including them now would obscure the executive story.

---

Sketch the capstone context diagram

Build the diagram in this order:

1. Place the Enterprise Intelligence Platform in the center and state its purpose in one sentence.
2. Add the primary analyst who submits questions and reviews cited answers.
3. Add a data steward or source owner only if that role directly manages sources, permissions, or ingestion through the platform.
4. Add the enterprise identity provider, because your P0 authorization requirement depends on it.
5. Add the two enterprise data categories: approved knowledge sources and, if in scope, systems of record.
6. Add the AI providers. For an AWS-first design, distinguish Amazon Bedrock from an optional approved external model provider.
7. Enclose the platform and AWS-managed provider dependency in the AWS account and Region boundary.
8. Label every relationship with a concise purpose and include relevant constraints in the label where they materially affect trust.

Here is a suitable first sketch for the authorization-aware evidence assistant. It is a draft architecture hypothesis, not a claim that all listed services or integrations already exist.

Draft context diagram — Enterprise Intelligence Platform (system context)

The diagram does not claim that every query uses every dependency:

• A general policy question may use approved knowledge sources and a model provider, without consulting a system of record.
• A request involving a current workflow state may need permitted structured context from a system of record.
• An external model provider may be optional, omitted entirely for an AWS-only pilot, or limited to specific approved use cases.

That precision matters. A vague connection labelled “data” or “AI” cannot tell a reviewer what crosses a boundary. A relationship label such as “retrieves authorized evidence and source metadata” signals that authorization filtering and citation metadata are architectural requirements, not implementation afterthoughts.

Relationship labels as governance statements

For this platform, write relationships in language that makes risk controls visible:

Source	Destination	Useful relationship label	What the label makes reviewable
Decision Analyst	Platform	“Submits evidence questions and views cited answers”	The critical user journey and expected product outcome
Platform	Enterprise Identity Provider	“Delegates authentication and obtains access claims”	The platform does not make authorization decisions from a client-provided role alone
Platform	Knowledge Sources	“Retrieves authorized evidence and source metadata”	Permission-aware retrieval, freshness, source identity, and citations
Platform	System of Record	“Retrieves narrowly permitted contextual facts”	Data minimization and a distinction between factual context and broad document retrieval
Platform	Amazon Bedrock	“Invokes approved managed models with minimum necessary context”	Provider boundary, privacy review, and prompt-data minimization
Platform	External AI Provider	“Invokes approved fallback or specialized models under policy”	Vendor governance, resilience, and model-routing controls

Do not add API keys, credentials, subnet identifiers, token formats, or prompt templates to this diagram. Those details will matter later, especially for security and deployment, but they make a Level 1 view difficult to read and can reveal information that should not circulate broadly.

---

Validate the diagram against the previous quality profile

A context diagram is useful only if it helps identify decisions and gaps. Review your sketch against the quality attributes from the previous lesson.

Authorization integrity

Ask:

• Is the enterprise identity provider visible?
• Are enterprise knowledge sources distinct from the platform?
• Does the platform’s data relationship make permission-aware retrieval explicit?
• Does any path accidentally imply that a browser or external provider accesses enterprise data directly?

The intended answer is that the platform mediates access. The user should not send enterprise document content straight to a model provider from the browser.

Groundedness and citations

Ask:

• Is there a distinct source of citable enterprise evidence?
• Does the source relationship mention metadata or provenance?
• Can a reviewer see that the platform, not the model alone, is responsible for producing grounded answers?

The platform should remain accountable for assembling evidence, attaching citations, and displaying uncertainty or abstention when evidence is insufficient.

Privacy and provider governance

Ask:

• Is it apparent which model provider is within the AWS boundary and which is outside it?
• Does the diagram avoid implying that all enterprise data is sent to all providers?
• Does the external-provider relationship communicate policy control and minimum necessary context?

The context diagram cannot prove safe handling, but it identifies where privacy, procurement, legal, security, and data-governance review must concentrate.

Resilience and operating model

Ask:

• Is a model provider dependency visible rather than hidden inside a generic “AI” box?
• If an external provider is planned, is it clear that it is a distinct dependency with its own availability, cost, and contractual risks?
• Does the diagram provide enough context to assign owners for data sources, identity, the platform, and model-provider governance?

This is where the diagram becomes useful in executive discussions. It exposes the cross-functional operating model needed for a trustworthy system, rather than presenting AI as a self-contained application feature.

---

Produce a versioned, reviewable artifact

Your capstone deliverable is a single-page diagram accompanied by a short set of assumptions. Use this checklist before sharing it:

• Title: “Enterprise Intelligence Platform — System Context.”
• Scope statement: one sentence describing the platform’s decision-support purpose.
• Primary person: named by role, not “User.”
• Platform: one central system-of-interest box with a concise responsibility statement.
• Enterprise data: one or two grouped external systems, named by source category and ownership.
• Identity: the enterprise authentication and claims source is shown.
• AI providers: named separately, including the difference between AWS-managed and external providers where applicable.
• AWS boundary: labelled with the account and Region intent, without overstating guarantees.
• Relationships: labelled with business-relevant interaction purposes and significant control language.
• Assumptions: record what is provisional, such as “external provider fallback is optional” or “systems of record are excluded from the pilot.”
• Legend: if colors, line styles, or special boundaries have meaning, explain them directly on the page.
• Version and date: architecture diagrams are decision artifacts and should be traceable.

If you want to turn the sketch into diagram-as-code later, Structurizr’s tutorial gives a lightweight way to define people, software systems, relationships, and a system-context view without committing to a visual tool.

---

Key takeaways

• A system context diagram is a high-level map of the system being built, its users, and the external systems it directly relies on.
• Keep the Enterprise Intelligence Platform as one central system at this level; internal APIs, services, databases, and deployment units come later.
• Treat enterprise knowledge sources, systems of record, identity, and model providers as distinct dependencies when they have distinct owners, permissions, or risks.
• Add an AWS account and Region boundary to communicate hosting intent, but do not mistake it for proof of data residency, privacy, or compliance.
• Make relationships specific enough to expose control requirements: authorized retrieval, access claims, source metadata, minimum necessary model context, and provider policy.
• Use the previous lesson’s quality attributes as a review lens: the diagram should reveal where authorization, grounding, privacy, freshness, and resilience must be designed and governed.

Next, the course moves into the hands-on software engineering refresher, beginning with configuring a local workspace for Python, TypeScript, containers, and Git.