Security architecture for complex public-facing infrastructure, in four variants: captive data centre, AWS, Azure and GCP

Executive summary

This paper sets out the design considerations for an infrastructure estate that must do three things at once: serve consumers on the public internet, serve business customers who log in with their own corporate identities, and receive a steady one-way flow of operational data from enterprise clients so that it can be monitored and analysed on their behalf. The three workloads have different threat profiles, different trust relationships and different regulatory exposure, and the central design problem is to host them on shared foundations without letting the weakest of them become the attack path into the strongest.

The approach taken here is to fix the architecture first and the hosting model second. Section 2 characterises the workloads and their threats. Section 3 sets out a six-zone reference architecture and the principles that hold it together, of which the most important is that the ingestion path from enterprise clients is one-way by construction, not by configuration. Section 4 works through the cross-cutting decisions that every variant must make: identity, segmentation, data protection, tenant isolation, secrets, supply chain, observability, resilience and compliance. Sections 5 to 8 then map the same architecture onto a captive in-house data centre and onto AWS, Azure and GCP, naming the native constructs that implement each zone and each control and being candid about where each platform is strong and where it is merely adequate. Section 9 compares them side by side and Section 10 gives a decision frame, including the increasingly common answer that the right estate is two of the four.

The one sentence version

Segment by trust, isolate by tenant, make the ingestion path physically or cryptographically incapable of flowing backwards, put identity at every boundary, and choose the hosting model for its isolation primitives and its operating burden rather than for its feature list.

2. The workload profile and what it implies

A security architecture is a response to a threat model, and a threat model begins with who is on the other side of each connection. This estate has three distinct populations, and it is worth being precise about them before any zone is drawn.

2.1 Three populations, three trust relationships

The third row is the one that shapes the whole design. In a B2C or B2B relationship a compromise of the estate harms the estate and its users. In a B2B2C monitoring relationship a compromise of the estate is, from the client's chief information security officer's point of view, a supply-chain incident inside their own perimeter, and the contract they signed will say as much. The architecture therefore has to make two promises that go beyond the usual: that data can only ever flow from the client into the estate, and that a client's data is isolated from every other client's with a boundary the client can be shown, not merely told about.

2.2 Regulatory and contractual exposure

The three workloads also attract different obligations. Consumer data brings data-protection law in every jurisdiction the consumers live in, and payment card data brings PCI DSS if card details are handled rather than tokenised at the edge. Business customers will ask for SOC 2 Type II or ISO/IEC 27001 and will send questionnaires. Enterprise ingestion clients will go further: they will want to see the isolation boundary, the encryption key arrangements, the incident-notification clauses and often a right to audit. The estate should be designed so that these are answerable from the architecture rather than from a policy document, which in practice means the boundaries have to be real constructs that can be inspected and evidenced.

3. Reference architecture

The architecture is organised into six zones. Four of them carry traffic; two of them carry control. The same zones appear in every hosting variant; what changes is the construct that implements each one.

3.1 The six zones

•     Zone 1, Edge. The only zone with a public address. It absorbs volumetric attacks, terminates TLS, enforces the web application firewall and bot policy, and routes to Zone 2. Nothing in Zone 1 holds data or business logic.

•     Zone 2, Application. API gateway, authentication and authorisation, and the B2C and B2B services themselves. Every request arrives with an identity established at the gateway; no service trusts a request because of where it came from.

•     Zone 3, Data. Transactional stores, the analytics platform and the key and secrets infrastructure. Reachable only from Zone 2 and Zone 4 through defined service identities, never from the edge and never from an operator laptop.

•     Zone 4, One-way ingestion. A private entry point per enterprise client, a write-only landing area, a quarantine-and-validation stage, and a curated store that feeds the analytics platform. Per-client isolation runs the length of the zone. There is no path from Zone 4 back to any client.

•     Zone 5, Management plane. Privileged access, infrastructure-as-code pipelines, secrets distribution, patching and break-glass. This is the zone whose compromise is total, and it is treated accordingly: separate identities, hardware-backed authentication, session recording, and no standing access.

•     Zone 6, Security operations. Telemetry collection, detection, the security information and event management platform, response tooling and evidence storage. It reads from everywhere and writes to nothing except its own stores.

3.2 Principles that hold the zones together

Eight principles are load-bearing. They are stated here once and applied in every variant.

1.   Identity is the perimeter. Network position grants nothing. Every call between zones carries a workload identity that is issued, rotated and revoked centrally, and every policy is written in terms of that identity.

2.   Segment by trust, then by tenant. Zones separate populations with different trust; within a zone, tenants are separated by the strongest boundary the platform offers, which for B2B2C clients means a boundary with its own blast radius.

3.   One-way by construction. The ingestion path is made incapable of reverse flow through the combination of ingress-only network policy, write-only identities and, where the data warrants it, a physical unidirectional gateway. Configuration alone is not enough, because configuration drifts.

4.   Encrypt everything, hold the keys deliberately. Encryption in transit and at rest is assumed. The design decisions are about key hierarchy, who can use which key, and which keys a client holds or can revoke.

5.   Immutable and reproducible. Infrastructure is declared in code and deployed by pipeline. Nothing is changed by hand in production; drift is detected and reverted.

6.   Least privilege with an expiry. Human privilege is granted just in time and expires; machine privilege is scoped to a single purpose. Standing administrative access does not exist outside break-glass.

7.   Assume compromise, bound the blast radius. Each zone and each tenant is designed so that its compromise is contained and detectable. The question asked of every design choice is what an attacker who already holds this component can reach.

8.   Evidence over assertion. Every control produces a record that a client or an auditor can inspect. If a boundary cannot be evidenced it is not a boundary.

4. Cross-cutting design considerations

The decisions in this section are made once for the estate. Each has a platform-native answer in Sections 5 to 8, but the reasoning is the same everywhere.

4.1 Identity: three directories, not one

The three populations need three identity systems, and conflating them is the most common early mistake. Consumers belong in a customer identity and access management system built for scale, self-service, risk-based step-up and breached-credential checking. Partner staff should be federated from the partner's own identity provider through SAML or OpenID Connect, so that the partner's joiner-mover-leaver process governs access and the estate never holds partner passwords. Workforce and machine identities belong in the estate's own directory with hardware-backed multi-factor authentication for humans and short-lived certificates or tokens for workloads. The three systems meet only at the API gateway, which normalises them into a single internal token format that carries the population, the tenant and the granted scopes.

Authorisation follows the same shape. Coarse decisions, such as which population may reach which service, are made at the gateway. Fine decisions, such as which tenant's records a request may read, are made in the service against the tenant claim in the token and enforced again at the data layer. Two layers are deliberate: a bug in one is caught by the other.

4.2 Network segmentation

Zones are implemented as separately routed networks with a policy enforcement point between each pair. Default deny applies in both directions; each permitted flow is named, owned and reviewed. Within Zone 2 and Zone 3, micro-segmentation at the workload level replaces the flat internal network: a service can reach the two or three services it depends on and nothing else. East-west traffic is encrypted and authenticated with mutual TLS issued by the workload identity system, so that a compromised host cannot impersonate its neighbours.

Two flows deserve explicit mention because they are the ones most often left implicit. Egress from every zone is proxied and allow-listed by destination, which is what stops data exfiltration and command-and-control callbacks. And the management plane reaches production only through a hardened bastion or a privileged-access service, never through a route that a workload could also use.

4.3 Tenant isolation for B2B2C clients

Three isolation models are available and the choice is the most consequential one in the ingestion design.

The recommendation for enterprise ingestion is siloed at the network entry and the landing store, bridged through validation and curation, and at minimum bridged in the analytics store with a per-client encryption key. That gives each client its own blast radius where the data first arrives and its own key throughout, while keeping the processing tier shared enough to operate. The largest or most regulated clients can be promoted to fully siloed without changing the architecture, because the boundary constructs are the same ones, applied at one more layer.

4.4 Making the ingestion path one-way

The one-way property is assembled from independent controls so that no single failure reverses it.

•     The client initiates. Data is pushed by the client over an outbound connection they hold the credential for, or pulled by the estate only through a mechanism the client can unilaterally sever. The estate never holds a credential that grants access into the client's environment.

•     No public endpoint. The entry point is reachable only over a private connection: a private-link style endpoint, a dedicated circuit, or a site-to-site tunnel terminated in a client-specific network. Public reachability turns a client's ingestion path into the estate's attack surface.

•     Write-only landing. The identity presented by the client can create objects and nothing else: no list, no read, no delete. The landing store is versioned and write-once for a retention window, so that neither the client's compromise nor the estate's can silently alter what arrived.

•     Quarantine before trust. Nothing leaves the landing store without malware and content scanning, schema and size validation, and classification for personal data. Rejects are logged and reported; they are never silently dropped.

•     No return route. The curated store and the analytics platform have no network path to any client environment and no identity that could be used to reach one. Reports and alerts go back to clients over a separate outbound channel, typically a portal in Zone 2 or an email or webhook delivery from a dedicated egress.

•     Physical enforcement where warranted. For clients whose data originates in operational technology or regulated environments, a hardware unidirectional gateway, commonly a data diode, at the client side makes reverse flow physically impossible rather than merely prohibited. The estate should be able to accept that pattern without modification, because it is the one such clients will ask for.

Why configuration is not enough

Every cloud platform can express 'this role may only write to this bucket'. The difficulty is that the same platform lets a sufficiently privileged operator widen that policy in one line, and the widening is indistinguishable in the audit log from routine change. One-way must therefore be layered: a network control that has no reverse route, an identity control that has no read permission, an organisational guard-rail that prevents either from being loosened without a second approver, and a detective control that alerts if the guard-rail itself is touched.

4.5 Data protection and key management

The key hierarchy has three tiers. Root keys live in a hardware security module and never leave it. Key-encryption keys, one per environment and one per client for ingested data, are wrapped by the root. Data-encryption keys are generated per store or per object and wrapped by the appropriate key-encryption key. The practical consequences are that revoking a client's key-encryption key renders their data unreadable without touching the data, which is the crypto-shredding that enables clean offboarding; that a client who wishes to hold their own key can be accommodated by pointing the wrap at a key they control; and that key usage is logged per key, which is the evidence clients ask for.

Field-level encryption or tokenisation applies to the highest-sensitivity fields, payment instruments and national identifiers among them, so that the transactional store never holds them in the clear and a database compromise yields tokens. Data residency is decided per population and enforced by placing stores in the required region and preventing replication elsewhere by policy.

4.6 Secrets, supply chain and the build pipeline

Secrets are issued from a central vault, injected at runtime, rotated automatically and never stored in code, images or configuration. Workload identity should remove most static secrets altogether: a service authenticates to a store with a certificate it was issued at start-up, not a password it was given at build time.

The software supply chain is treated as a zone in its own right. Base images come from a curated internal registry, are scanned, signed and rebuilt on a schedule. Application builds run in ephemeral, isolated runners, produce a software bill of materials, and are signed so that the runtime admits only artefacts with a valid signature from the pipeline. Third-party dependencies are pinned and mirrored. The pipeline's own credentials are the most valuable in the estate and are scoped, short-lived and monitored accordingly.

4.7 Observability and detection

Zone 6 collects four classes of telemetry: control-plane audit logs from the hosting platform, network flow and DNS logs from every zone, application and access logs from the gateway and services, and host and container runtime signals. All of it lands in immutable storage with a retention policy that satisfies the longest contractual requirement, and a subset streams to the detection platform. Detection content is written against the architecture: a read from a landing store, an egress attempt from Zone 3, a policy change on an ingestion boundary, a break-glass login, or a workload identity used from an unexpected place are each a rule with an owner and a tested response. Security operations has read access everywhere and write access nowhere, so that its own compromise cannot become a change.

4.8 Resilience, recovery and the ransomware case

Availability is a security property for a public-facing estate. Zones 1 to 3 run across at least two failure domains with automated failover; the ingestion zone tolerates the estate being unavailable by having clients buffer and retry, which the contract should require. Backups are immutable, held under a separate identity boundary that production credentials cannot reach, and restored on a schedule to prove they work. The recovery plan is written for the ransomware case specifically: an attacker who has held administrative access for weeks, has encrypted or corrupted primary stores, and has attempted to reach the backups. Recovery time and recovery point objectives are set per population, and the B2B2C clients' objectives are written into their contracts because they will be asked about.

4.9 Compliance as a by-product

Where the architecture is real, compliance is largely a matter of mapping. A controls matrix maps each requirement in ISO/IEC 27001, SOC 2, PCI DSS and the applicable data-protection regimes to the construct that satisfies it and the evidence that construct emits. Continuous compliance tooling checks the constructs against the declared configuration and raises drift as an incident. The goal is that a client questionnaire is answered by pointing at the matrix rather than by writing prose, and that an audit is a demonstration rather than a scramble.

5. Variant A: the captive in-house data centre

A captive facility offers the strongest physical assurances and the fullest control over every layer, and demands that the organisation supply every capability the cloud providers otherwise bundle. It is the right choice where data sovereignty or contractual terms preclude a shared platform, where the operating team already exists, or where the ingestion clients are themselves in operational-technology environments that expect a physical unidirectional boundary.

5.1 Physical and environmental

A facility designed to Uptime Institute Tier III or equivalent, with concurrently maintainable power and cooling, dual utility feeds, generator and fuel for a defined autonomy, and physical security in concentric layers: perimeter, building, hall, cage and rack, each with its own access control and logging. Two-person rules apply to the hall that houses the hardware security modules and the ingestion landing infrastructure. Environmental monitoring, fire suppression and water detection feed the same security-operations platform as the logical telemetry, because a physical event is a security event.

5.2 Network fabric

A leaf-spine fabric with the six zones implemented as separate virtual routing and forwarding instances, connected only through a pair of next-generation firewalls in an active-passive cluster with a second pair for the ingestion zone so that its policy set is administered separately. The edge zone terminates in a demilitarised segment behind a DDoS-scrubbing service contracted from an upstream provider, because a captive facility cannot absorb a volumetric attack on its own transit. Web application firewall and bot mitigation run either as appliances in the edge or, more commonly, as a cloud-delivered service in front of the facility, which is the first place a captive design becomes hybrid.

Client ingestion arrives over dedicated circuits or site-to-site tunnels terminated on a per-client interface in the ingestion firewall, or through a hardware data diode where the client requires it. Micro-segmentation within zones is delivered by the virtualisation platform or a Kubernetes network policy engine.

5.3 Compute, platform and identity

A virtualisation cluster per zone, hosting Kubernetes clusters for the application and ingestion tiers, with node images built and signed by the internal pipeline and booted with measured boot and a hardware root of trust. Workload identity is provided by a SPIFFE-style issuer integrated with an internal certificate authority backed by the hardware security modules. Workforce identity is an on-premises directory federated to a modern identity provider for conditional access; consumer identity is a self-hosted or hosted customer identity platform; partner federation terminates at the same gateway as in every variant.

5.4 Data, keys and ingestion

Transactional stores on dedicated storage with encryption at rest keyed from the hardware security modules. The landing store for ingestion is an object-storage platform with write-once-read-many enforcement and per-client buckets whose credentials are create-only. Validation runs in the ingestion Kubernetes cluster with no route to the application zone; the curated store sits in the data zone and is reached from the analytics platform through a service identity. The physical separation available here is a genuine advantage: the ingestion landing can live on hardware with no network adjacency to anything but the validation tier.

5.5 Operations and security operations

Everything that a cloud provider runs as a service must be run here: patch management, vulnerability scanning, certificate lifecycle, backup, the security information and event management platform, the vault, the registry and the pipeline runners. A privileged-access workstation model with a bastion, session recording and just-in-time elevation is mandatory. The staffing implication is the largest hidden cost of the captive variant: a twenty-four-hour security-operations rota, platform engineering for the Kubernetes and virtualisation layers, and network and facilities engineering, none of which can be part-time.

Where the captive variant is strong, and where it is not

Strong: physical isolation of the ingestion path, sovereignty of every byte, hardware-enforced one-way flow, and the ability to show a client the rack. Weak: DDoS absorption at internet scale, elasticity for B2C peaks, the breadth and speed of managed security services, and the sheer number of specialist roles it takes to operate. Most captive designs end up hybrid at the edge for the first reason and consider hybrid for the second.

6. Variant B: AWS

The AWS mapping is built on the account as the hard isolation boundary and on the landing-zone pattern that the provider's own guidance recommends. The design below uses native constructs throughout; equivalent third-party products exist for most and the reasoning does not change.

6.1 Organisation and landing zone

A single organisation with organisational units for security, infrastructure, workloads and, critically, ingestion. Service control policies at the organisational-unit level express the guard-rails that no account administrator can loosen: regions that may be used, services that may not, the prohibition on public object storage, the requirement that the ingestion landing roles carry no read permission. A dedicated security account holds the aggregated audit trail, the detection service administrator delegation and the immutable log archive; a dedicated log-archive account holds the logs themselves under an identity that production cannot assume. Control Tower or an equivalent landing-zone framework provisions accounts from a template so that a new B2B2C client silo is a pipeline run rather than a project.

6.2 The zones in AWS constructs

6.3 Making ingestion one-way in AWS

The layering from Section 4.4 maps cleanly. The network layer is a PrivateLink endpoint service that the client connects to from their own VPC or, for on-premises clients, Direct Connect into a client-specific VPC; there is no internet gateway in the ingestion account. The identity layer is a role the client assumes, or an access point they write through, whose policy grants only PutObject on their prefix; the bucket policy additionally denies GetObject and ListBucket to every principal except the validation function. Object Lock in compliance mode makes the landing immutable for the retention window. The organisational guard-rail is a service control policy on the ingestion OU that denies any modification of the landing bucket policies and any creation of internet or NAT gateways. The detective control is a Config rule and a CloudTrail alarm on any attempt at either. Cross-account access from the analytics account reads the curated bucket through a resource policy and never the landing bucket.

6.4 Where AWS is strong and where care is needed

The account boundary is mature and well understood, the guard-rail mechanism is expressive, and the edge protection is among the strongest available. Care is needed with the breadth of the identity policy language, which makes it easy to write permissions that are broader than intended; with the number of accounts a siloed design produces, which needs the landing-zone automation to be treated as production code; and with cost visibility across many accounts, which needs tagging discipline from the first day.

7. Variant C: Azure

The Azure mapping rests on the subscription as the isolation boundary, management groups as the policy hierarchy, and the hub-and-spoke network pattern that the provider's Cloud Adoption Framework landing zones prescribe. Its distinguishing strength is the identity platform, which is the same system many enterprise clients already use for their own workforce.

7.1 Tenant, management groups and policy

A single Entra tenant with a management-group hierarchy mirroring the organisational units of the AWS design: platform, security, workloads and ingestion. Azure Policy assigned at management-group level provides the guard-rails: allowed regions, denied public IP creation in the ingestion group, required encryption with customer-managed keys, required private endpoints for storage and databases. Policy in deny mode is the equivalent of service control policies; policy in deploy-if-not-exists mode additionally remediates drift, which is a capability worth using for the diagnostic settings that route every resource's logs to the central workspace.

7.2 The zones in Azure constructs

7.3 Making ingestion one-way in Azure

The network layer is a Private Link Service exposed from the client's spoke and consumed by the client from their own virtual network, or an ExpressRoute circuit landing in that spoke; the spoke's route table sends everything else to the hub firewall, which denies it. The identity layer is a storage container whose only client-facing credential is a user-delegation shared access signature with create permission and a short expiry, issued by a service that has no other capability; the container has an immutable, time-based retention policy. The organisational guard-rail is a policy assignment on the ingestion management group that denies public network access on storage, denies NAT gateways and public IPs, and denies modification of immutability policies. The detective control is a Sentinel analytic rule on policy exemptions and on any role assignment change within the ingestion group. The analytics subscription reaches the curated store through a private endpoint and a managed identity with reader role on that store alone.

7.4 Where Azure is strong and where care is needed

Identity is the strength: conditional access, privileged identity management and cross-tenant federation are more integrated here than anywhere else, and many enterprise ingestion clients will be able to federate to the estate from a directory they already run. The policy engine's remediation mode is a genuine operational advantage. Care is needed with role-based access control scope, where a role assigned at subscription level quietly applies to every resource beneath it; with the hub firewall as a shared chokepoint, which must be sized and made highly available; and with the default network posture of some platform services, which is public until a private endpoint is configured and must be locked by policy rather than by memory.

8. Variant D: Google Cloud

The GCP mapping uses the project as the isolation boundary, the organisation and folder hierarchy for policy, and Shared VPC for the network. Its distinguishing construct is VPC Service Controls, which places a perimeter around a set of projects and services such that data cannot leave the perimeter even when an identity holds permission to read it. For the one-way ingestion problem this is the closest any platform comes to a logical data diode.

8.1 Organisation, folders and organisation policy

A single organisation with folders for platform, security, workloads and ingestion. Organisation policy constraints at folder level provide the guard-rails: restricted resource locations, domain-restricted sharing so that identities from outside the organisation cannot be granted roles, the prohibition on external IP addresses for compute in the ingestion folder, and uniform bucket-level access enforced everywhere. Project creation is automated through a project factory so that a client silo is a pull request.

8.2 The zones in GCP constructs

8.3 Making ingestion one-way in GCP

The network layer is a Private Service Connect published service that the client consumes from their own VPC, or a Cloud Interconnect attachment into a client-specific project; the project has no external IP addresses by policy and no Cloud NAT. The identity layer is a service account the client impersonates, or a signed URL the client is issued, carrying only the object-creator role on their bucket; bucket lock makes the landing immutable. The organisational guard-rail is where GCP differs: a VPC Service Controls perimeter around the ingestion folder means that even a principal with storage-reader permission cannot copy data out of the perimeter to anywhere that is not in the explicit egress rule, which names the curated project and nothing else. The detective control is a Security Command Center finding and a log-based alert on any change to the perimeter or its egress rules, plus the access-approval requirement for provider-side access. The analytics project sits outside the ingestion perimeter and is reached through the single egress rule.

8.4 Where GCP is strong and where care is needed

VPC Service Controls is the standout for this workload; nothing else provides a data-exfiltration boundary that survives an over-privileged identity. BigQuery's native row and column security suits the tenant-partitioned analytics store well, and the organisation-level log sink protects the audit trail structurally. Care is needed with the perimeter itself, which is powerful but easy to misconfigure into a service outage; with the smaller catalogue of managed security services relative to the other two hyperscalers, which may mean a third-party SIEM sooner; and with the partner-federation story, which is capable but less turnkey than Azure's.

9. Side-by-side comparison

10. Choosing, and the case for two

The choice is rarely between four equals. The questions that decide it are, in order of weight:

1.   Does any client or regulator require physical control of the ingestion path? If so, the captive variant is in scope for that path at least, and the question becomes whether the rest of the estate should follow it or sit in a cloud with the ingestion zone on premises.

2.   Which identity system do the B2B and B2B2C clients already run? Federation is smoother when the estate and the client share a platform, and a majority of enterprise clients on one directory tilts the choice.

3.   How many ingestion clients, and how regulated? Tens of clients with strong isolation demands favour the platform whose data-exfiltration boundary is strongest and whose silo automation is most mature.

4.   What does the organisation already know how to operate? Every variant is secure in the hands of a team that understands it and insecure in the hands of one that does not. Existing skills are a legitimate first-order input.

5.   Where are the consumers, and what are the residency rules? Region availability and sovereign options narrow the field for some markets.

Increasingly the answer is two of the four. The pattern that recurs is a hyperscaler for the public-facing B2C and B2B zones, where elasticity and edge protection matter most, with the ingestion zone either in a second hyperscaler chosen for its isolation constructs or in a captive facility chosen for physical assurance. The cost is a second operating model and a cross-platform identity and observability layer; the benefit is that the estate's public attack surface and its most sensitive client data are not on the same control plane, which is an argument that lands well with enterprise clients' security teams. If that path is taken, Zone 6 must be genuinely unified, because a security operation that sees only half the estate is not a security operation.

A caution on feature comparison

Provider capability lists change quarterly and this paper will date. What does not date is the shape of the argument: identify the hard isolation boundary, the guard-rail that no administrator can loosen, the data-exfiltration boundary, and the evidence each produces. A platform that answers those four well is a candidate; one that answers them with 'configure it carefully' is not, whatever else it offers.

11. Conclusion

An estate that serves the public, serves business customers and monitors enterprise clients' data has to be three things at once, and the temptation is to design three estates. The alternative set out here is one architecture with six zones, whose boundaries are real constructs that can be inspected, and whose most sensitive path, the one-way ingestion of client data, is made incapable of reverse flow by layering network, identity, organisational and detective controls rather than by trusting any one of them. That architecture maps onto a captive facility and onto each of the three major clouds with different constructs but the same reasoning, and the choice among them turns on isolation primitives, identity fit, sovereignty and the organisation's ability to operate what it chooses. Choose for those, evidence every boundary, and the compliance, the client questionnaires and the audit follow from the design rather than competing with it.

Appendix A. Control checklist by zone

A condensed list for design review. Each line should be answerable with the name of a construct and the location of its evidence.