Reconstruct the System From Evidence

A final architecture diagram should not be a drawing made from memory.

It should be a compressed representation of evidence collected throughout the course.

Start with required functions

For the fictional Northstar system, define the functions that must survive:

• public viewers can read approved status information;
• operators can update match notes;
• privileged role changes require approval;
• logs support investigation and troubleshooting;
• backups support recovery;
• the system can recover from a bounded configuration or identity failure.

Every component in the final architecture should connect to at least one required function, control, dependency, or evidence source.

Build an inventory with provenance

Do not write only:

web server
database
firewall

Build a table:

Now the architecture can be challenged.

Add identity and authority to the diagram

A network line is not enough.

Concept flow

Identity and permission are different questions

1. CLAIMI am this user or service
   prove
2. AUTHENTICATEverify the identity claim
   evaluate
3. AUTHORIZEdecide what this identity may do
   access
4. RESOURCEfile, service, data, or action
   record
5. AUDITpreserve evidence of the decision

Show which identity makes the claim, what proves the claim, what action that identity is allowed to perform, which resource receives the action, and where the decision is recorded.

For example, an operator may authenticate into a status session, the status service may act with a service identity, and the match database may accept only the authorized update path. A coach-admin role-management action should cross a different privileged boundary.

Authority flows through the system just like data does.

Add evidence paths

A control that cannot be observed is difficult to verify.

For important actions, mark evidence such as:

• authentication event;
• authorization decision;
• request ID;
• database audit event;
• config-change record;
• service-health heartbeat;
• backup result;
• detection alert.

Now your architecture contains system behavior and how you know about it.

Trust boundaries should name the assumption change

Instead of a generic dashed line, label boundaries:

public/untrusted client → application input boundary
operator identity → authorization boundary
application → database service-identity boundary
host → centralized log pipeline
production-like dataset → backup/recovery store
admin role → privileged change boundary

This makes the diagram useful during review.

Dependency chains reveal single points of failure

Suppose:

status service
  ↓
database
  ↓
storage

and both status serving and role administration depend on the same database.

If that database fails, multiple functions fail together.

Architecture review should identify those shared dependencies.

The same applies to defensive controls:

auth logs + role-change alert + investigation timeline
                 ↓
         same log collector

If the collector fails, several “layers” may disappear together.

Activity: build the evidence-backed architecture

Use your prior artifacts from Weeks 1–16.

Include at minimum:

• 8 components/assets;
• 5 required functions;
• 5 data/action flows;
• 4 trust boundaries;
• 4 identities/roles;
• 5 evidence sources;
• 3 defensive controls;
• 2 recovery dependencies.

For every item, note which week/artifact supports it.

Separate unknown from missing

If you cannot prove a relationship, mark it:

UNKNOWN: database backup encryption state
EVIDENCE NEEDED: backup configuration + restore/test record

Do not fill the gap with a confident assumption.

Architecture review is allowed to reveal that the architecture is incompletely documented.

Build the first section of your Defensive Architecture Review

Include:

1. system purpose;
2. required functions;
3. architecture diagram;
4. asset/component inventory;
5. identity/authority relationships;
6. trust boundaries;
7. evidence sources;
8. shared dependencies; and
9. known unknowns.

Lesson 2 tests whether the controls in that architecture actually cover the failure paths you care about.