H — Highlight what is known
Record fictional observations, evidence sources, versions, owners, dates, and source-health context.
High School AdvancedModule A3Lesson 8 of 10Model Honesty and Traceability
A3.8 Documenting Assumptions and Limits
Learn how professional defenders make fictional threat models trustworthy by recording what is known, believed, unknown, constrained, excluded, provisional, accepted, and decision-blocking. Build assumption and limitation records that connect evidence, confidence, owners, consequences, expiration, review triggers, risks, mitigations, and recovery decisions.
Lesson Progress
Documenting Assumptions and Limits
High School Advanced • A3: Threat Modeling • Lesson 8 of 10
80% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
An Undocumented Assumption Can Quietly Control the Entire Threat Model
A fictional Northbridge risk register ranks stale supplier results as High. The selected mitigation relies on the belief that queue ordering is preserved and that one service identity represents all supplier result activity. Neither belief is clearly documented. If either is false, actor attribution, duplicate handling, reconciliation, control design, and residual risk may all change.
Hidden assumption
“The queue works normally.” No owner, evidence, confidence, meaning, expiration, consequence, or validation plan is shown.
Documented assumption
“Assume result ordering is preserved for one case reference until the workflow owner validates fictional delay, retry, and recovery evidence; confidence is Moderate and the assumption expires after queue or supplier change.”
A trustworthy model does not pretend to know everything. It makes uncertainty visible, assigns responsibility, limits conclusions, and shows how decisions must change when evidence changes.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Explain why fictional assumptions, limits, exclusions, dependencies, unknowns, and evidence gaps are essential parts of a trustworthy threat model rather than signs of failure.
Objective 2
Write precise fictional assumption statements that identify scope, owner, evidence, confidence, expiration, consequences, and review triggers.
Objective 3
Distinguish fictional observations, interpretations, hypotheses, assumptions, constraints, exclusions, unknowns, decisions, and accepted residual risks.
Objective 4
Evaluate how fictional model limits affect threat categories, risk rankings, mitigation choices, recovery expectations, communication, and stakeholder confidence.
Objective 5
Produce a portfolio-ready fictional assumptions-and-limits register that remains ethical, authorized, defensive, evidence-aware, privacy-safe, non-operational, and completely invented.
Why This Matters
Assumptions Determine How Far a Model Can Be Trusted
Fictional threat models combine incomplete evidence, stakeholder knowledge, diagrams, exercises, role records, supplier statements, control reviews, and professional judgment. Without explicit assumptions and limits, readers may mistake a draft model for a complete description, a possibility for a fact, a design control for an operating control, or an exercise result for current production behavior.
Decision integrity
Readers can see which fictional conclusions are confirmed, provisional, blocked, or dependent on owner validation.
Maintenance
Owners know when assumptions expire and which changes require review.
Responsible communication
Leadership receives useful priorities without false certainty, hidden gaps, or exaggerated claims.
Core Framework
The H-O-N-E-S-T Model
O — Outline what is assumed
Write precise, testable fictional beliefs with confidence and consequences.
N — Name what is unknown
Identify missing ownership, state, exposure, data, identity, control, supplier, and recovery information.
E — Explain exclusions and constraints
Show which fictional areas are outside scope and which conditions limit options.
S — Set owners and schedules
Assign validation actions, expiration, review dates, triggers, and version history.
T — Trace decision effects
Connect assumptions and limits to categories, rankings, mitigations, residual risk, recovery, and communication.
Decision-ready assumption statement
The fictional model assumes a precise condition for a documented reason, based on named evidence with known limitations. The assumption has a confidence level, accountable owner, validation action, expiration, consequence if false, affected decisions, review triggers, status, and version history.
Advanced Vocabulary
Terms for Model Honesty and Maintenance
Assumption
A documented fictional belief used to continue analysis when complete evidence is unavailable, with an owner, confidence level, expiration, consequence, and validation plan.
Limit
A fictional boundary on what the threat model can reliably describe, conclude, compare, rank, or recommend.
Constraint
A fictional condition that restricts design, evidence collection, mitigation, timing, resources, authority, technology, supplier options, or recovery choices.
Exclusion
A fictional asset, actor, environment, workflow, interface, data set, supplier, recovery state, or question intentionally left outside the current model.
Unknown
A fictional fact, state, owner, behavior, dependency, control condition, or outcome that is not currently established.
Evidence gap
A fictional missing, stale, incomplete, conflicting, unhealthy, inaccessible, or unowned record needed to support a claim or decision.
Observation
A fictional fact directly represented by supplied evidence, such as a field appearing in an inventory or a queue delay appearing in a training dashboard.
Interpretation
A fictional explanation of what an observation may mean, based on context and reasoning rather than direct proof.
Hypothesis
A fictional, testable explanation for an observation or relationship that has not yet been confirmed.
Decision
A fictional authorized choice about scope, category, risk, mitigation, evidence, ownership, exception, acceptance, or review.
Model confidence
A documented fictional judgment about how strongly scope, evidence, ownership, control state, and stakeholder review support the model.
Assumption confidence
A documented fictional judgment about how strongly available evidence supports one assumption.
Validity period
The fictional time window during which an assumption or decision remains usable before scheduled review or expiration.
Expiration
The fictional date or condition after which an assumption, exception, temporary control, or owner decision may no longer be relied upon.
Review trigger
A fictional event or change that requires an assumption or model limit to be reconsidered before its normal review date.
Dependency
A fictional service, identity, supplier, process, data source, person, queue, interface, environment, or recovery step on which the model or mitigation relies.
Scope boundary
The fictional line separating what the current model includes from what it does not analyze.
Evidence provenance
The fictional source, owner, collection context, timestamp, version, health, transformation, and review history of evidence used in the model.
Staleness
The fictional risk that a record, diagram, role map, supplier statement, control review, or assumption no longer reflects current conditions.
Contradictory evidence
Fictional records or owner statements that support different conclusions and therefore require reconciliation rather than silent selection.
Decision-blocking gap
A fictional unknown or evidence limit serious enough to prevent responsible category assignment, risk ranking, mitigation selection, or residual-risk acceptance.
Residual uncertainty
The fictional uncertainty that remains even after evidence collection, review, mitigation, or owner decisions.
Traceability
The fictional connection from an assumption or limit to affected assets, actors, flows, boundaries, abuse cases, categories, risks, mitigations, owners, and review triggers.
Model caveat
A concise fictional statement explaining a limitation that readers must understand before using the model.
Instructional Section 1
Apply Ten Documentation Principles
Write assumptions as testable statements
A strong fictional assumption identifies exactly what is believed, why it matters, what evidence supports it, and what could disprove it.
Strong practice
Assume the supplier-result service uses one managed identity for the documented interface until the supplier owner validates current identity and delegation records.
If ignored
Vague statements such as “security is good” cannot be validated, owned, or reviewed.
Separate known from believed
Distinguish fictional observations from interpretations, hypotheses, assumptions, decisions, and unknowns.
Strong practice
Observation: the field appears in the inventory. Assumption: it may be populated in current requests. Unknown: actual current use and retention.
If ignored
Readers may mistake a possibility or interpretation for a confirmed fact.
Name the affected decision
Every fictional assumption should explain which category, risk ranking, mitigation, recovery, or ownership decision depends on it.
Strong practice
The free-text-field assumption blocks final privacy risk ranking and supplier-data mitigation approval.
If ignored
Teams cannot tell which conclusions must change when an assumption changes.
Assign one accountable owner
A fictional role should be responsible for validating, updating, extending, or retiring each assumption.
Strong practice
The fictional supplier owner validates interface identity, fields, retention, and evidence by the review date.
If ignored
Shared responsibility without accountability often leaves assumptions unreviewed.
Record confidence and evidence limits
Explain how strongly fictional evidence supports the assumption and where source health, coverage, timing, or ownership remains weak.
Strong practice
Confidence is Moderate because the interface record is current, but operating evidence and supplier confirmation are incomplete.
If ignored
An assumption may appear equally reliable whether supported by strong evidence or guesswork.
Use expiration and triggers
Every important fictional assumption should have a review date and change conditions that cause earlier review.
Strong practice
Review after supplier version, field schema, identity, queue, recovery, ownership, or contract change.
If ignored
Temporary assumptions become permanent and stale.
Document consequences of failure
State which fictional conclusions, controls, priorities, or user outcomes may be wrong if the assumption is false.
Strong practice
If the queue preserves ordering differently than assumed, stale-state and duplicate-risk rankings must be revised.
If ignored
The team may continue using invalid conclusions after the assumption fails.
Preserve exclusions visibly
Explain which fictional systems, environments, actors, flows, states, and questions were not analyzed and why.
Strong practice
The current model excludes mobile-client behavior and focuses only on the fictional web portal and connected services.
If ignored
Readers may believe the model covers more than it does.
Treat model limits as decision inputs
Fictional limitations should influence confidence, evidence actions, ranking, mitigation, communication, and review.
Strong practice
Decision-blocking uncertainty pauses final residual-risk acceptance.
If ignored
A model can look complete while relying on unsupported conclusions.
Version the register
Maintain fictional history so readers can understand which assumptions changed, why, who approved the change, and which decisions were updated.
Strong practice
Record previous statement, new evidence, revised confidence, affected risks, owner, and approval date.
If ignored
Changes may overwrite the reasoning needed for accountability and learning.
Instructional Section 2
Classify Ten Types of Model Statements
Threat-model quality improves when fictional teams label the type of statement they are making. This prevents evidence, reasoning, and decisions from blending together.
Observation
A fictional fact directly shown by supplied evidence.
Fictional example
The fictional queue dashboard shows a twenty-two-minute result delay while source health remains Green.
Professional use
Supports evidence review and prompts interpretation.
Warning
The observation does not prove cause, harm, compromise, or future frequency.
Interpretation
A fictional explanation of what an observation may indicate.
Fictional example
The Green health indicator may represent connectivity rather than event freshness or business completion.
Professional use
Guides defensive questions and evidence requests.
Warning
An interpretation must not be presented as direct evidence.
Hypothesis
A fictional explanation that can be checked using safe, supplied evidence.
Fictional example
The delayed results may have contributed to stale user status and duplicate submissions.
Professional use
Supports structured evidence analysis.
Warning
Correlation does not prove one cause.
Assumption
A fictional belief temporarily relied upon so the model can continue.
Fictional example
Assume queue result ordering is preserved unless supplier or queue evidence shows otherwise.
Professional use
Enables provisional modeling while keeping uncertainty visible.
Warning
The assumption requires an owner, confidence, expiration, consequence, and validation plan.
Unknown
A fictional fact or state that is not established.
Fictional example
Current population and supplier retention of the free-text support-note field are unknown.
Professional use
Identifies evidence work and possible decision blocking.
Warning
Unknown does not mean Low risk or Very High risk by itself.
Constraint
A fictional restriction on possible design, timing, evidence, mitigation, or recovery choices.
Fictional example
The fictional supplier cannot be replaced during the current quarter.
Professional use
Shapes feasible mitigation options and compensating controls.
Warning
A constraint should not silently become an excuse for indefinite risk acceptance.
Exclusion
A fictional item intentionally outside the current model.
Fictional example
The current threat model excludes the fictional mobile application and focuses on the web portal.
Professional use
Prevents overclaiming scope and informs follow-up work.
Warning
Exclusions that affect major dependencies or user outcomes may require a separate model.
Decision
A fictional authorized choice based on current evidence and constraints.
Fictional example
The fictional risk owner approves a provisional High residual ranking pending supplier evidence.
Professional use
Records accountability and the current action path.
Warning
A decision should state conditions, owner, date, evidence, and review triggers.
Residual risk acceptance
A fictional authorized decision to tolerate remaining risk under defined conditions.
Fictional example
The fictional owner accepts temporary manual-review delay until the state-validation control is implemented.
Professional use
Makes temporary or permanent risk ownership explicit.
Warning
Acceptance must not be implied by inaction.
Model caveat
A concise fictional statement readers must understand before using the model.
Fictional example
The model uses exercise evidence and does not establish current production frequency.
Professional use
Improves responsible communication.
Warning
Caveats should not be buried where decision-makers cannot see them.
Instructional Section 3
Build Every Important Assumption with Twelve Fields
1
Assumption identifier
Give the fictional assumption a stable reference for risks, mitigations, decisions, and reviews.
Strong fictional example
ASM-07
Weak example
Assumption about supplier.
2
Precise statement
State exactly what the fictional model believes.
Strong fictional example
The supplier-result interface uses one managed service identity and does not delegate authority to additional downstream identities.
Weak example
The supplier identity is secure.
3
Reason for use
Explain why the model needs the fictional assumption.
Strong fictional example
The identity relationship is required to evaluate trust boundaries, authorization, evidence, and recovery ownership.
Weak example
We need to assume something.
4
Supporting evidence
List the fictional records that support the assumption.
Strong fictional example
Interface inventory, service-identity record, architecture diagram, and supplier-owner statement.
Weak example
The documentation.
5
Evidence limits
Explain missing, stale, conflicting, unhealthy, transformed, or unowned evidence.
Strong fictional example
The service-identity record is current, but delegation, operating events, and supplier confirmation are incomplete.
Weak example
Evidence may be incomplete.
6
Confidence
Rate how strongly fictional evidence supports the statement.
Strong fictional example
Moderate confidence because design evidence is current but operating evidence is partial.
Weak example
Probably correct.
7
Affected decisions
Identify which fictional categories, risks, mitigations, owners, or recovery plans depend on the assumption.
Strong fictional example
Supplier trust-boundary model, identity risk, logging design, and recovery validation.
Weak example
Security decisions.
8
Consequence if false
Explain what fictional conclusions may need revision.
Strong fictional example
If delegation exists, actor attribution, least privilege, monitoring, supplier ownership, and residual risk must be reassessed.
Weak example
Risk could increase.
9
Validation action
Describe the safe fictional evidence needed to confirm, revise, or retire the assumption.
Strong fictional example
Supplier owner reviews the invented identity relationship record and supplied event schema.
Weak example
Test the system.
10
Owner
Assign one fictional role accountable for review.
Strong fictional example
Fictional supplier integration owner.
Weak example
Security team.
11
Review date and expiration
Define when reliance must stop or be reconsidered.
Strong fictional example
Review by October 15; expires after supplier identity, interface, contract, or recovery change.
Weak example
Review later.
12
Status and history
Track whether the fictional assumption is open, validated, revised, rejected, expired, replaced, or retired.
Strong fictional example
Open—version 2, revised after interface-schema update.
Weak example
Active.
Instructional Section 4
Document Ten Families of Model Limits
Scope limits
The fictional model covers only defined systems, actors, environments, workflows, states, data, suppliers, or time periods.
Fictional example
The model includes the web portal and connected services but excludes the separate fictional mobile client.
Decision effect
Findings cannot be generalized automatically to excluded components.
Required action
Create follow-up scope or a separate model where excluded dependencies matter.
Evidence limits
Fictional records may be missing, stale, incomplete, conflicting, transformed, sampled, unhealthy, or unowned.
Fictional example
Queue health reports connectivity but may not report event freshness or business completion.
Decision effect
Confidence and risk rationale must remain provisional.
Required action
Assign source-health, completeness, ownership, and validation actions.
Time limits
The fictional model reflects a specific architecture version, review period, exercise, or design state.
Fictional example
The current model uses the July fictional architecture record and one recovery exercise.
Decision effect
Later changes may invalidate flows, controls, ownership, or risk.
Required action
Set scheduled review and change triggers.
Control limits
Fictional controls may be designed but not implemented, implemented but not operating, or operating only under normal conditions.
Fictional example
Schema validation is documented, but resilient failure-state evidence is incomplete.
Decision effect
Residual-risk reduction may be smaller than expected.
Required action
Separate design, implementation, operation, monitoring, review, and recovery evidence.
Supplier limits
Fictional teams may not have complete visibility into supplier identity, fields, internal processing, retention, evidence, recovery, or changes.
Fictional example
The supplier field inventory is available, but current population and downstream retention are unknown.
Decision effect
Risk and mitigation may depend on shared responsibility and contract evidence.
Required action
Assign supplier owner, evidence rights, change review, recovery, and exit decisions.
Human and process limits
Fictional workflows, approvals, support actions, communication, training, and manual reviews may vary under pressure or ambiguity.
Fictional example
Reason and confirmation fields are missing in several support tickets.
Decision effect
A documented process may not represent every real fictional workflow outcome.
Required action
Use quality review, workflow evidence, usability review, and bounded manual controls.
Modeling-method limits
The chosen fictional categories, scoring scales, diagrams, or templates may emphasize some concerns and miss others.
Fictional example
A category worksheet may underrepresent accessibility, communication trust, or operational handoff.
Decision effect
Framework completeness should not be mistaken for system completeness.
Required action
Preserve uncategorized concerns and use multidisciplinary review.
Prediction limits
Fictional risk rankings and abuse cases compare plausible scenarios but do not predict exact frequency, actor behavior, or future harm.
Fictional example
One recovery exercise supports concern but not production frequency.
Decision effect
Scores and bands require confidence and review context.
Required action
Avoid false precision and record assumptions, evidence, and uncertainty.
Recovery limits
Fictional backup or restore evidence may not prove complete business-state, identity, communication, evidence, or trust recovery.
Fictional example
Application service returns before notification and archival state are validated.
Decision effect
Technical availability cannot be treated as full recovery.
Required action
Model sequencing, reconciliation, user outcomes, evidence, and closure.
Portfolio limits
Public fictional artifacts intentionally omit or invent operational details to remain safe and privacy-preserving.
Fictional example
All names, systems, identities, flows, fields, events, controls, dates, and outcomes are invented.
Decision effect
The artifact demonstrates reasoning rather than documenting a real environment.
Required action
Maintain complete fictionalization and a clear safety statement.
Instructional Section 5
Use Confidence without Pretending to Have Certainty
Low confidence
Indicators
Important fictional scope, ownership, evidence, control state, or stakeholder review is missing or contradictory.
Appropriate use
Early hypotheses, provisional scenarios, and evidence-planning decisions.
Communication
State that final ranking or mitigation may be decision-blocked.
Moderate confidence
Indicators
The fictional scenario and main relationships are supported, but some operating evidence, owner confirmation, or failure-state coverage is incomplete.
Appropriate use
Provisional categories, risk bands, and mitigation planning with explicit follow-up.
Communication
Explain which evidence could raise or lower the conclusion.
High confidence
Indicators
Fictional scope, owners, current evidence, control state, affected assets, and stakeholder review are consistent and recent.
Appropriate use
Decision-ready ranking and mitigation with normal residual uncertainty.
Communication
Avoid claiming certainty; preserve review triggers and limits.
Decision-blocked
Indicators
The fictional scenario, asset, current state, owner, evidence, or control condition is too unclear for responsible use.
Appropriate use
Evidence collection, scope clarification, ownership assignment, and escalation.
Communication
Do not force a final score, mitigation, or acceptance decision.
Worked Fictional Register
Northbridge Assumption Examples
ASM-01
The fictional supplier-result queue preserves event order for one case reference.
Evidence
Queue design summary and interface sequence notes.
Evidence limits
No operating or recovery evidence confirms ordering after delay, retry, or failover.
Confidence
Moderate
Affected decisions
Integrity risk, duplicate handling, stale-state mitigation, and recovery reconciliation.
Consequence if false
If false, risk ranking and selected controls must include stronger ordering, correlation, and reconciliation requirements.
Owner
Fictional workflow integration owner
Review trigger
Review after queue, supplier, retry, or recovery change.
ASM-02
The fictional free-text support-note field may be populated in current supplier requests.
Evidence
Field inventory lists the field.
Evidence limits
No current payload sample, usage summary, purpose approval, or retention evidence is supplied.
Confidence
Low
Affected decisions
Privacy risk, confidentiality risk, data-minimization design, and supplier governance.
Consequence if false
If the field is unused, current residual risk may decrease; if used broadly, impact and mitigation urgency may increase.
Owner
Fictional data owner
Review trigger
Decision-blocking until current use is validated.
ASM-03
The fictional archival service identity is required for approved retention and recovery workflows.
Evidence
Service catalog and recovery process reference the identity.
Evidence limits
Current owner, authority scope, activity, and review evidence are incomplete.
Confidence
Moderate
Affected decisions
Identity risk, governance risk, archival mitigation, and recovery readiness.
Consequence if false
If the purpose has changed or ended, the identity may require restriction, replacement, or retirement.
Owner
Fictional records and recovery owner
Review trigger
Review before any lifecycle decision and after recovery-design change.
ASM-04
The fictional source-health dashboard represents source connectivity rather than complete event freshness and business processing.
Evidence
Green status remained during a twenty-two-minute event delay.
Evidence limits
Dashboard semantics and source-health implementation are not fully documented.
Confidence
Moderate
Affected decisions
Detection design, evidence confidence, supplier-result risk, and mitigation validation.
Consequence if false
If the dashboard already includes freshness, the monitoring gap may be smaller; if not, independent evidence is required.
Owner
Fictional monitoring owner
Review trigger
Review when dashboard semantics or telemetry pipeline changes.
ASM-05
The fictional support workflow expects reason capture and user confirmation for notification changes.
Evidence
Support procedure and ticket template contain both fields.
Evidence limits
Several tickets are incomplete, and workflow enforcement is not demonstrated.
Confidence
Moderate
Affected decisions
Accountability risk, support mitigation, user communication, and quality review.
Consequence if false
If the fields are optional by design, the control objective and evidence standard must be revised.
Owner
Fictional support operations owner
Review trigger
Review after workflow, ticket, role, or notification-process change.
ASM-06
The fictional recovery exercise represents a credible but not complete indicator of current recovery behavior.
Evidence
The exercise produced stale messages and repeated archival tasks.
Evidence limits
One exercise does not establish production frequency, every dependency, or all corrective actions.
Confidence
High for the exercise observation; Moderate for current-state inference
Affected decisions
Recovery risk, mitigation priority, dependency order, communication, and reconciliation.
Consequence if false
If corrective controls are already operating, residual risk may decrease; if not, recovery urgency remains High.
Owner
Fictional continuity owner
Review trigger
Review after corrective action and the next exercise.
Traceability Matrix
Connect Assumptions to Threat-Model Decisions
| Threat-model area | Possible fictional assumption | If false | Required review |
|---|---|---|---|
| Assets | The documented case-status record is the authoritative source. | Integrity, recovery, and user-communication conclusions may be wrong. | Data owner validates authority, copies, lineage, and reconciliation. |
| Actors | One fictional service identity represents all archival actions. | Attribution, privilege, monitoring, and recovery ownership may change. | Identity and archive owners validate delegation and activity. |
| Entry points | The temporary migration interface is inactive. | Exposure, authority, monitoring, and retirement decisions may change. | Interface owner validates purpose, state, evidence, and dependencies. |
| Data flows | Supplier results preserve ordering and correlation. | Duplicate, stale-state, and reconciliation risk may increase. | Workflow owner reviews queue and recovery evidence. |
| Trust boundaries | Supplier identity and schema validation occur before results are trusted. | The boundary control model and residual risk may be incomplete. | Supplier and application owners validate controls and evidence. |
| Abuse cases | Delayed notifications contribute to duplicate submissions. | Causal narrative and selected controls may need revision. | Support and workflow owners compare alternative explanations. |
| Categories | Accountability is the primary notification-change concern. | Primary owner and control priorities may change. | Multidisciplinary review confirms the central decision. |
| Risk ranking | Current controls reduce likelihood to Moderate. | Residual risk may be higher or lower than documented. | Control owners provide operating and failure evidence. |
| Mitigations | State validation will reduce stale-update risk. | The chosen package may not achieve its objective. | Validation plan checks normal, delay, retry, and recovery states. |
| Recovery | Restored application availability reflects usable service. | Business state, communication, evidence, and trust may remain incorrect. | Continuity owner validates full recovery and closure. |
Fictional Model Boundary
Northbridge Included, Excluded, and Conditional Scope
Included
Fictional web portal
Identity and support workflows
Supplier request and result flows
Notification service
Monitoring and queue evidence
Archive and recovery relationships
Normal, failure, degraded, and recovery states
Excluded
Any real organization or system
Fictional mobile-client internals
Supplier internal architecture
Real-world legal conclusions
Operational attack methods
Real credentials, logs, routes, addresses, or configurations
Current production claims
Conditional
Future analytics design
Temporary migration interface
Supplier field population
Current service-identity ownership
Queue ordering after recovery
Operating effectiveness of planned controls
Current recovery readiness
Fake Dashboard
Fake Northbridge Assumptions and Limits Dashboard
Fictional assumption confidence, ownership, expiration, evidence, and decision-blocking status for training only.
Open assumptions
14
Six concern identity and suppliers, four concern control operation, and four concern recovery, workflow, or evidence.
Assumptions without owners
3
Queue ordering, supplier retention, and temporary-interface state still need accountable fictional roles.
Decision-blocking gaps
2
Current supplier free-text use and future analytics purpose block final privacy decisions.
Fake SOC Alert
Expired Assumption Still Used in Residual-Risk Decision
Source: Fake Northbridge Model Assurance Console • Time: 4:02 PM
A fictional residual-risk decision still relies on an assumption that the archival service identity has one owner and a narrow scope. The assumption expired after a recovery-design change, and no updated identity or activity evidence is attached.
Defensive recommendation: Mark the assumption expired, identify affected identity, governance, archival, and recovery decisions, assign an owner, collect only supplied fictional evidence, and pause any final acceptance that depends on the outdated statement.
Fake Log Panel
Fake Assumption Review Timeline
training-log-viewer.log
09:00 REGISTER assumptions='14' limits='10' 09:08 ASM-01 queue-order confidence='moderate' 09:16 ASM-02 supplier-note confidence='low' status='blocking' 09:24 ASM-03 archive-identity confidence='moderate' 09:32 ASM-04 dashboard-semantics confidence='moderate' 09:40 ASM-05 support-confirmation confidence='moderate' 09:48 ASM-06 recovery-inference confidence='mixed' 09:56 LIMIT scope-mobile='excluded' 10:04 LIMIT supplier-internal='not-visible' 10:12 LIMIT controls-operating='partial-evidence' 10:20 OWNER missing='queue,supplier-retention,migration' 10:28 EXPIRATION archive-identity='triggered' 10:36 DECISION residual-acceptance='paused' 10:44 TRACE affected='identity,governance,recovery' 10:52 ACTION owner-validation='required' 11:00 ACTION evidence-provenance='update' 11:08 REVIEW leadership-caveat='draft' 11:16 REVIEW technical-appendix='complete' 11:24 CONFIDENCE model='moderate' 16:02 ALERT issue='expired-assumption'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What the Evidence Supports—and What It Does Not Prove
AL-01
Fictional architecture record
Observation
The current diagram shows web portal, supplier, notification, monitoring, archive, and recovery relationships.
Supports
The model can describe those documented relationships.
Does not prove
The diagram does not prove every current flow, identity, control, temporary path, or failure state.
Documentation use
Create a scope caveat and assign current-state validation actions.
AL-02
Fictional queue dashboard
Observation
The dashboard shows a delay and Green source health.
Supports
The evidence sources may represent different dimensions of service state.
Does not prove
Cause, completeness, source-health semantics, and final business impact remain uncertain.
Documentation use
Document an evidence limitation and monitoring assumption.
AL-03
Fictional supplier-field inventory
Observation
A free-text support-note field appears in the documented request schema.
Supports
The field is part of the documented design or inventory.
Does not prove
Current population, approved purpose, access, retention, and downstream use are unknown.
Documentation use
Create a decision-blocking assumption for final privacy ranking.
AL-04
Fictional support tickets
Observation
Several notification changes lack recorded reason and confirmation fields.
Supports
The evidence record is incomplete for those fictional changes.
Does not prove
The tickets do not prove unauthorized action, harmful outcome, actor intent, or workflow design.
Documentation use
Separate observation from interpretation and assign process-validation work.
AL-05
Fictional service-identity review
Observation
The archival identity lacks a confirmed owner and current review.
Supports
Ownership and lifecycle evidence are incomplete.
Does not prove
The record does not prove compromise, misuse, broad authority, or active processing.
Documentation use
Document identity-purpose and lifecycle assumptions with Moderate confidence.
AL-06
Fictional recovery exercise
Observation
Application recovery preceded validation of notification and archival dependencies.
Supports
The exercise demonstrates a recovery-sequencing concern.
Does not prove
It does not prove production frequency, every current control, or future outcome.
Documentation use
Record the exercise-to-current-state inference as a model limit.
AL-07
Fictional mitigation register
Observation
Several controls are designed but do not yet have operating, failure, or recovery evidence.
Supports
Residual-risk reduction should remain provisional.
Does not prove
The register does not prove the controls are absent or ineffective.
Documentation use
Separate design evidence from operating-effectiveness assumptions.
AL-08
Fictional analytics proposal
Observation
The process is proposed and lacks approved fields, purpose, audience, retention, and ownership.
Supports
The scenario is future-state and design-blocking.
Does not prove
The proposal does not prove current collection, exposure, or misuse.
Documentation use
Document a future-state exclusion from current residual-risk reporting.
Analyze the Evidence
Which Assumption Record Is Most Responsible?
The fictional supplier-field inventory lists a free-text support-note field.
No current usage summary or payload evidence is supplied.
The approved purpose, access, retention, and downstream use are unresolved.
The field may affect privacy, confidentiality, governance, supplier, and mitigation decisions.
The evidence does not prove that the field is populated or misused.
The current privacy residual-risk decision depends on whether the field is used.
A fictional data owner has not yet been assigned.
The model has Low confidence for current field use.
Which statement best documents the fictional free-text supplier-field uncertainty?
Common Mistakes
Errors That Weaken Assumptions and Limitations
Hiding assumptions in narrative text
Why it fails
Readers may not know which fictional conclusions depend on unverified beliefs.
Strong correction
Use a structured register with identifiers, owners, confidence, consequences, expiration, and triggers.
Writing vague assumptions
Why it fails
Statements such as “the supplier is secure” cannot be validated or tied to a decision.
Strong correction
Write precise, bounded, testable fictional statements.
Treating unknown as Low risk
Why it fails
Missing evidence does not prove a scenario is unlikely or harmless.
Strong correction
Record uncertainty, confidence, evidence actions, and possible decision blocking.
Treating unknown as proof of danger
Why it fails
An evidence gap does not prove compromise, misuse, control failure, or severe impact.
Strong correction
Use provisional conclusions and bounded defensive questions.
Leaving assumptions without owners
Why it fails
Unowned fictional beliefs can remain stale while risks and mitigations depend on them.
Strong correction
Assign one accountable role and a review date.
Omitting consequences if false
Why it fails
The team cannot tell which categories, rankings, controls, or decisions must change.
Strong correction
Trace the assumption to affected conclusions and revision actions.
Using confidence without rationale
Why it fails
Low, Moderate, or High can become another unsupported label.
Strong correction
Explain evidence quality, scope, owner review, staleness, conflict, and source health.
Forgetting exclusions
Why it fails
Readers may assume the fictional model includes mobile, supplier-internal, administrative, recovery, or support areas that were never reviewed.
Strong correction
Publish included and excluded scope prominently.
Allowing assumptions to become permanent
Why it fails
Architecture, identity, data, supplier, control, evidence, and recovery conditions change.
Strong correction
Use expiration, versioning, scheduled review, and change triggers.
Using real assumptions or limitations
Why it fails
Real gaps, owners, suppliers, controls, recovery details, and priorities may reveal sensitive information.
Strong correction
Invent every organization, asset, actor, assumption, limit, evidence record, owner, date, decision, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Assumptions and Limits Register
Use only the supplied fictional information on this page. Do not access, scan, test, configure, investigate, monitor, recover, or change any real system. Do not use real assumptions, gaps, owners, suppliers, logs, configurations, controls, incidents, recovery details, or organizational priorities.
1
Confirm model scope and audience
State which fictional Northbridge systems, actors, flows, environments, suppliers, states, time period, and decisions are included.
Required output
Scope statement, audience, purpose, inclusions, exclusions, and safety boundary.
Quality check
A reader can tell what the model does and does not cover.
2
Extract hidden assumptions
Review fictional assets, actors, flows, boundaries, abuse cases, categories, risks, and mitigations for statements that depend on incomplete evidence.
Required output
A candidate-assumption list with affected decisions.
Quality check
The list includes identity, data, supplier, control, evidence, recovery, process, and user assumptions.
3
Classify each statement
Label each item as observation, interpretation, hypothesis, assumption, unknown, constraint, exclusion, decision, acceptance, or caveat.
Required output
A statement-classification table.
Quality check
Possibility and interpretation are not presented as confirmed facts.
4
Build the assumption register
Record identifier, statement, reason, evidence, limits, confidence, affected decisions, consequence if false, validation, owner, date, and status.
Required output
A decision-ready assumptions register.
Quality check
Every important assumption is testable, owned, time-bound, and traceable.
5
Document model limits
Record scope, evidence, time, control, supplier, human, method, prediction, recovery, and portfolio limitations.
Required output
A limitations and exclusions register.
Quality check
Limits appear where decision-makers will see them.
6
Identify decision-blocking gaps
Determine which fictional unknowns prevent responsible category, ranking, mitigation, or acceptance decisions.
Required output
A blocked-decision queue with evidence owners.
Quality check
The model does not force scores or conclusions through serious uncertainty.
7
Set maintenance rules
Assign fictional review dates, expirations, change triggers, versions, owners, and revision history.
Required output
An assumption-maintenance plan.
Quality check
Temporary beliefs cannot remain active indefinitely.
8
Communicate confidence responsibly
Write fictional leadership and technical summaries explaining what is known, assumed, unknown, excluded, blocked, and ready for decision.
Required output
Leadership caveat, technical appendix, decision log, and reflection.
Quality check
The summary remains useful without overstating certainty or completeness.
Scenario Decision Lab
A Team Wants to Hide Low-Confidence Assumptions
The fictional team worries that leadership will distrust the threat model if several assumptions are marked Low confidence, so a reviewer proposes removing confidence labels from the summary.
Scenario Decision Lab
An Excluded Component Affects a Major Dependency
The fictional model excludes the mobile client, but the mobile and web clients share the same identity service and notification process.
Advanced Challenge
Repair a Threat Model Built on Conflicting Assumptions
The fictional supplier owner says result ordering is guaranteed. The queue owner says ordering is best effort. The workflow owner assumes duplicates are impossible. The recovery exercise shows repeated archival tasks. Build a responsible assumption record and decision path without choosing one statement simply because it is more convenient.
Separate the claims
Record each fictional owner statement as evidence with source, date, scope, and limits.
Document contradiction
Explain which statements cannot all be relied upon together.
Identify affected decisions
Trace ordering and duplication assumptions to integrity risk, mitigation, evidence, and recovery.
Set provisional confidence
Use Low or Moderate confidence until supplied evidence resolves the conflict.
Create safe validation
Use invented event sequences and recovery records rather than any real testing.
Pause unsupported acceptance
Do not finalize residual risk if the contradiction materially changes the mitigation objective.
Challenge output
Produce a fictional contradictory-evidence record, revised assumption, confidence rationale, affected-decision map, validation plan, owner assignments, expiration, decision-blocking statement, leadership caveat, and revision history.
Defender Habits
Documenting Assumptions and Limits Checklist
Check Your Understanding
A3.8 Mini Quiz: Documenting Assumptions and Limits
Choose your answers first. Explanations appear only after submission.
1. Which statement is the strongest fictional assumption?
2. What is the difference between an observation and an interpretation?
3. What should happen when uncertainty is decision-blocking?
4. Why must an assumption include consequences if false?
5. What is a model exclusion?
6. Why should assumptions expire?
7. Which portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Assumptions, Limits, and Confidence Register for the Northbridge Student-Support Portal. Include purpose, audience, scope, inclusions, exclusions, constraints, safety boundary, statement-type definitions, at least fifteen assumptions, stable identifiers, precise statements, reasons for use, evidence, evidence provenance, evidence limits, confidence, affected assets, actors, flows, trust boundaries, abuse cases, categories, risk rankings, mitigations, recovery decisions, consequences if false, validation actions, owners, review dates, expiration, triggers, status, revision history, at least eight model limitations, decision-blocking gaps, residual uncertainty, leadership caveat, technical appendix, reflection, and a statement that every organization, asset, actor, system, assumption, limit, record, owner, date, decision, and outcome is invented.
Separate fictional observations, interpretations, hypotheses, assumptions, unknowns, constraints, exclusions, and decisions.
Give every important assumption a precise statement, owner, evidence, confidence, consequence, expiration, and review trigger.
Trace assumptions to the exact threat-model conclusions that depend on them.
Use decision-blocking status when missing evidence prevents responsible ranking, mitigation, or acceptance.
Keep the entire artifact completely fictional, defensive, non-operational, privacy-safe, evidence-aware, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready to Review a Threat Model?
Before moving to A3.9, rate your readiness from 1 to 5 for statement classification, assumption quality, evidence provenance, confidence, ownership, consequences, expiration, exclusions, decision blocking, traceability, versioning, leadership caveats, and complete fictionalization.
I can identify where a fictional threat model depends on hidden or weak assumptions.
I can separate supplied evidence from interpretation, hypothesis, and belief.
I can write assumptions that are testable, owned, time-bound, and traceable.
I can explain how scope, evidence, control, supplier, human, method, prediction, and recovery limits affect decisions.
I can use confidence without presenting it as certainty.
I can pause decisions when uncertainty is genuinely blocking.
I can explain the model honestly to leadership without making it useless or dramatic.
I can create a complete fictional register without copying, modifying, or exposing real organizational information.
Record one fictional assumption you rewrote, one model exclusion that affected a decision, one evidence limitation, one decision-blocking gap, and one review question you will carry into A3.9.
Key Takeaways
What You Should Remember
1.Assumptions, limits, exclusions, and unknowns are required parts of a trustworthy fictional threat model.
2.Observations, interpretations, hypotheses, assumptions, unknowns, constraints, decisions, and acceptances answer different questions.
3.A strong assumption is precise, testable, evidence-aware, owned, time-bound, and traceable to affected decisions.
4.Confidence requires a rationale based on scope, evidence quality, ownership, staleness, conflict, source health, and stakeholder review.
5.Unknowns should not be treated automatically as Low risk or proof of severe danger.
6.Decision-blocking uncertainty should pause final category, ranking, mitigation, or acceptance decisions.
7.Scope and exclusions must be visible so readers do not overgeneralize the fictional model.
8.Every assumption should explain what must change if it is false.
9.Expiration, review triggers, versions, owners, and revision history keep the model maintainable.
10.Every CyberShield assumptions-and-limits artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.
Navigation
Continue Module A3
Next, review the complete fictional threat model for scope, completeness, evidence, consistency, safety, category coverage, ranking quality, mitigation traceability, ownership, assumptions, limitations, communication, and maintenance.