D — Define mission and question
State the fictional purpose, mission risk, stakeholders, primary defender question, scope, exclusions, and non-proof statement.
High School AdvancedModule A5Lesson 9 of 10Specifications, Runbooks, Traceability, and Lifecycle
A5.9 Detection Documentation
Learn how professional defenders document fictional detections as maintainable capabilities with purpose, evidence, logic, alerts, analyst guidance, tests, ownership, metrics, changes, limitations, review triggers, rollback, residual risk, and retirement.
Lesson Progress
Detection Documentation
High School Advanced • A5: Detection Engineering • Lesson 9 of 10
90% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Working Detection Can Still Be an Unmaintainable Detection
A fictional stale-role alert is active and produces useful results. The logic owner leaves, the extension source changes fields, the group source enters a blind period, and analysts use an old runbook that closes cases when alerts disappear. The detection still runs, but the organization can no longer explain, test, or trust it.
Weak documentation state
“The rule is in the platform, and the analyst knows what to do.”
Strong documentation state
“The fictional capability has a versioned specification, source and field map, logic narrative, alert contract, runbook, test package, owner matrix, metrics, change log, limitations, and retirement plan.”
Documentation is part of the control. When it becomes stale, the detection's meaning, confidence, and decision quality can become stale too.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Explain how fictional detection documentation connects mission risk, defender questions, evidence, logic, tests, alert behavior, analyst decisions, ownership, metrics, limitations, and lifecycle.
Objective 2
Build a versioned fictional detection specification containing purpose, scope, exclusions, source requirements, field meaning, timing, context, missing-data behavior, confidence, severity, and non-proof statements.
Objective 3
Document fictional alert presentation, analyst guidance, evidence requests, escalation, closure, reopen criteria, privacy controls, and response boundaries.
Objective 4
Evaluate fictional documentation quality for completeness, traceability, freshness, reproducibility, maintainability, privacy, source-health awareness, residual risk, and retirement readiness.
Objective 5
Create a portfolio-ready fictional detection documentation package containing specifications, diagrams, test evidence, change history, owner records, metrics, review triggers, and leadership summaries.
Why This Matters
Documentation Preserves Defensive Meaning across People and Change
Fictional detections depend on sources, schemas, identities, services, workflows, owners, context, tests, and analyst decisions. Documentation connects those dependencies so a new reviewer can understand what the capability supports, what it cannot prove, how it behaves during degradation, and when it must change or retire.
Traceable design
Connect fictional mission risk, questions, evidence, logic, tests, alerts, decisions, and changes.
Repeatable operations
Give fictional analysts and owners clear evidence, question, state, escalation, and closure guidance.
Maintainable lifecycle
Preserve fictional versions, owners, metrics, review triggers, rollback, residual risk, and retirement.
Core Framework
The D-O-C-U-M-E-N-T Method
O — Organize evidence
Document fictional sources, fields, provenance, timing, transformations, health, coverage, privacy, and owners.
C — Capture logic and context
Explain fictional conditions, relationships, windows, thresholds, context, exclusions, missing-data behavior, confidence, and severity.
U — Specify analyst use
Define fictional alert presentation, ordered questions, evidence requests, states, escalation, closure, reopen, and response boundaries.
M — Map tests and metrics
Connect fictional requirements to validation cases, defects, alert usefulness, misses, source health, effort, and impact.
E — Establish ownership
Assign fictional detection, source, identity, service, supplier, change, privacy, risk, documentation, and retirement owners.
N — Note limitations and changes
Record fictional assumptions, known gaps, residual risks, versions, approvals, observation, rollback, and review triggers.
T — Terminate responsibly
Retire fictional rules, sources, exceptions, runbooks, metrics, and artifacts only after replacement and dependency validation.
Decision-ready documentation statement
This fictional detection package explains mission, questions, evidence, logic, alerts, tests, analyst decisions, owners, metrics, changes, limitations, residual risks, review triggers, rollback, and retirement through controlled, versioned, privacy-safe artifacts.
Advanced Vocabulary
Terms for Detection Documentation
Detection specification
A fictional versioned document describing why a detection exists, what it evaluates, which evidence it needs, how it behaves, and how it is maintained.
Documentation traceability
The fictional ability to connect mission risk, defender question, source, field, logic, test, alert, decision, change, owner, and review records.
Purpose statement
A fictional explanation of the defensive outcome the detection is intended to support.
Scope statement
A fictional description of the identities, services, devices, destinations, environments, states, periods, and evidence covered.
Exclusion statement
A fictional description of what the detection does not cover and why.
Non-proof statement
A fictional explanation of what an alert match does not establish, such as intent, compromise, cause, scope, or impact.
Source dependency
A fictional evidence source, field set, timing relationship, or health state required for the detection to behave as documented.
Field dictionary
A fictional versioned record of field meaning, source, type, values, transformations, requirements, privacy purpose, and limitations.
Logic narrative
A fictional conceptual explanation of conditions, relationships, sequence, thresholds, timing, context, exclusions, and missing-data behavior.
Alert contract
A fictional definition of what an alert must display and which analyst decision it should support.
Analyst runbook
A fictional step-by-step question and evidence guide for reviewing an alert safely and consistently.
Decision criterion
A fictional evidence-based rule for moving a case among New, In Review, Conditional, Expected, Source-Degraded, Unknown, Escalated, Resolved, or Reopened states.
Test evidence record
A fictional record of test input, expected outcome, observed outcome, source health, defect, decision, and validation.
Change history
A fictional versioned record of what changed, why, who approved it, how it was tested, and what rollback exists.
Documentation owner
The fictional role accountable for the accuracy, freshness, accessibility, and lifecycle of a documentation artifact.
Review trigger
A fictional event requiring documentation revalidation, such as source, schema, identity, service, policy, workflow, privacy, or mission change.
Residual risk
The fictional detection limitation, coverage gap, uncertainty, dependency, or impact that remains after current controls.
Known limitation
A fictional documented condition under which the detection may be incomplete, delayed, noisy, uncertain, or not applicable.
Decision log
A fictional record of approvals, exceptions, risk acceptance, rollback, closure, reopening, and retirement decisions.
Documentation debt
Fictional risk created by missing, stale, contradictory, ownerless, inaccessible, or untested documentation.
Operational readability
The fictional degree to which analysts and owners can quickly understand and use the documentation.
Leadership summary
A fictional concise explanation of mission value, readiness, limits, resources, milestones, residual risks, and decisions needed.
Retirement record
A fictional document confirming why a detection is no longer needed, which replacement exists, which dependencies are removed, and which evidence is retained.
Documentation review date
The fictional scheduled or event-triggered point when an artifact must be revalidated.
Instructional Section 1
Apply Ten Documentation Principles
Document the decision, not only the rule
A fictional detection document should explain which defender question and analyst decision the capability supports.
Strong practice
State that the detection helps determine whether temporary emergency authority remained effectively active beyond approval.
If ignored
Technical logic may exist without a clear mission or triage purpose.
Use one source of truth
Fictional purpose, scope, sources, logic, tests, owners, metrics, and lifecycle should be coordinated through a controlled specification.
Strong practice
Link supporting artifacts to one versioned detection identifier.
If ignored
Different teams may use contradictory assumptions and outdated versions.
Separate direct facts from derived context
Fictional documents should label source-recorded fields, normalized fields, enrichment, owner statements, and hypotheses distinctly.
Strong practice
Mark service criticality as derived and role state as direct source evidence.
If ignored
Derived context may be treated as authoritative fact.
Make source health part of the specification
Fictional documentation should state how Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering evidence changes behavior.
Strong practice
Document lower authorization confidence when group evidence is delayed.
If ignored
Analysts may interpret degraded evidence as normal.
Document expected alerts
Fictional documentation should explain which approved or benign conditions remain intentionally visible.
Strong practice
Describe current approved extensions as Expected alerts rather than false positives.
If ignored
Useful awareness may be tuned away or mislabeled.
Document what the detection cannot prove
Fictional alert matches should never silently imply intent, compromise, root cause, complete scope, or impact.
Strong practice
State that stale assignment does not prove misuse or harmful action.
If ignored
Alert language may drive unsupported escalation.
Keep tests connected to requirements
Fictional positive, negative, boundary, degraded-source, privacy, and regression cases should trace to specification statements.
Strong practice
Link the valid-extension test to the documented expected-alert behavior.
If ignored
Tests may pass without validating the actual requirement.
Assign artifact-level owners
Fictional specification, source map, field dictionary, test library, runbook, metrics, and retirement records need accountable roles.
Strong practice
Assign source owners to field meaning and detection owners to logic and alert behavior.
If ignored
Documentation becomes stale because everyone owns it generally and no one owns it specifically.
Record changes and rollback
Fictional documentation should preserve version, rationale, approvals, tests, observation, metrics, rollback, and completion.
Strong practice
Record why extension context was added and which false-negative regression cases must still pass.
If ignored
Future reviewers cannot understand why the current behavior exists.
Retire documentation with the detection
Fictional retirement should confirm replacement coverage, source removal, exception removal, artifact retention, lessons learned, and residual risk.
Strong practice
Close the specification only after the replacement and dependencies are validated.
If ignored
Old artifacts may continue guiding analysts after the capability changes.
Instructional Section 2
Maintain Ten Core Documentation Artifacts
Detection overview
Purpose
Explain the fictional mission risk, defender question, users, stakeholders, scope, exclusions, non-proof statement, readiness, and value.
Required fictional content
Identifier, title, owner, status, version, purpose, mission risk, primary question, scope, exclusions, safety boundary, limitations, and review date.
Primary audience
Analysts, detection engineers, service owners, risk owners, and leadership.
Risk if stale
The capability may continue after its mission, owner, scope, or risk has changed.
Source and field specification
Purpose
Document fictional evidence provenance, field meaning, timing, transformations, health, coverage, privacy, and ownership.
Required fictional content
Source categories, required and optional fields, schema versions, event time, collection time, processing time, transformations, retention, health states, and owners.
Primary audience
Detection owners, source owners, analysts, privacy reviewers, and testers.
Risk if stale
Schema drift or field misunderstanding may create false positives, false negatives, or false confidence.
Logic specification
Purpose
Explain fictional conditions, relationships, sequence, windows, thresholds, context, exclusions, missing-data behavior, confidence, and severity.
Required fictional content
Logic narrative, dependencies, correlation keys, timing, expected alerts, exclusions, source-health behavior, confidence, severity, and non-proof limits.
Primary audience
Detection owners, reviewers, testers, and analysts.
Risk if stale
Current behavior may differ from the documented logic.
Alert contract
Purpose
Define what the fictional alert must communicate and which questions it should help answer.
Required fictional content
Title, observation, primary question, evidence, context, source health, confidence, severity, priority, alternatives, next questions, owners, and limits.
Primary audience
Analysts, case owners, service owners, and leadership reviewers.
Risk if stale
The alert may technically fire but fail to support a consistent decision.
Analyst runbook
Purpose
Guide fictional triage through evidence requests, decision states, escalation, closure, reopening, and response boundaries.
Required fictional content
Question order, evidence sources, privacy limits, owners, states, escalation criteria, closure criteria, reopen triggers, and residual-risk documentation.
Primary audience
Analysts, incident coordinators, source owners, service owners, and reviewers.
Risk if stale
Analysts may collect irrelevant evidence, escalate too early, or close too soon.
Test and validation package
Purpose
Demonstrate fictional behavior across positive, negative, boundary, degraded-source, change, privacy, recovery, and regression cases.
Required fictional content
Test charter, dataset dictionary, case catalog, expected results, observed results, defects, actions, validation gates, owners, and residual risks.
Primary audience
Detection owners, testers, source owners, privacy reviewers, and approvers.
Risk if stale
A detection may appear validated even though the environment or logic has changed.
Tuning and exception register
Purpose
Record fictional enrichment, thresholds, grouping, deduplication, severity, confidence, exclusions, suppression debt, tests, expiration, and rollback.
Required fictional content
Problem, root cause, proposal, context, owner, expiration, tests, before-and-after metrics, rollback, completion, and review triggers.
Primary audience
Detection owners, analysts, risk owners, service owners, and reviewers.
Risk if stale
Temporary exceptions may become permanent blind spots.
Metrics and quality report
Purpose
Track fictional alert usefulness, expected alerts, false positives, false negatives, Unknown outcomes, source degradation, analyst effort, user impact, privacy, and lifecycle debt.
Required fictional content
Metric definition, data source, period, limitations, trends, findings, owner, action, due date, and confidence.
Primary audience
Detection owners, quality reviewers, analysts, service owners, and leadership.
Risk if stale
Leadership may rely on alert volume or misleading labels instead of meaningful quality.
Change and decision log
Purpose
Preserve fictional approvals, version changes, risk acceptance, exceptions, rollback, completion, and reopen decisions.
Required fictional content
Date, version, change, reason, evidence, approver, tests, metrics, rollback, residual risk, and next review.
Primary audience
Detection owners, auditors, risk owners, source owners, and leadership.
Risk if stale
Future maintainers cannot explain why the current design behaves as it does.
Retirement record
Purpose
Close the fictional capability safely when the risk, service, source, replacement, or mission changes.
Required fictional content
Reason, replacement, source removal, exception removal, final tests, residual risk, retained evidence, owner, closure date, and lessons learned.
Primary audience
Detection owners, source owners, service owners, risk owners, and leadership.
Risk if stale
Old rules, sources, runbooks, or exceptions may remain active after retirement.
Instructional Section 3
Write Twelve Specification Sections
1
Identity and version
What fictional identifier, title, status, version, owner, approver, creation date, review date, and retirement state apply?
Strong fictional example
DET-ID-004, Stale Emergency Authority, version 3, Conditional, reviewed after identity workflow change.
Weak example
Admin alert, current version.
2
Purpose and mission risk
Which fictional user, service, identity, supplier, data, policy, evidence, availability, or recovery outcome is protected?
Strong fictional example
Prevent emergency authority from outliving its approved recovery purpose.
Weak example
Detect suspicious access.
3
Defender questions
Which primary and supporting fictional questions should the alert help answer?
Strong fictional example
Did temporary emergency authority remain effectively active beyond approval without a valid extension?
Weak example
Was there an attack?
4
Scope and exclusions
Which fictional identities, devices, services, destinations, environments, states, periods, and evidence are covered or excluded?
Strong fictional example
Covers emergency roles in normal and recovery states; excludes training-only role records with separate identifiers.
Weak example
Covers administrators.
5
Evidence requirements
Which fictional sources, fields, timing, relationships, provenance, health, and alternate evidence are required?
Strong fictional example
Role, group, approval end, extension, session, revocation, service, owner, and source-health records.
Weak example
Identity logs.
6
Logic narrative
Which fictional conditions, relationships, sequence, windows, context, exclusions, and missing-data behavior apply?
Strong fictional example
Role appears active after approval end, no current matching extension exists, and evidence health determines confidence.
Weak example
Alert on late role.
7
Alert contract
Which fictional observation, evidence, source health, confidence, severity, priority, alternatives, questions, owners, and limits must appear?
Strong fictional example
Show role state, expiration, extension, group health, session state, service, owner, and non-proof statement.
Weak example
Show user and severity.
8
Analyst guidance
Which fictional evidence requests, decision states, escalation, closure, reopen, privacy, and response boundaries apply?
Strong fictional example
Validate extension freshness, group state, session scope, service impact, owner expectation, revocation, and closure criteria.
Weak example
Investigate and escalate if needed.
9
Testing and validation
Which fictional positive, negative, boundary, degraded-source, duplicate, change, privacy, recovery, and regression cases are required?
Strong fictional example
Valid extension, expired extension, delayed group, changed destination, new session, blind source, and replay duplicates.
Weak example
Test alert.
10
Metrics and quality
Which fictional usefulness, expected-alert, false-positive, false-negative, Unknown, source-health, effort, impact, and lifecycle measures apply?
Strong fictional example
Track expected extensions, known misses, Conditional outcomes, decision latency, source degradation, and review debt.
Weak example
Track alert count.
11
Ownership and lifecycle
Who owns fictional purpose, sources, logic, tests, alerts, runbook, privacy, risk, reviews, changes, rollback, and retirement?
Strong fictional example
Detection owner coordinates logic; source owner owns field meaning; identity owner owns role lifecycle.
Weak example
Security team owns it.
12
Limitations and residual risk
Which fictional gaps, assumptions, unobservable states, source dependencies, false-negative risks, privacy concerns, and future changes remain?
Strong fictional example
Effective access confidence is limited during group-source blind periods; session evidence is required as alternate support.
Weak example
No known limitations.
Instructional Section 4
Build a Versioned Field Dictionary
| Fictional field | Source | Meaning | Requirement | Transformation | Privacy | Limitation |
|---|---|---|---|---|---|---|
| role_state | Fictional identity-role source | Current observed assignment state for the invented emergency role. | Required | Normalized from invented Active, Revoked, Pending, and Unknown values. | Role state only; no unrelated personal profile data. | Assignment state does not prove effective group access or active use. |
| approval_end | Fictional access-approval source | Approved end time for temporary authority. | Required | Converted to the fictional common time format. | Purpose-limited approval timing. | Missing or stale approval data requires Conditional or Unknown behavior. |
| extension_state | Fictional extension registry | Whether a current approved extension covers the identity, role, purpose, destination, and period. | Required for normal authorization confidence | Derived from invented extension records and expiration. | Uses owner group and purpose category rather than personal narrative. | Extension does not authorize activity outside documented scope. |
| group_effective_state | Fictional group-membership source | Observed effective membership supporting role authority. | Required for high effective-access confidence | Normalized from invented membership and synchronization records. | Group category only. | May be delayed during synchronization or recovery. |
| session_state | Fictional session-evidence source | Whether an invented session remains active, ended, or Unknown. | Optional corroborating evidence | Grouped by invented identity and session relationship. | Session state and service category only. | Session visibility does not prove privileged action or harmful use. |
| service_category | Fictional service catalog | Mission category of the service reached by the invented session. | Optional enrichment for severity and ownership | Mapped to invented Student Support, Notification, Administration, or Recovery categories. | No real service names or internal routes. | Category may be stale after service or ownership change. |
| source_health | Fictional source-health dashboard | Healthy, Conditional, Degraded, Blind, Conflicting, or Recovering state for required evidence. | Required | Derived from invented freshness, completeness, schema, clock, coverage, and queue checks. | Operational metadata only. | A healthy state does not prove semantic correctness in every record. |
| owner_group | Fictional ownership registry | Accountable identity or service owner group. | Required for routing and confirmation | Normalized from invented organizational roles. | Group-level ownership only. | Ownership may be stale or disputed. |
Instructional Section 5
Define a Nine-Layer Alert Contract
Neutral alert title
Required
Fictional condition and subject without unsupported intent or cause.
Strong fictional example
Emergency Role Remains Visible after Approved End.
Weak version
Privileged Misuse Confirmed.
Primary defender question
Required
The exact fictional decision question supported by the alert.
Strong fictional example
Did temporary emergency authority remain effectively active beyond approval without a valid extension?
Weak version
Is this malicious?
Observation
Required
The fictional matched condition and direct evidence.
Strong fictional example
Role state is Active twenty minutes after approval end.
Weak version
The user abused access.
Source health
Required
Fictional status for every required source and affected conclusion.
Strong fictional example
Role current; group delayed; extension freshness Unknown.
Weak version
All sources online.
Context
Required
Fictional identity, role, owner, service, destination, change, extension, session, and mission information needed for the question.
Strong fictional example
Recovery role, student-support service, no current extension supplied, one active session.
Weak version
Full identity profile and unrelated history.
Confidence, severity, and priority
Required
Separate fictional evidence certainty, potential impact, and review urgency.
Strong fictional example
Observation confidence High; authorization confidence Moderate; severity High; priority High.
Weak version
Risk score 92.
Alternatives and limits
Required
Fictional plausible explanations and non-proof statements.
Strong fictional example
Extension delay, synchronization lag, incomplete closure, or stale source remain possible; misuse is unconfirmed.
Weak version
Likely compromise.
Next questions and owners
Required
Ordered fictional questions and accountable roles.
Strong fictional example
Source owner validates extension freshness; identity owner confirms approval; service owner validates session purpose.
Weak version
Investigate immediately.
Decision criteria
Required
Fictional escalation, Expected, Conditional, Unknown, closure, and reopen conditions.
Strong fictional example
Escalate on confirmed effective authority and active impact; close after revocation, session review, source reconciliation, owner validation, and residual-risk documentation.
Weak version
Close when alert stops.
Instructional Section 6
Use Eight Documentation Lifecycle States
Draft
Meaning
The fictional purpose, scope, sources, logic, tests, owners, or limits remain incomplete.
Required artifacts
Initial overview, source list, logic narrative, safety boundary, and open-question register.
Exit path
Move to Review when the specification and supporting artifacts are complete enough for challenge.
In Review
Meaning
Fictional detection, source, service, identity, privacy, test, and risk owners are validating the package.
Required artifacts
Review comments, evidence, disagreements, actions, due dates, and revised version.
Exit path
Move to Conditional, Approved, Rejected, or Draft.
Conditional
Meaning
The fictional detection may proceed in limited scope while known source, test, context, privacy, ownership, or lifecycle conditions remain.
Required artifacts
Conditions, owner, due date, observation, metrics, rollback, residual risk, and approval limit.
Exit path
Move to Approved, Rolled Back, or Retired.
Approved
Meaning
The fictional package satisfies required purpose, evidence, logic, test, privacy, ownership, rollback, and lifecycle gates.
Required artifacts
Signed approval, current version, review date, baseline metrics, and distribution record.
Exit path
Move to Observing, Change Review, or Retired.
Observing
Meaning
The fictional detection is being measured for alert usefulness, expected alerts, false positives, false negatives, Unknowns, source health, effort, impact, and documentation gaps.
Required artifacts
Observation metrics, findings, defects, actions, owner decisions, and next review.
Exit path
Move to Approved, Conditional, Change Review, Rolled Back, or Retired.
Change Review
Meaning
A fictional source, field, schema, logic, identity, service, policy, workflow, supplier, privacy, or mission change may invalidate the current package.
Required artifacts
Change description, affected artifacts, tests, metrics, risk, approval, and rollback.
Exit path
Move to Approved, Conditional, Rolled Back, or Retired.
Rolled Back
Meaning
A fictional change caused unacceptable quality, coverage, source, privacy, user, or operational impact.
Required artifacts
Rollback decision, restored version, defect evidence, impact, lessons learned, and retest plan.
Exit path
Move to Draft, In Review, Conditional, or Retired.
Retired
Meaning
The fictional detection is no longer needed or has been replaced.
Required artifacts
Retirement reason, replacement validation, source and exception removal, retained evidence, owner signoff, and lessons learned.
Exit path
Remain retired unless formally reopened.
Instructional Section 7
Measure Eight Documentation Quality Dimensions
Documentation completeness
Review question
Do fictional purpose, scope, evidence, logic, alert, runbook, tests, metrics, owners, limitations, and lifecycle artifacts exist?
Fictional evidence
Artifact inventory, required-section checklist, owners, and review records.
Limitation
Complete sections may still be inaccurate or stale.
Documentation freshness
Review question
Were fictional artifacts reviewed after relevant source, schema, service, identity, policy, workflow, privacy, or mission changes?
Fictional evidence
Review dates, triggers, change log, source versions, and owner confirmation.
Limitation
A recent date does not prove meaningful review.
Traceability
Review question
Can fictional requirements be linked to sources, fields, logic, tests, alerts, decisions, changes, and owners?
Fictional evidence
Identifiers, links, matrices, test references, and version history.
Limitation
Strong linking does not prove the requirement itself is correct.
Analyst usability
Review question
Can fictional analysts understand the alert, evidence, questions, source health, limits, owners, escalation, and closure?
Fictional evidence
Walkthroughs, decision latency, evidence-request count, feedback, and rework.
Limitation
Fast use can still hide shallow or incomplete analysis.
Owner responsiveness
Review question
Do fictional documentation owners update artifacts and answer assigned questions by required dates?
Fictional evidence
Owner matrix, requests, responses, due dates, overdue items, and escalations.
Limitation
Fast response does not prove the content is correct.
Test traceability
Review question
Does each fictional specification requirement have relevant positive, negative, boundary, degraded, privacy, and regression evidence?
Fictional evidence
Requirement-to-test matrix, results, defects, and validation gates.
Limitation
Passing tests represent only the cases included.
Documentation debt
Review question
How many fictional artifacts are missing, stale, contradictory, ownerless, inaccessible, or overdue?
Fictional evidence
Debt register, risk rating, owners, due dates, milestones, and residual risk.
Limitation
Counting debt does not show which item has the greatest mission impact.
Retirement readiness
Review question
Can the fictional organization safely remove the detection, sources, exceptions, runbooks, metrics, and artifacts when the capability ends?
Fictional evidence
Replacement coverage, dependency map, exception register, source map, final tests, and retirement plan.
Limitation
A written plan does not prove all dependencies are known.
Fictional Documentation Architecture
Northbridge Detection Documentation Model
This conceptual model is completely invented and intentionally non-operational. It teaches documentation relationships without real rules, source names, fields, identities, systems, domains, services, suppliers, runbooks, alerts, or internal architecture.
Mission layer
Purpose, risk, question, scope, exclusions, limits
Evidence layer
Sources, fields, provenance, timing, health, privacy
Logic layer
Conditions, relationships, context, missing-data behavior
Validation layer
Tests, defects, metrics, quality, regression, gates
Fictional Documentation Core
Overview
Why, who, what, scope, status, review
Specification
Sources, fields, logic, context, limits
Alert contract
Observation, evidence, health, questions, owners
Runbook
Requests, states, escalation, closure, reopen
Testing
Cases, expected, observed, defects, regression
Quality
Usefulness, misses, effort, impact, debt
Change
Version, rationale, approval, rollback, completion
Retirement
Replacement, removal, retention, lessons
Analyst output
Usable alerts, questions, evidence, states, closure
Owner output
Dependencies, changes, tests, actions, residual risk
Leadership output
Value, readiness, limits, resources, milestones
Portfolio boundary
Fully fictional, privacy-safe, non-operational
Fake Dashboard
Fake Northbridge Detection Documentation Dashboard
Fictional artifact completeness, freshness, traceability, ownership, testing, debt, and retirement status for training only.
Required documentation artifacts complete
7 / 10
Alert contract, retirement record, and source-health ownership remain incomplete.
Artifacts reviewed after recent changes
5 / 10
Field dictionary, analyst runbook, metrics report, and exception register require revalidation.
Open documentation debt items
8
Missing owners, stale closure criteria, unlinked tests, incomplete rollback, and undocumented residual risks remain open.
Fake SOC Alert
Detection Documentation No Longer Matches Current Evidence Behavior
Source: Fake Northbridge Documentation Quality Console • Time: 3:16 PM
The fictional role source and extension context are current, but the field dictionary omits the new extension freshness state, the runbook closes on alert disappearance, the alert contract hides source-health differences, and the change log lacks rollback and observation metrics.
Defensive recommendation: Keep the fictional documentation package Conditional. Update source and field specifications, alert contract, runbook closure criteria, test traceability, artifact ownership, change rationale, rollback, metrics, residual risk, and review triggers.
Fake Log Panel
Fake Documentation Review Timeline
training-log-viewer.log
09:00 DOC overview='current' 09:08 DOC source-map='partial' 09:16 DOC field-dictionary='stale-extension-field' 09:24 DOC logic-spec='partial-scope' 09:32 DOC alert-contract='missing-source-health' 09:40 DOC runbook='stale-closure' 09:48 DOC test-package='conditional' 09:56 DOC tuning-register='current' 10:04 DOC metrics='stale' 10:12 DOC change-log='missing-rollback' 10:20 OWNER detection='assigned' 10:28 OWNER source-health='missing' 10:36 OWNER privacy='missing' 10:44 TRACE tests-to-requirements='partial' 10:52 LIMITATIONS documented='incomplete' 11:00 DEBT open-items='8' 11:08 STATUS documentation='conditional' 11:16 REVIEW trigger='identity-workflow-change' 11:24 CONFIDENCE package='moderate' 15:16 ALERT issue='documentation-drift'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What the Documentation Evidence Supports—and What Remains Incomplete
DOC-01
Fictional detection overview
Observation
The stale-role detection has a clear mission risk and primary defender question.
Supports
The capability has a documented purpose and bounded decision.
Does not prove
The overview does not prove sources, logic, tests, or alert behavior are current.
Documentation use
Anchor the remaining artifacts to the same identifier and version.
DOC-02
Fictional source specification
Observation
Role, approval end, extension, group, session, service, owner, and source-health fields are documented.
Supports
The evidence dependencies are mostly visible.
Does not prove
The extension-source freshness rule and group-source recovery behavior are incomplete.
Documentation use
Mark the specification Conditional and add missing health behavior.
DOC-03
Fictional logic narrative
Observation
The design evaluates role state after expiration and checks for a current extension.
Supports
The core conceptual condition is documented.
Does not prove
Changed destinations, new sessions, and conflicting sources are not addressed.
Documentation use
Add scope-change and conflict behavior with tests.
DOC-04
Fictional alert contract
Observation
The alert displays role state and severity but omits source health, confidence separation, alternatives, and owner questions.
Supports
The alert exists but does not fully support analyst decisions.
Does not prove
The document does not prove analysts currently mis-handle every case.
Documentation use
Expand the alert contract and test analyst usability.
DOC-05
Fictional test package
Observation
Positive, negative, valid-extension, boundary, delayed-group, and recovery replay cases exist.
Supports
Several important behaviors are validated.
Does not prove
Privacy, changed-destination, new-session, and retirement cases remain incomplete.
Documentation use
Maintain Conditional status and complete validation gates.
DOC-06
Fictional analyst runbook
Observation
The runbook asks for extension, group, session, and service evidence but closes when the alert disappears.
Supports
The evidence questions are partially useful.
Does not prove
Closure behavior is incomplete and may hide unresolved authority or source state.
Documentation use
Replace alert-silence closure with evidence-based criteria.
DOC-07
Fictional ownership matrix
Observation
Detection and identity owners are assigned, but source-health and privacy artifacts lack owners.
Supports
Some lifecycle accountability exists.
Does not prove
Unowned artifacts may become stale or inconsistent.
Documentation use
Assign artifact-level source and privacy owners.
DOC-08
Fictional change log
Observation
Extension context was added after false positives, but the rationale, failed tests, observation metrics, and rollback are missing.
Supports
A meaningful change occurred.
Does not prove
Future maintainers cannot reconstruct why the current design exists or when to reverse it.
Documentation use
Complete the change and decision record.
Analyze the Evidence
Which Documentation Decision Is Best Supported?
The overview and primary defender question are current.
The field dictionary omits extension freshness behavior.
The logic narrative lacks changed-destination and conflicting-source behavior.
The alert contract hides source health and confidence differences.
The runbook closes when the alert disappears.
Several important tests exist, but privacy and new-session cases remain incomplete.
Source-health and privacy artifacts lack owners.
The change log lacks rationale, observation metrics, and rollback.
Which conclusion most responsibly represents the fictional documentation review?
Common Mistakes
Avoid Ten Detection Documentation Errors
Documentation begins with technical syntax
Fictional observation
A fictional specification starts with logic fragments but never states the mission risk or defender question.
Decision impact
Reviewers cannot judge whether the capability supports a valuable decision.
Professional correction
Begin with purpose, mission, question, scope, non-proof statement, and stakeholders.
Sources are listed without field meaning
Fictional observation
A fictional document says identity logs are required but does not define role, extension, group, or timing fields.
Decision impact
Field semantics and source dependencies remain ambiguous.
Professional correction
Use a versioned field dictionary with provenance, meaning, transformations, privacy, and limitations.
Logic documentation ignores degraded evidence
Fictional observation
A fictional narrative explains normal matching but not delayed, missing, conflicting, blind, or recovering sources.
Decision impact
Analysts may interpret degraded results with full confidence.
Professional correction
Document explicit source-health states and missing-data behavior.
Alert documentation repeats the alert title
Fictional observation
A fictional alert contract contains a title and severity but no evidence, questions, source health, alternatives, or owners.
Decision impact
The alert is visible but not decision-ready.
Professional correction
Define the full alert contract and test analyst usability.
Runbook says investigate
Fictional observation
A fictional analyst guide provides generic instructions without ordered questions or evidence requests.
Decision impact
Triage becomes inconsistent and privacy-heavy.
Professional correction
Use purpose-limited questions, owners, states, criteria, and stop conditions.
Tests are stored separately with no traceability
Fictional observation
Fictional test cases do not reference requirements, logic versions, defects, or changes.
Decision impact
Passing results cannot prove current specification behavior.
Professional correction
Create requirement-to-test and change-to-regression links.
Changes overwrite history
Fictional observation
A fictional document is updated without preserving the previous version, reason, approval, tests, metrics, or rollback.
Decision impact
Future reviewers lose design intent and recovery options.
Professional correction
Maintain versioned change and decision logs.
One broad owner is assigned
Fictional observation
A fictional record says Security owns every artifact.
Decision impact
Source, privacy, service, identity, testing, and retirement responsibilities remain unclear.
Professional correction
Assign artifact-level and question-level owners.
No limitations section
Fictional observation
A fictional specification claims complete coverage and no known risks.
Decision impact
Unknown false negatives, source gaps, stale context, and untested states become invisible.
Professional correction
Document assumptions, known gaps, unobservable conditions, residual risks, and review triggers.
Real internal documentation appears in a portfolio
Fictional observation
A fictional learning project includes copied internal diagrams, source names, field values, alerts, runbooks, screenshots, or owner roles.
Decision impact
Sensitive systems, people, defensive capabilities, and operations may be exposed.
Professional correction
Invent every artifact, source, field, diagram, owner, test, date, decision, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Detection Documentation Package
Use only the supplied fictional information on this page. Do not copy, expose, upload, reproduce, inspect, or transform any real detection rule, source map, field dictionary, alert, runbook, diagram, incident, account, endpoint, network, domain, supplier, platform, organization, or internal document.
1
Create the documentation charter
Define the fictional detection identifier, mission, scope, stakeholders, safety boundary, artifact set, owners, review triggers, and completion criteria.
Required output
Detection documentation charter.
Quality check
Every artifact is fictional and tied to one controlled identifier.
2
Write the overview
Document fictional purpose, mission risk, primary defender question, scope, exclusions, expected alerts, non-proof statement, readiness, and residual risk.
Required output
Detection overview.
Quality check
The overview explains why the capability exists before how it works.
3
Document sources and fields
Create fictional source categories, field definitions, timing, transformations, requirements, health behavior, privacy purpose, coverage, and owners.
Required output
Source map and field dictionary.
Quality check
Every required and optional field has meaning and limitation.
4
Write the logic narrative
Describe fictional conditions, relationships, sequence, thresholds, windows, context, exclusions, missing-data behavior, confidence, severity, and limits.
Required output
Versioned logic specification.
Quality check
The narrative is conceptual, explainable, and non-operational.
5
Define the alert contract
Specify fictional title, observation, question, evidence, source health, context, confidence, severity, priority, alternatives, owners, and criteria.
Required output
Alert presentation contract.
Quality check
The alert supports the intended analyst decision.
6
Write the analyst runbook
Create fictional ordered questions, purpose-limited evidence requests, owners, states, escalation, closure, reopen, privacy, and response boundaries.
Required output
Analyst decision runbook.
Quality check
Another analyst can reach a consistent bounded decision.
7
Connect tests and defects
Link fictional requirements to positive, negative, boundary, degraded, change, privacy, recovery, and regression cases.
Required output
Requirement-to-test traceability matrix.
Quality check
Every important behavior has evidence and known gaps.
8
Document quality and tuning
Record fictional metrics, expected alerts, false positives, false negatives, Unknown outcomes, source degradation, effort, impact, exceptions, and suppression debt.
Required output
Quality, tuning, and exception package.
Quality check
Lower alert volume is never the only success measure.
9
Record decisions and lifecycle
Maintain fictional versions, approvals, changes, observation, rollback, completion, review triggers, residual risk, and retirement readiness.
Required output
Change, decision, and lifecycle log.
Quality check
Future reviewers can reconstruct why the design exists.
10
Create audience summaries
Prepare fictional analyst, owner, privacy, risk, and leadership summaries using only the detail each audience needs.
Required output
Role-based documentation set.
Quality check
Public portfolio material contains no real internal details.
Scenario Decision Lab
The Team Wants One Short Document Instead of a Documentation Set
A fictional team proposes replacing the overview, source specification, logic narrative, alert contract, runbook, test package, metrics, and change history with one brief page that lists the alert title and owner.
Scenario Decision Lab
The Detection Changes but the Runbook Does Not
A fictional extension source adds a freshness state, and the logic now returns Conditional when freshness is Unknown. The analyst runbook still tells reviewers to treat any extension record as current and close the alert.
Advanced Challenge
Create a Documentation System That Survives Staff and Technology Change
Fictional Northbridge has detections for privileged access, suppliers, network behavior, DNS, wireless, applications, source health, and recovery. Documentation exists in separate locations, source owners have changed, tests are not linked to requirements, runbooks disagree with alert behavior, and no retirement records exist.
Create artifact governance
Define fictional required artifacts, templates, owners, access, versions, review dates, quality checks, and retirement.
Create traceability
Link fictional mission risks, questions, sources, fields, logic, tests, alerts, decisions, changes, metrics, and owners.
Create source-health documentation
Document fictional Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering behavior.
Create operational runbooks
Use fictional ordered questions, evidence requests, ownership, states, escalation, closure, reopen, privacy, and response boundaries.
Create documentation quality review
Measure fictional completeness, freshness, traceability, usability, ownership, test linkage, debt, and retirement readiness.
Create audience summaries
Prepare fictional analyst, owner, privacy, risk, and leadership views without exposing internal operational detail.
Challenge output
Produce a fictional documentation-governance charter, artifact catalog, overview template, source and field template, logic template, alert contract, analyst runbook, test traceability matrix, tuning register, metrics report, owner matrix, change and decision log, documentation-debt register, residual-risk statement, retirement template, analyst summary, and leadership summary.
Defender Habits
Detection Documentation Checklist
Check Your Understanding
A5.9 Mini Quiz: Detection Documentation
Choose your answers first. Explanations appear only after submission.
1. What should appear first in a strong fictional detection specification?
2. Why is a field dictionary important?
3. What should fictional documentation say about a delayed required source?
4. Which fictional alert contract is strongest?
5. Why should documentation link requirements to tests?
6. What is the strongest closure documentation?
7. Which portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Detection Documentation Package for the Northbridge Student-Support Cooperative. Include mission, purpose, scope, stakeholders, exclusions, safety boundary, at least twelve fictional detections, detection identifiers, titles, versions, statuses, owners, approvers, creation dates, review dates, mission risks, primary defender questions, supporting questions, non-proof statements, identity scope, device scope, service scope, destination scope, environment scope, operating states, exclusions, source categories, source dependencies, source owners, required fields, optional fields, field meanings, field types, values, schema versions, event time, collection time, processing time, transformations, retention, privacy purpose, source-health states, Healthy behavior, Conditional behavior, Degraded behavior, Blind behavior, Conflicting behavior, Recovering behavior, logic narratives, conditions, relationships, sequences, thresholds, time windows, context, exclusions, missing-data behavior, confidence, severity, alert titles, observations, evidence, enrichment, alternatives, analyst questions, evidence requests, decision states, escalation criteria, closure criteria, reopen criteria, response boundaries, test charters, positive tests, negative tests, boundary tests, source-degraded tests, change tests, privacy tests, recovery tests, regression tests, expected outcomes, observed outcomes, defects, corrective actions, validation gates, tuning records, exception records, suppression debt, metrics, alert usefulness, expected alerts, false positives, false negatives, Unknown outcomes, source-health impact, analyst effort, user impact, privacy impact, documentation completeness, freshness, traceability, usability, owner responsiveness, test linkage, documentation debt, change history, approvals, observation periods, rollback, completion criteria, review triggers, known limitations, assumptions, residual risks, retirement records, replacement coverage, lessons learned, analyst summaries, owner summaries, privacy summaries, leadership summaries, reflection, and a statement that every organization, detection, source, field, alert, owner, test, date, decision, and outcome is invented.
Write fictional mission and decision purpose before technical behavior.
Use versioned linked artifacts rather than one giant unstructured page.
Make source health, expected alerts, limitations, residual risk, ownership, rollback, and retirement explicit.
Connect every major requirement to tests and every change to regression evidence.
Keep the entire artifact completely fictional, defensive, non-operational, privacy-safe, evidence-aware, maintainable, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready for the Detection Engineering Capstone Lab?
Before moving to A5.10, rate your readiness from 1 to 5 for mission documentation, source and field specifications, logic narratives, alert contracts, runbooks, test traceability, metrics, owners, changes, limitations, residual risk, review triggers, rollback, retirement, and complete fictionalization.
I can explain why fictional detection documentation is part of the control.
I can write a versioned overview, source map, field dictionary, logic narrative, alert contract, and runbook.
I can document source-health behavior and missing-data decisions.
I can connect requirements to tests, defects, changes, and regression.
I can assign artifact-level owners and review triggers.
I can document known limitations, residual risks, rollback, and retirement.
I can create audience-specific analyst, owner, privacy, risk, and leadership summaries.
I can produce a safe fictional documentation package without copying real internal material.
Record one fictional detection purpose, one required source, one field limitation, one alert-contract requirement, one runbook closure criterion, one documentation-debt item, and one question you will carry into A5.10.
Key Takeaways
What You Should Remember
1.Detection documentation should begin with fictional mission risk, defender questions, purpose, scope, exclusions, stakeholders, and non-proof statements.
2.Strong documentation connects fictional sources, fields, logic, tests, alerts, analyst decisions, owners, metrics, changes, limitations, and lifecycle.
3.Field dictionaries should document provenance, meaning, transformations, requirements, privacy purpose, source health, and limitations.
4.Alert contracts should separate observation, evidence, context, source health, confidence, severity, priority, alternatives, owners, limits, and decision criteria.
5.Analyst runbooks should use ordered questions, purpose-limited evidence requests, accountable owners, decision states, escalation, closure, reopen, privacy, and response boundaries.
6.Healthy, Conditional, Degraded, Blind, Conflicting, and Recovering source behavior belongs in the specification.
7.Requirements should trace to tests, defects, regression cases, changes, metrics, and review decisions.
8.Documentation needs artifact-level owners, version history, observation, rollback, review triggers, residual risk, and retirement records.
9.Complete documentation can still be stale, so freshness, usability, traceability, and owner responsiveness must be measured.
10.Every CyberShield documentation artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.
Navigation
Continue Module A5
Next, complete the A5 Detection Engineering Capstone Lab by designing, testing, tuning, documenting, and presenting a fully fictional detection program with evidence, analyst decisions, quality review, governance, and portfolio artifacts.