Mission
State what business or service outcome matters and why the review exists.
Northbridge example: Maintain trustworthy access to the fictional Northbridge Learning Portal while protecting student-service data and administrative functions.
High School AdvancedA20.2Advanced Capstone
Lesson A20.2
Capstone Scenario Briefing
Complex cybersecurity cases become unreliable when people start with a preferred explanation. A professional briefing establishes what the mission is, what evidence exists, what the evidence can prove, which questions matter, and where uncertainty must remain visible.
This lesson introduces the fictional Northbridge capstone case and creates the Case Charter and Evidence Inventory that every later A20 phase will reuse.
Lesson Progress
Capstone Scenario Briefing
High School Advanced • A20: Advanced Capstone • Lesson 2 of 10
20% complete
Readiness Check
Before You Start
0/4 ready
Professional Hook
A Briefing Is a Decision Boundary, Not a Story About What You Think Happened
A weak briefing begins with a conclusion and selects evidence that fits it. A strong briefing begins with the mission, scope, evidence, source limitations, stakeholders, constraints, and unanswered questions. Conclusions come later.
This matters because A20 will move through architecture, monitoring, incident response, cloud, identity, privacy, risk, and executive communication. If every phase begins with a different definition of the case, the final capstone will contradict itself.
Learning Objectives
Five Outcomes for A20.2
1
Explain why a professional capstone begins with a case charter and evidence inventory before responders, architects, or risk owners make strong conclusions.
2
Define mission, scope, stakeholders, assets, decisions, constraints, assumptions, unknowns, exclusions, and stop conditions for a fictional cybersecurity case.
3
Classify supplied records by evidence source, purpose, provenance, source health, freshness, reliability, limitations, and the decisions they can support.
4
Separate confirmed facts from interpretations, hypotheses, assumptions, findings, risks, incidents, exceptions, recommendations, decisions, and unresolved questions.
5
Create a Capstone Case Charter and Evidence Inventory that gives later A20 phases a consistent, safe, and defensible starting point.
Case Charter
Define the Case Before You Analyze It
The case charter gives every later reviewer the same starting point. It does not predict the answer. It explains what matters, what is included, who owns the decisions, and which limitations prevent overconfidence.
Primary decision
Identify the decision the capstone team must support rather than starting with a preferred technical solution.
Northbridge example: Determine what is confirmed about the service interruption and unusual administrative activity, what remains uncertain, and which defensive actions are justified.
Scope
Name the fictional systems, identities, data, time window, evidence, and activities included in the review.
Northbridge example: Portal application, identity service, worker service, protected data store, monitoring sources, recovery records, and selected governance evidence.
Exclusions
State what the case does not attempt to prove or review.
Northbridge example: No real infrastructure, no external organizations, no live scanning, no credential testing, no offensive validation, and no claims about systems outside the synthetic case.
Stakeholders
Identify who needs the result and who owns the services, controls, risks, data, recovery actions, and communications.
Northbridge example: Application owner, identity owner, monitoring owner, cloud owner, privacy reviewer, risk owner, incident lead, and executive sponsor.
Constraints
Record limitations that shape what the review can safely conclude.
Northbridge example: Some synthetic telemetry is delayed, one recovery record is stale, and only approved case evidence may be used.
Assumptions
Record necessary but unconfirmed statements separately from facts.
Northbridge example: The fictional architecture inventory is assumed current unless another supplied record contradicts it.
Unknowns
List unanswered questions that could materially change the decision.
Northbridge example: Whether one privileged action was expected during the approved change window remains unresolved.
Evidence Inventory
Know What Each Source Can Support—and What It Cannot
Evidence inventory is more than a list of logs. A professional record captures purpose, provenance, source health, freshness, reliability, limitations, and the decisions a source can support.
Architecture inventory
Supports
Intended system relationships, trust boundaries, dependencies, service roles, control placement, and recovery paths.
Does not prove
That every deployed component currently matches the design or that every control is effective.
Source health
Current design record with one dependency marked for review.
Identity records
Supports
Authentication timing, identity type, role assignment, account state, approval context, and selected lifecycle events.
Does not prove
Physical identity, complete user intent, or authorization for every later action.
Source health
Current except for a short synthetic ingestion delay during the case window.
Application logs
Supports
Request timing, application errors, worker activity, job state, service responses, and selected business events.
Does not prove
Complete endpoint behavior, human intent, or every network path.
Source health
Available with one four-minute gap during service restart.
Monitoring alerts
Supports
Which synthetic detection conditions fired, severity, confidence, source references, and triage context.
Does not prove
That an alert is a confirmed incident, complete scope, or root cause.
Source health
One source was delayed; alert absence in that window has reduced evidentiary value.
Change records
Supports
Approved purpose, planned timing, owner, expected systems, rollback plan, and documented maintenance context.
Does not prove
That every observed action was part of the approved change or that the change caused later symptoms.
Source health
Current and signed by the fictional service owner.
Service-health records
Supports
Availability, latency, queue state, dependency health, restart timing, and recovery checkpoints.
Does not prove
Whether a security event caused the operational condition.
Source health
Current for the primary portal, partial for one background dependency.
Risk and policy records
Supports
Expected controls, business importance, risk ownership, exception state, review requirements, and decision authority.
Does not prove
Current implementation effectiveness unless supporting control evidence is present.
Source health
Current policy; one risk review is due soon.
Recovery records
Supports
Backup coverage, restoration ownership, recovery objectives, prior validation, and dependency requirements.
Does not prove
Current restoration success if the most recent exercise is stale.
Source health
Backup status current; full restoration evidence older than the preferred review window.
Fake Dashboard
Northbridge Capstone Briefing Dashboard
Synthetic case-state snapshot before architecture, detection, or response decisions
Primary assets
7
Portal, identity, data, worker, queue, monitoring, recovery
Evidence classes
8
Architecture through recovery records
Confirmed facts
6
Facts are preserved separately from interpretation
Material unknowns
5
Each is connected to a decision and evidence need
Fake SOC Alert
Correlation Mistaken for Root Cause
Source: Synthetic Northbridge Case Review • Time: 09:32
A draft briefing says the 09:11 privileged action caused the portal interruption because it occurred shortly before elevated errors.
Defensive recommendation: Reclassify causation as a hypothesis. Preserve the privileged action as a confirmed fact, compare it with approved change scope, normalize the timeline, and keep competing explanations visible.
Fake Log Panel
Northbridge Synthetic Briefing Records
training-log-viewer.log
[09:05] CHG-NB-220 approved maintenance window begins [09:08] monitoring collector backlog starts increasing [09:11] privileged administrative action recorded by identity and application sources [09:13] worker queue latency rises above fictional baseline [09:14] portal error rate begins increasing [09:17] monitoring collector remains delayed; negative evidence confidence reduced [09:21] worker-service restart approved by fictional service owner [09:25] queue health improves [09:29] portal error rate returns to normal range [09:34] recovery checkpoint confirms portal availability; full causal analysis remains open
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Evidence Analysis 1 — Fact or Cause?
The action is present in two synthetic evidence sources.
It occurred during an approved maintenance window.
Portal errors began three minutes later.
The monitoring source was delayed and a queue dependency was also degrading.
The approved change task does not yet confirm whether this exact action was expected.
What is the strongest conclusion about the 09:11 privileged action during the initial briefing?
Reasoning States
Do Not Collapse Different Kinds of Statements Into One Category
Advanced case quality depends on language discipline. A fact can support a hypothesis. A hypothesis may later become a finding. A finding may create a risk. A risk may influence an incident decision. These are connected, but they are not interchangeable.
Fact
A statement directly supported by the supplied evidence at the stated confidence.
Example: A privileged administrative event was recorded at 09:11.
Interpretation
A reasoned meaning assigned to one or more facts without claiming more certainty than the evidence supports.
Example: The privileged action may be relevant because it occurred during the maintenance window and before service degradation.
Hypothesis
A testable possible explanation that competes with other explanations.
Example: The service interruption may have resulted from an approved change interacting with a queue dependency.
Assumption
A statement temporarily accepted so work can proceed, but not independently confirmed.
Example: The provided architecture inventory is assumed current for the capstone.
Finding
A defensible conclusion about a condition that matters to the review.
Example: Monitoring delay reduces confidence in negative evidence during the affected period.
Risk
A possible adverse outcome evaluated through likelihood, impact, controls, ownership, and residual exposure.
Example: Concentrated monitoring dependence could delay detection and response during future service disruptions.
Incident
A governed response state for an event or condition requiring coordinated handling under defined criteria.
Example: The current briefing does not yet prove whether the case meets the fictional incident threshold.
Exception
An approved deviation from an expected requirement, with rationale, owner, risk, limits, and review.
Example: A temporary monitoring retention exception exists for one synthetic source and expires next month.
Recommendation
A proposed defensive action supported by evidence and linked to an owner and intended outcome.
Example: Validate monitoring-source recovery and improve dependency-health context before future maintenance windows.
Decision
An authorized choice made by the appropriate owner using the evidence and risk available at that time.
Example: Continue service recovery while preserving the administrative action as an unresolved review item.
Unresolved question
A material question that remains open and could change confidence, priority, or the final decision.
Example: Was the 09:11 privileged action part of the approved change scope or a separate administrative action?
Confirmed Facts
Six Facts the Capstone Can Safely Carry Forward
FACT-NB-01Confidence: High
The fictional Northbridge Learning Portal experienced elevated error rates between 09:14 and 09:29.
Support: Application and service-health records agree on the affected period.
FACT-NB-02Confidence: High
An approved administrative change began at 09:05 and included identity-policy and worker-service maintenance.
Support: Synthetic change record CHG-NB-220 with named fictional owners.
FACT-NB-03Confidence: High
A privileged identity performed an administrative action at 09:11.
Support: Identity and application records contain matching synthetic event references.
FACT-NB-04Confidence: High
The monitoring collector was delayed for part of the 09:08–09:17 period.
Support: Source-health dashboard and collector backlog record.
FACT-NB-05Confidence: Medium
One background processing queue exceeded its fictional normal latency before portal errors increased.
Support: Service-health and application records.
FACT-NB-06Confidence: High
Portal availability returned after a worker-service restart and queue recovery.
Support: Application, service-health, and recovery checkpoint records.
Decision Questions
What the Capstone Team Actually Needs to Decide
Mission
Which service outcomes are most important to preserve during the review?
Scope
Which fictional systems, identities, data, time window, and evidence are actually included?
Evidence
Which records agree, contradict, lag, or have known source-health limitations?
Identity
Which human or workload identities acted, under what role, purpose, approval, and lifecycle context?
Architecture
Which trust boundaries and dependencies could connect the observed conditions without implying causation prematurely?
Response
What defensive decisions are justified now, and which should wait for stronger evidence?
Recovery
What evidence shows the service is restored, dependencies are healthy, and confidence is sufficient for normal operation?
Risk
Which unresolved conditions create material residual risk and who owns the decision?
Privacy
What data is being reviewed, for what purpose, by whom, and with what minimization and retention expectations?
Communication
What do technical teams, managers, and leaders need to know now without overstating certainty?
Analyze the Evidence
Evidence Analysis 2 — Approved Change Context
The change has a fictional owner, approved purpose, timing, affected services, and rollback plan.
A privileged action occurs inside the maintenance window.
The exact action is not listed in the summarized change task.
A queue dependency also degrades during the same period.
An approved change record covers identity-policy and worker-service maintenance. What is the strongest use of that record?
Unresolved Questions
Good Unknowns Are Specific Enough to Guide Evidence Review
An unresolved-question register prevents uncertainty from disappearing when the team becomes busy. Each question should explain why it matters and what evidence could change the decision.
UQ-NB-01
Was the 09:11 privileged administrative action explicitly included in the approved change scope?
Why it matters: This affects whether the event is expected maintenance context, a process deviation, or a separate investigation item.
Evidence needed: Approved change-task details, owner confirmation, and matching workflow record.
UQ-NB-02
Did the queue-latency increase begin before, during, or after the worker-service configuration change?
Why it matters: Sequence may help distinguish dependency degradation from later application symptoms.
Evidence needed: Normalized application, service-health, and change timestamps.
UQ-NB-03
How much monitoring evidence was delayed during the collector backlog?
Why it matters: The answer changes confidence in claims based on missing alerts or events.
Evidence needed: Source-health timeline, ingestion delay range, and recovery confirmation.
UQ-NB-04
Was the worker-service restart sufficient for trusted recovery or did another dependency also change?
Why it matters: Recovery causation should not be assigned to one action if several conditions changed together.
Evidence needed: Recovery checkpoint, queue health, dependency status, and change timeline.
UQ-NB-05
Does the current restoration evidence satisfy the fictional recovery-review requirement?
Why it matters: Backup availability is not the same as validated restoration readiness.
Evidence needed: Current restoration test record or documented risk-owner decision on the evidence gap.
Common Briefing Mistakes
What Weakens a Capstone Before Analysis Even Begins
Starting with root cause
A briefing should not claim a cause before the evidence inventory and competing explanations have been reviewed.
Treating all evidence equally
Sources have different purposes, health states, freshness, coverage, and limitations.
Hiding unknowns
Unanswered questions should remain visible when they could change scope, confidence, priority, or ownership.
Confusing approval with proof
An approved change can explain expected activity but does not prove every observed action or effect was intended.
Expanding beyond scope
A local synthetic observation cannot justify claims about systems, identities, or time periods outside the charter.
Ignoring decision owners
The case should identify who has authority to accept risk, approve recovery, change policy, or communicate material conclusions.
Safe Fictional Lab
Build the Northbridge Capstone Case Charter
Use only the synthetic evidence already provided on this page. Your job is to create a defensible starting point, not solve the entire case.
Task 1 — Define mission and decision
Write one mission statement and one primary decision question that explain why the case exists.
Task 2 — Bound the scope
List included systems, identities, evidence classes, time window, and explicit exclusions.
Task 3 — Build an evidence inventory
For at least six sources, record what each supports, what it cannot prove, and its current health or limitation.
Task 4 — Classify statements
Write at least four facts, two interpretations, two hypotheses, two assumptions, and two unresolved questions.
Task 5 — Assign owners
Identify fictional owners for application, identity, monitoring, recovery, risk, privacy, and incident decisions.
Task 6 — Write the briefing summary
Produce a short summary that states confirmed conditions, major uncertainty, immediate decision needs, and what the briefing does not prove.
Scenario Decision Lab
Scenario Decision 1 — Leadership Wants an Immediate Cause
A fictional executive asks whether the approved maintenance caused the portal interruption before the architecture and timeline review are complete.
Scenario Decision Lab
Scenario Decision 2 — Missing Alert During Source Delay
A reviewer argues that no privileged alert means no privileged concern existed during the monitoring-delay window.
Advanced Challenge
Write Three Briefings Without Changing the Facts
Use the same Northbridge case evidence to produce three briefing versions. The underlying facts and uncertainty must remain consistent.
Technical briefing
Emphasize sources, timing, architecture dependencies, source-health limitations, hypotheses, and evidence needs.
Manager briefing
Emphasize affected service, current status, owners, immediate decisions, uncertainty, and recovery progress.
Executive briefing
Emphasize material impact, confidence, current risk, decision needs, owner accountability, and next checkpoint.
Defender Habits
Capstone Scenario Briefing Checklist
Assessment
A20.2 Knowledge Check
Check Your Understanding
A20.2 Mini Quiz: Capstone Scenario Briefing
Choose your answers first. Explanations appear only after submission.
1. Why should the A20 capstone begin with a case charter?
2. A monitoring source was delayed during the case window. What is the strongest treatment of missing alerts from that period?
3. Which statement is a hypothesis rather than a fact?
4. What is the main purpose of documenting exclusions?
5. An approved change record shows that maintenance was planned. What does it not automatically prove?
6. Which unresolved question is most useful?
7. What is safest for the A20 capstone briefing?
Portfolio Prompt
Portfolio Prompt — Capstone Case Charter and Evidence Inventory
Create a fictional Northbridge Capstone Case Charter and Evidence Inventory. Include mission, primary decision, scope, exclusions, stakeholders, owners, constraints, assumptions, unknowns, stop conditions, at least six evidence sources, provenance, source-health state, freshness, what each source supports, what each source cannot prove, at least four confirmed facts, two interpretations, two hypotheses, two findings, two risks or risk questions, two unresolved questions, and a short technical and executive briefing that preserve the same underlying case truth.
Write the decision question before proposing solutions.
Keep source limitations beside the evidence rather than hiding them in a footnote.
Do not convert sequence or correlation into causation without supporting evidence.
Treat approved maintenance as context that still requires event-level validation.
Make unresolved questions specific enough to identify the next evidence needed.
Use only fictional systems, synthetic records, and defensive reasoning.
Confidence / Readiness Reflection
Are You Ready for A20.3?
A20.3 moves into Architecture and Threat Model Phase. Before continuing, make sure the case has a stable scope and that your architecture review will begin from confirmed case facts rather than a preferred cause.
1
I can explain the mission and primary decision of the Northbridge capstone.
2
I can identify which evidence sources are current, delayed, partial, or limited.
3
I can separate the privileged event from any unsupported conclusion about its purpose or cause.
4
I can carry unresolved questions forward instead of forcing closure.
5
I can use the case charter as the boundary for the architecture and threat-model phase.
Portfolio Build Guide
Keep the Case Charter Useful Through A20.10
Version the charter
If scope or evidence changes later, record the revision instead of silently rewriting the original briefing.
Use stable IDs
Facts, findings, risks, evidence sources, and unresolved questions should be easy to reference from later artifacts.
Record evidence limits beside evidence
Do not separate a source from the limitation that determines what it can support.
Carry unknowns forward
Later phases should close, revise, or preserve unresolved questions explicitly.
Preserve decision history
If new evidence changes the case, show what was known before and why the updated decision changed.
Keep owners consistent
Application, identity, monitoring, recovery, risk, and privacy ownership should remain compatible across later artifacts.
Reuse the executive summary
Update it as confidence changes, but keep material facts and limitations aligned with the technical record.
Maintain the safety boundary
Every new A20 artifact should remain fictional, synthetic, defensive, and publication-safe.
Key Takeaways
What You Should Remember
1.A professional capstone begins by defining the decision environment before deciding the answer.
2.Mission, scope, stakeholders, assets, evidence, constraints, assumptions, unknowns, exclusions, and decision authority form the foundation of the case charter.
3.Evidence should be evaluated by source, provenance, health, freshness, reliability, limitation, and the decisions it can support.
4.Facts, interpretations, hypotheses, assumptions, findings, risks, incidents, exceptions, recommendations, decisions, and unresolved questions are related but not interchangeable.
5.Approved maintenance is context, not proof that every event during the window was expected.
6.Source-health problems reduce confidence in absence-of-event conclusions and should remain visible throughout later capstone phases.
7.Strong unresolved questions are specific, decision-relevant, and linked to the evidence needed for resolution.
8.The A20 case remains completely fictional and requires no real security access, testing, monitoring, or investigation.
Lesson Safety Boundary
The case briefing is entirely fictional and read-only
Use only the synthetic Northbridge records supplied within CyberShield Academy. Do not access, scan, probe, enumerate, exploit, test credentials, bypass controls, collect real logs, inspect private records, connect to real cloud accounts, modify configurations, or investigate any real organization. The capstone evaluates evidence reasoning and defensive decision quality, not operational security testing.
Lesson Complete
A20.2 Capstone Scenario Briefing Complete
The Northbridge capstone now has a mission, bounded scope, evidence inventory, source-health context, confirmed facts, unresolved questions, and decision framework. Next, A20.3 uses this briefing to build the Architecture and Threat Model Decision Pack.