Service paths, dependencies and degraded modes

Week 1, day 3. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

1.2b Essential service paths and degraded modes

A running component is not a delivered business service

A library website may respond while the underlying booking system cannot display current rooms or accept a reservation. A backup monitor may report a completed job while no one has shown that the resulting copy can restore a correct schedule. A help desk may still take a patron's request while the computer-based reservation cannot be accepted. All three situations illustrate the same preparedness problem: the organization can truthfully say that some technology remains operational without establishing that the user's promised outcome is available.

The existing Chapter 01 begins correctly with a service map and a D1 evidence-readiness contract. A service map tells the responder which components and owners matter. D1 asks whether useful observations could be obtained under authority, including source semantics and missing evidence. A third question is needed: which exact user-facing functions would a component fault affect? Answering it requires a function-specific dependency model rather than treating every component as either globally healthy or globally fatal.

A service function is a specific operation with a defined useful result. A technical dependency is something required to carry out that operation in the stated architecture and mode. A degraded mode is a deliberately narrower operating state in which some activities continue but other service commitments cannot honestly be made.

These distinctions are consistent with the emphasis on service dependencies and business function recovery in NIST SP 800-184, Guide for Cybersecurity Event Recovery and with risk-aware response preparation in NIST SP 800-61 Revision 3. Those NIST publications do not specify Harbor Library's internal routes; PATH1 is original classroom reasoning material.

Begin with the promise made to a patron

Imagine five distinguishable functions for a hypothetical reservation service: an informational page responding, a current list of rooms being displayed, an authorized staff member editing a booking, a front-desk employee recording a pending request, and a new backup job obtaining its source data.

The results are not interchangeable. A successful informational page response says little about reservation accuracy. An accepted staff edit is a business-state change, potentially requiring authorization and durable storage. A manual request receipt is not acceptance of a reservation. A backup job's access to a database is not a tested restore or an accepted return to service.

A weak readiness statement says, "the app is available." A more useful statement says, "the authorized staff-edit function produced the expected change to the intended booking and a reviewer checked the resulting authoritative state in a controlled test." The second statement has a testable outcome and a declared scope.

At rapid-course depth, learners should identify the unit of success before selecting a test. Is the question about reaching a page, viewing a current room, placing a reservation, collecting a pending request or producing a backup object? Each unit needs a different answer and may have different technical dependencies.

This framing also improves incident communication. The service owner may legitimately approve a limited request-intake workaround, but staff must not announce that rooms are confirmed while writes are unavailable. An honest degraded-service notice should explain what the user can do, what remains pending and what must occur before confirmation is possible.

Express path assumptions as a small dependency table

The PATH1 teaching model uses components named web, identity, database, helpdesk and backup. These categories resemble the service map, but their specific connections are invented. The canonical R1–R8 records do not confirm this topology.

Lesson table; scroll horizontally to read all columns →

A component in a path is required under this model. If a required component is unavailable, the script predicts the function is impaired. If every required component is marked available, it predicts only structural possibility, not verified correctness. The model does not implement authentication, data persistence, cache validity, backup integrity, patron notification or performance.

These limitations are not weaknesses to conceal. They define which engineering question the model answers. A small, explicit model can help identify the next owner or test, provided no one promotes its predictions into real observations.

By contrast, D1's source contract asks whether an application audit or identity record could prove what actually happened. BSL1's business-rule exercise checks overlaps and cancellation semantics using separate invented booking records. PATH1 does neither. It asks which functions could lose their modeled prerequisites under component loss.

A single component failure may impair several different functions

Consider the independent hypothetical case where the PATH1 database becomes unavailable. Because room_view, staff_edit and new_backup_job all list it as required, the model predicts those three functions are impaired. The informational page and manual help-desk intake do not list it, so they remain structurally possible in this simplified design.

That prediction is not equivalent to "the website is healthy." A resident might reach a page but fail to view a trustworthy room list. It is also not equivalent to "the whole library cannot help anyone." Under the fictional fallback assumption, the help desk can still receive an unconfirmed request.

An identity-service failure has another shape. It impairs the modeled staff-edit path but does not necessarily impair room viewing. This does not establish that Harbor Library actually permits unauthenticated read access; it reflects only the independent fixture.

A help-desk failure can remove the manual fallback while website-mediated paths remain structurally possible. During ordinary operation this might be inconvenient; during a wider outage it could remove the only permitted path for receiving new requests. Thus the business importance of a dependency depends on the operating context.

The correct incident question is therefore not simply "which component is red?" It is which useful function is affected, what other path remains, and what legitimate promise can still be made? Component counts cannot substitute for that analysis.

Single points of failure must name their affected outcome

Calling a component a "single point of failure" is incomplete without naming the function it can prevent. In PATH1, failure of web alone prevents the informational page, room view and staff-edit route. It does not, under the stated fixture, prevent help-desk request intake or a new backup job.

Likewise, the database is a single required element for the modeled room view, but not for the informational page. A real application may have additional dependencies or a working alternate route; the PATH1 table provides no evidence about them.

For a function with all-required dependencies, failure of any listed component is sufficient to impair that particular modeled path. A real resilient design might instead have alternatives—such as two equivalent service instances or a controlled cached read. Such alternatives must be explicitly documented and tested before they are used in operational decisions.

This beginner model deliberately avoids probability estimates. A list of components does not provide failure rates, correlations, repair times or evidence that alternate capacity is usable. Assigning an invented likelihood of downtime would add precision without support.

The preparedness value of this reasoning is asking a service owner to identify what is truly essential and which alternate route can safely meet a narrower requirement. It does not authorize changing a production configuration.

Available, degraded, unavailable and unknown are different conclusions

A route can be modeled available, modeled impaired, observed to work in a bounded test, or not yet tested. These statements should not be collapsed into a single green/red label.

For PATH1, the supplied Python fixture uses Boolean component availability and predicts structural status. Real components can fail partially: a database may answer reads while rejecting writes; an identity service may validate old sessions but not new ones; a cache may return stale content. In those circumstances a simple Boolean may hide important uncertainty.

If an analyst cannot determine a component's actual state, it would be improper to enter True merely so the model returns a green result. Record the condition as unknown and ask what observation could resolve it. The classroom script omits a third state for simplicity; the learner must report that as a modeling limitation.

A successful response from a web endpoint also does not prove that a booking change was authorized and durably committed. A help-desk receipt does not prove a room assignment exists. These are examples of overclaiming from partial success.

An accurate report might say, "under the selected model, the informational page path remains structurally possible, while the booking write path is predicted unavailable." It should not claim that real patrons can safely use the service without a corresponding test and owner acceptance.

Design a degraded mode with explicit boundaries

A degraded mode is not simply "whatever still works." It should be defined in advance by the service owner, with conditions for activation, an approved workflow, a duration or review trigger, a message that accurately describes service limits, and a path back to normal operations.

For a hypothetical request-only help-desk mode, the owner would need to answer:

1. May staff receive requests while the authoritative reservation service is unavailable?
2. Which minimum details can be collected safely and for what purpose?
3. Does the request remain pending until a later authorized check?
4. Who maintains receipt order and prevents duplicates or conflicting instructions?
5. Who communicates the distinction between receipt and acceptance to patrons?
6. What is the escalation route if the desk cannot keep up or the request is urgent?
7. Who authorizes eventual reconciliation and confirms the resulting business state?
8. What observable result ends the degraded mode?

This is a proposed business contract, not a claim that the canonical Harbor Library help desk followed such a procedure. The later Module 3 MQ3 laboratory teaches detailed request reconciliation, but PATH1 asks an earlier, different question: Would that kind of fallback function remain technically possible under a specified component fault?

Manual intake may be unavailable by policy even when the help desk is working. Staff may lack capacity, approved paper procedures or privacy safeguards. A model's technical possibility never overrides the service owner's operating constraints.

A safe degraded-mode statement says, "the request may be recorded for review." A dangerous statement says, "the room is booked" when the accepted reservation has not been established.

Readiness needs a verification plan for each function

Before accepting the function table, a service owner and technical custodian should identify the test that would challenge it. A useful test plan includes:

• The function and promised outcome.
• The proposed required components.
• The specific isolated fault or unavailable component.
• The predicted impairment or alternative behavior.
• The positive technical observation to look for.
• A negative or business-safety check.
• The responsible owner and permitted environment.
• A source and timestamp for the actual result.
• The limit of the conclusion and the required review.

For the modeled room view, a technical response alone might be insufficient if it returns stale or unauthorized data. For staff editing, a successful request does not prove the intended authoritative value was committed. For a backup job, creation does not prove the object is recoverable. For help-desk intake, a receipt does not prove the request was accepted.

This plan should be compared with existing D1 and BSL1 artifacts without copying their content. D1 specifies how a record could be obtained and interpreted; BSL1 defines some correct booking-state behavior; PATH1 specifies which path's prerequisites are being challenged. A real isolated test might draw on all three, but the conclusions remain separate.

If the expected negative test fails, record the failure rather than silently weakening the acceptance rule. If the input data are incomplete or the supposed fault was not actually induced, report an inconclusive test rather than a clean pass.

Contrast a tempting wrong conclusion with a defensible one

Incorrect hypothetical analysis:

"The database is down but the homepage responds, so the service is healthy. Staff can take requests at the desk, which means reservations are still confirmed. The backup component remains online, so the library can already restore everything."

This assumes that the informational page represents all booking functions; that a pending manual request is a completed reservation; and that a backup component or job outcome proves tested recovery. None of the claims follows from the PATH1 model, and no database outage appears in canonical R1–R8.

Correct bounded analysis:

"In the independent PATH1 model, database unavailability predicts impairment of the room-view, staff-edit and new-backup-job paths, while the informational page and help-desk request intake remain structurally possible. Manual intake does not accept reservations, and no recovery test is supplied. These are sensitivity predictions from declared assumptions, not Harbor Library incident observations. The service owner would need to approve any degraded operating promise, and a separate authorized check would be required to establish actual function and business correctness."

The improvement is not simply cautious language. It identifies the unit of service, the source of the claim and the missing acceptance evidence.

Compare fault scenarios without turning them into canonical events

A useful offline rehearsal changes one modeled condition at a time and records which functions change classification. The student should begin with the baseline, simulate a database failure, restore the baseline and simulate identity failure. The same process can be used for help-desk and web failures.

Without resetting the model, conclusions can become mixed: a lingering database-down condition may make an identity test appear to impair more functions than it really does. The code below avoids this by evaluating independent failure sets rather than mutating the shared route definitions.

Comparisons should be explained in business terms. If identity failure affects only the staff-edit path, that is different from database failure affecting viewing, editing and new-backup creation. If help-desk failure removes intake, the potential harm depends partly on whether users have another approved means of making requests.

A two-component failure is useful as a negative control. With both database and help desk unavailable under PATH1, the remaining informational page cannot provide accepted booking writes or receive pending requests. It would be misleading to label that state "partially operational reservation service" without specifying the limited information-only function.

The fixture provides no frequency, probability or severity score for these scenarios. Those require information from the service owner and measured operational evidence outside the classroom.

Relationship to incident decisions at 09:05

Return to the actual fictional Round A source set. R1 reports a desk-a sign-in, R3 and R4 report booking changes, R5 is a patron concern, R6 describes scheduled training, R7 reports a backup-job completion and R8 lacks sufficient destination detail. These records support questions about approval, service state and identity context. They do not establish any PATH1 component outage.

A student might reasonably propose that the service owner clarify what would happen if the database were unavailable, or whether a request-only fallback is approved. That is a readiness question, not a finding about the incident.

A PATH1 scenario must never be inserted as an additional R-series row or used to justify the 09:05 restriction decision. Likewise, the later B19/B20 events or Branch S/P results cannot be imported backward to resolve the original uncertainty.

A high-quality responder can maintain two ledgers: the canonical evidence ledger, limited to released case records, and a model/test ledger, containing declared assumptions and hypothetical outcomes. This separation permits technically useful planning without fictionalizing production observations.

Section synthesis: resilience is a bounded service promise

Resilience is not a guarantee that every component stays online. It is the ability to define important user outcomes, identify how component failure could affect them, prepare acceptable narrower modes, and test what those modes actually deliver.

A website may be reachable while current room viewing is impaired. A help desk may be able to receive a request without confirming a reservation. A backup job may be possible without demonstrating recovery. Recognizing these distinctions improves the quality of incident questions and makes subsequent service-owner decisions more defensible.

The PATH1 laboratory is purposely small. It trains one transferable habit: predict structural consequences, identify the business promise, and demand appropriate observation before declaring service impact or recovery.

PATH1 Offline Laboratory — Functional Dependencies and Degraded Service

Classification: Independent, entirely synthetic modeling exercise. Not R1–R24, not the BSL1 booking-state fixture, not the technical-level L6 architecture and not a recorded Harbor Library outage.

Environment: Python 3 standard library, in memory. No files, network calls, real credentials or service modifications.

Prediction task: Before running, predict which functions remain in each scenario and whether the result means modeled staff-edit availability, request intake only or no modeled staff-edit/intake route.

The summary mode classifies only the staff-edit and request-intake paths. Read the separate available list before saying whether room viewing or any other function remains possible.

Complete Python program

ROUTES = {
    "site_reachable": {"web"},
    "room_view": {"web", "database"},
    "staff_edit": {"web", "identity", "database"},
    "manual_intake": {"helpdesk"},
    "new_backup_job": {"database", "backup"},
}

CASES = [
    ("BASE", set()),
    ("DATABASE_DOWN", {"database"}),
    ("IDENTITY_DOWN", {"identity"}),
    ("HELPDESK_DOWN", {"helpdesk"}),
    ("WEB_DOWN", {"web"}),
    ("DATABASE_AND_HELPDESK_DOWN", {"database", "helpdesk"}),
]

def assess_failed(failed):
    available = sorted(
        name for name, needs in ROUTES.items()
        if needs.isdisjoint(failed)
    )
    impaired = sorted(set(ROUTES) - set(available))

    if "staff_edit" in available:
        mode = "STAFF_EDIT_PATH_MODELED"
    elif "manual_intake" in available:
        mode = "NO_STAFF_EDIT_INTAKE_MODELED"
    else:
        mode = "NO_EDIT_OR_INTAKE_PATH"

    return available, impaired, mode

for name, failed in CASES:
    available, impaired, mode = assess_failed(failed)
    print(
        f"{name}: available={','.join(available)} "
        f"impaired={','.join(impaired)} mode={mode}"
    )

assert assess_failed({"database"})[2] == "NO_STAFF_EDIT_INTAKE_MODELED"
assert "room_view" not in assess_failed({"database"})[0]

Predict the six output lines before running the program, then compare your result with the PATH1 worked result in the final appendix. Keep PATH1 separate from the R-series case evidence.

Week 1 review unit 3 — Reject unknown names; model unknown states

Objective and counterexample

Distinguish an invalid component identifier from a valid component with unknown state. Then explain why a known failed prerequisite can establish modeled impairment even when another prerequisite is unresolved.

The original PATH1 evaluates a set of failed components. If the supplied set is {"databsae"}, the misspelled name intersects none of the five route dependency sets. The original function consequently returns every modeled function as available. This is a reproducible input-boundary limitation, not a report that a database or real service was healthy.

An identifier guard should reject that spelling rather than guess that the writer intended database. Silent correction could conceal a wrong source, a schema change or a different component. Request an explicit corrected input and preserve the original one.

A different problem arises when database is spelled correctly but its state is not known. Rejecting its name would be wrong; entering False would invent an outage; entering True would invent availability. The extension uses None to represent this narrowly defined unknown condition, with every component explicitly present in the state dictionary.

Reason through three states

PATH1 defines each route as an all-required set. Under that model, a function is:

Lesson table; scroll horizontally to read all columns →

Consider staff editing, which requires web, identity and database. With web and identity true and database unknown, the route is unresolved. With web true, identity false and database unknown, the route is impaired regardless of how the database uncertainty is later resolved. The known failed prerequisite is sufficient within this model. That conclusion does not identify the cause of a real outage, quantify harm or establish that an alternate architecture is absent.

Manual intake depends only on helpdesk in PATH1. If helpdesk is true, that route can remain possible while staff editing is impaired. “Possible” still means a modeled route, not a confirmed room booking, an approved fallback procedure or observed delivery of service.

Reproducible PATH1 extension

Run the complete original PATH1 listing first in a fresh session. Predict the first four new lines manually. The final loop checks all 3^5 = 243 partial assignments across the five components. For each assignment, it enumerates every complete Boolean assignment consistent with the declared unknowns and compares each function's possible outcomes with the three-state classification.

This comparison is an independent calculation over a finite declared model. It does not verify real topology, measurements, permissions, alternate paths or service correctness. For real systems, the assumptions themselves require authorized observation and owner review.

# Run after the complete PATH1 listing, in the same Python session.
W1_COMPONENTS = frozenset().union(*ROUTES.values())

def w1_assess_failed(failed):
    if type(failed) not in (set, frozenset):
        raise ValueError("INVALID_FAILURE_SET")
    if not failed.issubset(W1_COMPONENTS):
        raise ValueError("UNKNOWN_COMPONENT")
    return assess_failed(failed)

def w1_assess_state(state):
    if type(state) is not dict or set(state) != set(W1_COMPONENTS):
        raise ValueError("COMPONENT_SET_MISMATCH")
    if any(value is not None and type(value) is not bool for value in state.values()):
        raise ValueError("INVALID_COMPONENT_STATE")
    result = {}
    for function, needs in sorted(ROUTES.items()):
        values = [state[component] for component in needs]
        if any(value is False for value in values):
            result[function] = "IMPAIRED"
        elif any(value is None for value in values):
            result[function] = "UNRESOLVED"
        else:
            result[function] = "POSSIBLE"
    return result

try:
    w1_assess_failed({"databsae"})
except ValueError as error:
    print("W1_TYPO", str(error))
w1_state = {component: True for component in W1_COMPONENTS}
w1_state["database"] = None
print("W1_UNKNOWN_DB", w1_assess_state(w1_state)["staff_edit"])
w1_state["identity"] = False
print("W1_UNKNOWN_DB_IDENTITY_DOWN", w1_assess_state(w1_state)["staff_edit"])
print("W1_MANUAL", w1_assess_state(w1_state)["manual_intake"])

# Independent finite check: compare each partial assignment with every
# complete Boolean assignment consistent with it. No real system is queried.
from itertools import product
w1_names = sorted(W1_COMPONENTS)
w1_checked = 0
for values in product((False, True, None), repeat=len(w1_names)):
    partial = dict(zip(w1_names, values))
    unknown = [name for name in w1_names if partial[name] is None]
    completions = []
    for fill in product((False, True), repeat=len(unknown)):
        complete = {**partial, **dict(zip(unknown, fill))}
        completions.append(complete)
    actual = w1_assess_state(partial)
    for function, needs in ROUTES.items():
        outcomes = {all(complete[name] is True for name in needs) for complete in completions}
        expected = ("POSSIBLE" if outcomes == {True} else
                    "IMPAIRED" if outcomes == {False} else "UNRESOLVED")
        if actual[function] != expected:
            raise AssertionError((partial, function, actual[function], expected))
    w1_checked += 1
print("W1_PARTIAL_STATES_CHECKED", w1_checked)

Supplementary practice W1-R3

Objective: justify a result under incomplete component knowledge. Inputs: the five PATH1 functions, their original dependencies and the extension above. Required artifact: the five-line transcript; a table for all five functions with database unknown and all other components true; a second table after identity alone becomes false; and a two-sentence service-owner message distinguishing modeled intake from confirmed booking acceptance. Constraints: do not turn unknown into false, repair the typo silently, or import any modeled failure into R1–R8.

Assessment: one point each for typo rejection, the first complete function table, the second complete table, the limited service-owner message, and explaining what the finite enumeration does not verify. The original EX003 still requires its two dependency cards; this table is separate supplementary practice. Worked answer.

Review synthesis

An invalid name is an input defect. An unknown state is an unresolved premise. A known failed prerequisite can settle a modeled route without settling every other uncertainty.

Worked checkpoint

If the booking application responds but the authoritative reservation state is unknown, availability is not business correctness. A manual intake path may preserve a limited user promise, but it cannot be called confirmed booking acceptance without owner-approved reconciliation.

Practice — Lesson 03

EX003 — Service dependency

Objective: connect an incident signal to service outcomes and evidence owners. Inputs: the section 1.2 service map and R1–R8. Output: a two-row dependency card with dependency, possible user harm, supplied pointer, missing discriminating evidence and custodian. Choose two dependencies; for each, explain what an authorized check would distinguish. Do not call a potential harm a confirmed outage. A score of 2 needs two different dependencies and a test that could separate a service-state problem from account misuse.

Extension: For each of the two chosen service dependencies, distinguish a possible downstream business harm from an actual observation. Name one negative test that could weaken the proposed explanation and identify who would be authorized to request it.

For full credit: A 2-point answer explicitly connects different technical sources to different decisions. The database's current booking values cannot be inferred directly from R3–R4's edit history.

PATH1 supplementary task (after the required artifact):

Additional requirement: After the existing two dependency cards, choose one PATH1 modeled function and identify a component fault that would impair it. State an authorized functional check and a separate business correctness check. Do not claim that the PATH1 fault occurred in canonical R1–R8.

Worked answer: EX003 in the final appendix.

EX008 — Evidence quality

Objective: limit claims to what three different source types actually say. Inputs: R6–R8. Output: a three-row evidence-limit table with ID and time, narrow supported conclusion, tempting unsupported conclusion, and a follow-up source or test. A score of 2 treats a scheduled activity as distinct from an approved booking change, a completed backup job as distinct from a proven restore, and a summary missing destination detail as distinct from a verified absence of transfer.

PATH1 supplementary task (after the required artifact):

Additional requirement: In the R7 backup-status row, explain why modeled new_backup_job availability would not verify usable restore, acceptable elapsed recovery or owner-approved booking correctness. Preserve the original R6 training and R8 network-summary source limitations.

Worked answer: EX008 in the final appendix.

EX011 — Escalation trigger

Objective: specify when the initial choice must be reopened. Inputs: the R1–R8 snapshot and section 1.9. Output: two hypothetical observation/response rows with source that would verify the signal, harm or uncertainty affected, decision owner and next action. One trigger should concern continued booking change; the other should concern breadth or service impact. A score of 2 states that neither observation is present at 09:05 and avoids an automatic production action without approval.

Behavior-baseline extension: For the hypothetical service-impact trigger, specify a future owner-approved booking-state comparison against the applicable policy version, with the service owner confirming rule and scope. Keep the other trigger about a separately verified new unexplained edit. Neither signal is present in R1–R8; a rule mismatch does not prove cyber compromise.

Worked answer: EX011 in the final appendix.