A bounded triage question and revisable priority

Lesson 06 — A bounded triage question and revisable priority

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

2.1 An alert is a question to investigate

Module 1 established owners and a bounded record. Triage now asks what the signal means, what might be affected, how soon a decision is needed and which authorized check would reduce uncertainty. A detector may produce the label “suspicious login,” but that label is neither an identity proof nor a conclusion that the account was compromised. The analyst must retain the detector's raw observation, collection time and rule context while testing alternative explanations.

For Harbor Library, the first two hypotheses are H1: the booking edits were scheduled training and H2: the account was used outside the planned training. A third possibility, H3: the patron's report reflects a display or synchronization problem, reminds us that the reported symptom and the booking changes might have different causes. These hypotheses are teaching devices. They are not exhaustive and should be revised when evidence appears.

The initial action should be the smallest authorized check that could change the next decision. If a new edit is causing immediate harm, the incident lead can seek an urgent containment decision while collection continues. If the signal is stale and service impact is unknown, preserving records and checking the owner may be the more informative first step. Triage and containment can overlap; they are not a rigid sequence.

2.2 Prioritize harm, urgency and confidence separately

This book uses an illustrative classroom matrix, not a universal severity standard. Keep three judgments separate:

A case can be urgent even when confidence is low: continued edits could affect patrons while the cause remains uncertain. It can be well supported but low urgency after an authorized maintenance test has ended. The incident lead should record a provisional priority and the condition for changing it. Harbor Library's opening priority is “prompt review,” because a patron reported harm, yet the available records do not establish compromise or broad impact. This priority is a teaching judgment based on the fictional facts, not a prescribed incident category.

Two questions, four possibilities: authorized work can still leave a service problem

The priority matrix is easier to use when a question about permission is not allowed to answer a different question about service correctness. A planned operation can be performed incorrectly. An operation outside the applicable authorization can leave a value that happens to match the accepted target. Neither a good outcome nor a bad outcome identifies the human operator.

Use two propositions to make that distinction visible:

• A: the particular operation was within an applicable authorization, for the named object and operation time.
• M: an authorized comparison found a mismatch between that object's observed state and its accepted target, at the comparison time and target version.

A and M concern different observations. The operation time and comparison time need not be equal. Connecting the later state to the earlier operation requires a separate causal argument; this model does not supply it. A result about one booking does not measure effects on all patrons.

These four assignments are logical possibilities in a deliberately small teaching model, not four causes, four incident severities, equally likely outcomes or calibrated confidence scores. Allowing all four combinations does not assert statistical independence. An unresolved proposition is not false: without an adequate authorization check, A remains unknown rather than becoming A0.

flowchart TD
  Q["Freeze object, operation, times and target version"] --> A["Authorization question: was this operation permitted?"]
  Q --> M["Service question: does observed state match the accepted target?"]
  A --> L["Record each bounded finding and its supporting source"]
  M --> L
  L --> C["Keep cause, human identity and wider impact unresolved unless separately supported"]
  C --> R["Propose the next authorized check; do not invent its result"]

Text alternative: Freeze the scope first. Ask the authorization and service-state questions through their respective owners. Combine only the findings actually supported for that scope. A combined finding still does not identify a cause or a person. Choose the next authorized check from what remains unresolved, rather than treating the diagram as permission to collect data or change a service.

Worked synthetic example, separate from R1–R16. Suppose a training owner supplies a verified, applicable instruction permitting operation E1 on invented booking X21 at 10:00. A service owner separately verifies that X21's value at 10:10 differs from its accepted target version V4. These premises select A1M1. They do not show whether E1, a later edit, an incorrect implementation or another mechanism caused the mismatch. The decision can require attention to service correctness even though the authorization question about E1 has been answered. No X21 observation becomes evidence in Harbor Library's canonical packet.

Reproducible worked example: eliminating assignments is not proving a cause

Run the following complete Python 3 program in a fresh session. It uses only in-memory synthetic propositions: no network access, credentials, files or real records. compatible retains each assignment whose two values satisfy every supplied premise. Missing information is represented by omitting a premise, not by passing False or None. Its result is conditional on the premises; the function does not verify their sources.

"""Offline logical illustration; no real records, probabilities or actions."""
from itertools import product

FIELDS = {"authorized": 0, "mismatch": 1}
WORLDS = tuple(product((False, True), repeat=2))


def compatible(premises):
    """Return assignments consistent with explicitly supplied toy premises."""
    if not isinstance(premises, (tuple, list)):
        raise ValueError("premises must be a sequence of field/Boolean pairs")
    checked = []
    for premise in premises:
        if not isinstance(premise, (tuple, list)) or len(premise) != 2:
            raise ValueError("each premise must contain a field and a Boolean")
        field, value = premise
        if not isinstance(field, str) or field not in FIELDS:
            raise ValueError("unknown proposition")
        if type(value) is not bool:
            raise ValueError("a premise value must be an actual Boolean")
        checked.append((FIELDS[field], value))
    return tuple(w for w in WORLDS
                 if all(w[index] == value for index, value in checked))


def report(label, premises):
    states = compatible(premises)
    text = " ".join(f"A{int(a)}M{int(m)}" for a, m in states)
    print(f"{label}: {text or 'INCONSISTENT_PREMISES'}")


cases = (
    ("NO_PREMISES", ()),
    ("AUTH_ONLY", (("authorized", True),)),
    ("MISMATCH_ONLY", (("mismatch", True),)),
    ("AUTH_AND_MISMATCH", (("authorized", True), ("mismatch", True))),
    ("AUTH_TWICE", (("authorized", True), ("authorized", True))),
    ("NO_AUTH_BUT_MATCH", (("authorized", False), ("mismatch", False))),
    ("CONFLICT", (("authorized", True), ("authorized", False))),
)
for label, premises in cases:
    report(label, premises)

for label, premises in (
    ("STRING_FALSE", (("authorized", "False"),)),
    ("MISSING_NOT_FALSE", (("mismatch", None),)),
    ("UNMODELED_ACTOR", (("operator_is_person_x", True),)),
):
    try:
        compatible(premises)
    except ValueError:
        print(f"{label}: INVALID_PREMISE")
    else:
        raise AssertionError(f"{label} was incorrectly accepted")

Reproduced output:

NO_PREMISES: A0M0 A0M1 A1M0 A1M1
AUTH_ONLY: A1M0 A1M1
MISMATCH_ONLY: A0M1 A1M1
AUTH_AND_MISMATCH: A1M1
AUTH_TWICE: A1M0 A1M1
NO_AUTH_BUT_MATCH: A0M0
CONFLICT: INCONSISTENT_PREMISES
STRING_FALSE: INVALID_PREMISE
MISSING_NOT_FALSE: INVALID_PREMISE
UNMODELED_ACTOR: INVALID_PREMISE

Read the first six lines as a worked elimination argument. With no premises, all four assignments remain possible within the model. Authorization alone leaves both a matching and a mismatching service state. A mismatch alone leaves both authorization possibilities. Combining the two positive premises selects A1M1, but uniqueness within two modeled propositions is not unique causation. Repeating the authorization premise leaves the same two assignments; it does not answer the service question. A0M0 illustrates why a correct-looking result cannot supply missing authority.

The program does not model source reliability or statistical corroboration. Two genuinely independent observations can affect a real analyst's confidence in a proposition, but counting repeated filters here does not measure that change. Before describing two reports as independent, check whether they merely repeat one underlying observation. Do not convert the number of remaining assignments into an incident probability.

Adversarial interpretation. The conflicting pair says both A and not-A for what is supposed to be the same scoped proposition. Zero remaining assignments therefore means that the entered premises cannot all hold together under that interpretation. It does not establish that the service is safe, that an incident is impossible, or which source is wrong. Check for different objects, operation times, policy versions, scope, transcription mistakes or a genuine contradiction; retain both reports while the disagreement is resolved. A later authorization cannot silently replace the authorization applicable to the earlier operation.

The final three controls reject a textual Boolean, an unknown value presented as a finding, and an actor proposition that the model does not contain. Rejecting None is not a reason to replace it with False: omit that unresolved premise and report the missing check. This small program has no way to establish human identity, so an operator_is_person_x input must not be accepted as if it followed from A or M.

Apply the distinction to the existing EX014, without changing its format

At 09:05, use only R1–R8. At 09:20, the release permits R1–R16, but release does not turn every proposition into a known Boolean. R9 reports the B19 edit and R10 omits B19 from the supplied plan. That omission is a reason to investigate the operation's authorization, not a complete determination of A0. R11 is a patron report, not the authoritative observed-versus-accepted comparison required to establish M1. Neither checkpoint supplies the completed checks used in the independent X21 example.

For EX014, retain the same two-row table, existing required fields and 0–2 rubric. Write the two discriminating questions yourself before consulting the final EX014 answer. One row should specify the bounded owner/source check needed to resolve the operation's task authorization; the other should specify the bounded comparison needed to assess the booking state. In each row, identify a possible answer that would change that particular judgment and the causal or human-actor claim it would still leave unproved. A proposed check is not a completed result. The existing final worked answer remains the comparison point; this worked example adds no numbered exercise and does not replace that answer.

A useful self-check is to cover one row: can the remaining row actually answer both questions? An authorization result cannot substitute for a state comparison. A state comparison cannot retrospectively authorize an operation. The same discipline applies to the next TRI2 reassessment: R14's incomplete quiet-query summary is not a general negative result, and R15's 24-hour policy still has no confirmed deletion anchor. Answering A or M does not supply the missing coverage, retention anchor, collection, hold or containment authority.

Source boundary. NIST SP 800-61 Revision 3 places incident response recommendations within cybersecurity risk management. The A/M notation, four-assignment illustration, Python program and EX014 teaching connection here are original OpenCyber Academy teaching material, not a NIST classification, prescribed severity matrix or automatic response policy. The supplied case records and the existing exercise's release boundaries control what may be claimed about Harbor Library.

2.2a Reassessing triage priority under changing evidence

2.2a.1 Why a priority decision must be revisable

The existing §2.2 distinguishes potential harm, time sensitivity, and confidence using a small qualitative matrix. That is a sound starting point, but an analyst needs to know how to revisit all three dimensions when information changes. A record can have an earlier event timestamp yet arrive later. A new source may support a previously uncertain fact while leaving its cause unknown. Evidence can become harder to preserve even while there is no proof of an attacker. A service owner may verify a booking-state mismatch without establishing who caused it.

Priority should therefore be written as a checkpoint-specific recommendation, not as a permanent label attached to a ticket. A useful note tells the incident lead what is concerning now, what can be lost through delay, which important claims remain weak, who owns the next authorized check, and which observation would require reassessment.

A provisional priority is not the answer to "Did a cyberattack occur?" It is an answer to "Which bounded response work deserves attention next, given the evidence and operational risk available at this checkpoint?" The answer can remain time-sensitive without attributing malicious conduct, and it can be revised without concealing the earlier reasoning.

NIST SP 800-61 Revision 3 explains incident response as part of cybersecurity risk management and emphasizes organizational context. NIST CSF 2.0 provides flexible high-level outcomes for understanding, assessing, prioritizing and communicating cybersecurity risks. Neither establishes the specific categories, labels or decision thresholds in this exercise. TRI2 is an original OpenCyber Academy method for teaching bounded reassessment, not a NIST-defined incident classification or automatic containment policy.

2.2a.2 First freeze what the analyst actually knows

Before comparing possible harm or urgency, identify the decision checkpoint and released sources. Otherwise an apparently precise priority record may rely on information the earlier responder did not have.

At 09:05 the learner has R1–R8: R1 reports the desk-a sign-in, R3/R4 report B17/B18 edits, R5 records a patron concern, and R6 reports scheduled training. R7 is a backup-job status and R8 a network summary without destination detail. These records support investigating the booking changes and training explanation. They do not prove unauthorized account control, restore success, information transfer, or a broad population impact.

At 09:20 R9–R16 become available. R9 reports a B19 edit whose event time was 09:03, R10 lists B17/B18 in the supplied plan but not B19, R11 records a second patron report, R12 provides a staff recollection, R13 a limited identity summary, R14 an application-audit quiet-query summary, R15 a 24-hour deletion notice without a known anchor, and R16 a service-owner request for impact assessment before account change.

The correct interpretation is not that the Round A analyst ignored R9. The learner did not receive it until Round B. In the review ledger, preserve reported event time, learner availability time, and decision time as different fields. A reviewer should be able to reconstruct the 09:05 decision from only the then-released records.

The TRI2 code checks this boundary. A deliberate attempt to cite R9 during Round A is rejected before any interpretation or priority discussion occurs. That output represents a classroom release rule; it is not a statement that the underlying event did not occur.

2.2a.3 Confidence is not one number

A single "confidence: medium" label mixes several logically independent questions. A beginner can reason more accurately by writing three separate fields:

1. Confidence in the record as supplied: Is the named item present in the released classroom packet, with a source and stated content? In a live case this would additionally require relevant source authentication and collection/provenance review.
2. Confidence in interpretation: Does the record support the asserted business or security meaning? A booking edit may be recorded accurately while its authorization remains disputed.
3. Confidence in cause and attribution: Does available evidence connect the operation to a specific causal mechanism or person? A staff account label or nearby sign-in time is not human attribution.

These fields can move differently. At 09:20 the record of the B19 edit is now available; the interpretation that it was unauthorized remains unsettled because a training-plan omission is not proof that no other approved instruction existed; and the identity of the operator is not established by R13's limited summary.

A useful report states these as separate sentences:

"R9 is a supplied synthetic booking-audit record describing a B19 change. The approved scope of that operation remains unresolved because the supplied plan lists B17/B18 but not B19. The human controlling the session is not established."

This is more useful than labeling the entire case "high confidence" without saying confidence in what. It also prevents another error: downgrading every field just because attribution is weak. A patron-facing booking problem can require action even when the cause is unknown.

TRI2 uses descriptive statuses rather than calibrated probabilities. The code cannot authenticate any real source or measure an actual probability of compromise, and its labels must not be interpreted as a universal confidence scale.

2.2a.4 A record can be reliable while the hypothesis remains weak

An analyst sometimes treats independent evidence as a vote: three records agree, therefore the cause is established. But agreement depends on what proposition the sources actually address. R9 describes an application edit; R10 is a training-plan document; R12 is a staff recollection. These do not measure the same fact. Their differing contents can legitimately strengthen the need for an authorization check without proving account theft.

Consider three statements:

• "The supplied booking-audit row reports a B19 edit."
• "The supplied training plan omits B19."
• "An unauthorized person used the staff account."

The first two follow from the records' stated contents. The third is a causal attribution and does not follow automatically. An incomplete training plan or forgotten approved task remains a possible explanation; neither alternative is itself confirmed.

Conflicting signals should increase attention to the discriminator, not force the team to choose one story immediately. The training owner might provide a dated, approved addendum; a source custodian might supply reliable session-to-request mapping; the service owner might confirm a current booking mismatch. Each has a different purpose.

A full, owner-confirmed task list that includes a particular booking could reduce concern that that booking's task was outside the plan. It still does not prove the human operator, establish every booking state, or resolve evidence-retention risk. A separate valid observation is required for each stronger claim.

2.2a.5 Potential harm and verified impact are different dimensions

A patron report is evidence of a reported problem, not automatic proof of an incorrect authoritative reservation value. At 09:05, R5 records a concern about B18. At 09:20, R11 adds a B19 concern, but neither record provides an owner-approved comparison of current versus expected booking values.

A potential-harm note asks which business function could be affected if the concern is accurate: patron scheduling, room availability, front-desk integrity or continuity of reservations. It may require quick attention when the full impact is unknown.

A verified-impact note requires a different type of source: an authorized current-state observation compared with an accepted target, with scope and provenance adequate for the question. Its conclusion is still limited to the objects actually checked. It does not magically establish how many people were affected.

The IM2 laboratory already teaches that report counts, event counts, booking IDs and people are distinct units, and that a biased subset cannot estimate the whole population. TRI2 does not recalculate those counts. It teaches what happens to a priority recommendation when a bounded impact check is actually supplied or remains missing.

For example, a future independent synthetic variant in which an owner-approved comparison confirms a mismatch can justify revisiting potential business harm. That observation cannot be inserted into canonical R1–R16, which contains no completed authoritative state comparison.

At both checkpoints, the correct discipline is to state: potential consequences are being assessed; measured impact remains unknown unless an appropriate source has actually verified it.

2.2a.6 Split time sensitivity into preservation and containment concerns

The original matrix places multiple urgent issues in one time-sensitivity column. For decision making, it helps to track two independent urgency questions.

Preservation urgency concerns whether a decision-relevant source may become unavailable if the team waits. It depends on source retention, availability, owner response, collection authority and any verified preservation control. The clock can matter even if the initial interpretation is wrong.

Containment urgency concerns whether additional harmful activity is sufficiently plausible or observed to justify prompt consideration of protective options. It depends on signs of continued activity, current impact, confidence in control scope and possible damage from the intervention itself. A short log-retention period does not, by itself, prove a new harmful edit or authorize account restriction.

At 09:20, R15 supplies a reported policy for detailed booking-audit records: a 24-hour duration with an authorized-copy provision. It does not demonstrate the policy's enforcement, its starting anchor, the oldest retrievable relevant row, or an actual deletion. The time-sensitive task is to ask the incident lead and application custodian about a bounded preservation route and current source availability. Do not add 24 hours to R9's event time or treat the 09:14 notice time as a new retention start. A retained copy, if later authorized and actually acquired, would have its own custody and retention record; its existence would not by itself show that deletion at the producing source stopped. Preservation concern is therefore justified without a confirmed loss outcome or a conclusion that an attack occurred.

At that same checkpoint, R9 and R11 merit investigation and continued review, but there is no post-09:20 newly verified edit in the released record. R14's quiet result is limited to an unspecified query range, and cannot establish that no additional activity occurred. The incident lead therefore needs a review trigger and a plan for authorized escalation without describing a containment operation as already needed or performed.

A team may honestly say that evidence-preservation contact is time-sensitive while its cause attribution remains low or unproven. Those statements do not conflict.

2.2a.7 A quiet query is not a negative observation until its scope is understood

A common reassessment error is:

"The dashboard shows no new alerts, so lower the priority."

That may be reasonable only after the observer establishes what the query measured. For R14, the supplied card says no further booking edits appear after R9 within the queried range. It does not provide all the source, account, time, ingestion and completeness details needed for a universal absence claim.

A query might use an interval that excludes the time of interest, an account filter that excludes another path, a source that does not include the relevant operation, or a log store that has not finished ingesting records. The absence of a returned row is therefore narrower than "no new edit occurred."

VQ2 already teaches query-envelope conditions, and T2 demonstrates delayed arrival. The present lesson does not duplicate those mechanics. It asks what a response lead should do with an imperfect negative observation: leave the containment concern open for review and request the missing query manifest or better-bounded observation through the authorized custodian.

A valid negative result can narrow the concern for a specified tested path and interval. Even then, it cannot prove the absence of malicious behavior on every route, and it does not establish human attribution or solve a preservation problem. The reduction must be scoped to the proposition that the negative test could actually refute.

TRI2 emits QUIET_NOT_NEGATIVE_PROOF when a case relies on an apparently quiet summary whose coverage is not established. That warning does not claim that a new edit occurred; it prevents the unsupported opposite conclusion.

2.2a.8 How to write an evidence-changing review checkpoint

A useful priority note is not merely a timestamp followed by a color. It should answer these seven questions:

For Round A, a classroom answer may favor prompt review with the training owner and a 09:15 checkpoint, without concluding compromise. This is justified by R1–R8's booking changes, user report and scheduled training. It is not a claim that the organization adopted a numbered severity category.

For Round B, the incident lead can keep a prompt, bounded review at 09:35 or earlier on a verified new unexplained edit or material source-availability concern. The newly released B19 edit increases the need for explanation; R15 separately raises preservation urgency. The next proposed step may involve asking the application custodian for the retention anchor and feasibility of P-A, plus a service-owner-approved impact check.

The note should distinguish "will request" from "requested," "approved," "collected" and "verified." None of those latter states is supplied for a real Round B collection or hold. An attractive priority label cannot substitute for authorization.

2.2a.9 Example one — correct 09:05 assessment without hindsight

Correct record, canonical Round A only:

"At 09:05 UTC, Harbor Library's supplied R1–R8 records report a desk-a sign-in, booking edits to B17/B18 and a patron concern about B18. R6 records scheduled training but does not show that those particular edits were approved. The potential service consequence warrants prompt review; there is no verified broad impact, human attribution or demonstrated ongoing attack. The incident lead proposes asking the training owner for the approved task list and preserving the current synthetic records within the classroom scope, with a review at 09:15 or sooner if a separately verified new unexplained edit is supplied."

This note has a specific checkpoint, source set, service concern, interpretation limit, proposed authorized next question, owner and review. Its confidence in the case records being supplied is not the same as confidence that the changes were unauthorized. R7's completed backup job and R8's limited network summary do not settle the cause.

A reviewer must not say that the 09:05 lead already knew B19 was changed at 09:03. R9 is released only at 09:20, and its event timestamp cannot backdate its availability. A retrospective discussion can identify that later source as new information but must preserve the earlier decision's actual basis.

Neither the original note nor the comparison claims a real identity operation, account restriction, source copy or production log review. The phrase prompt review is a locally reasoned fictional priority description, not a NIST-prescribed severity grade.

2.2a.10 Example two — incorrect 09:20 downgrade

Incorrect synthetic Round B handoff:

"R14 shows no edits after B19, so the issue is over. R12 cannot remember B19, which proves a thief used desk-a; nevertheless the case can be marked low because no further alarms were seen. R15's 24 hours means we have until exactly 09:03 tomorrow to export the evidence, and R11 proves another patron's booking was corrupted."

This text simultaneously overstates a negative query, fabricates a human attribution, invents a retention anchor and equates a patron report with an authoritative business-state mismatch. It cannot support a defensible downgrade. The contradiction between "proved theft" and "case over" also shows why a single severity label is not useful without specific evidence claims.

Corrected bounded Round B assessment:

"At 09:20 UTC, R9 adds a B19 booking edit whose event time was 09:03; R10's supplied training plan names B17/B18 but not B19, while R12 is an unverified recollection about the action. The account operator, approval and root cause remain unresolved. R11 reports a patron concern but does not measure current booking correctness or population impact. R14 is a quiet summary with incomplete query coverage, and R15 reports a 24-hour source policy with no confirmed anchor. The incident lead keeps a prompt, scoped review, seeks an authorized application-custodian retention and query-scope clarification plus a service-owner impact comparison, and will reassess at 09:35 or earlier on a verified new edit or a substantiated source-loss risk."

The correction preserves each level of confidence separately. It treats the preservation question as urgent without claiming malicious cause and avoids selecting any production containment control. The report does not assert that a real source hold was applied. Its review time is a classroom decision checkpoint, not an operational requirement imposed by NIST.

A good learner can explain why the priority is provisional without saying "we have no confidence in anything." The source cards are available, the authorization hypothesis is contested and the actor is unknown; those are different propositions.

2.2a.11 Reassess sequentially when a new card arrives

A review must start with the previous frozen decision, not a blank slate. A useful sequence is:

1. Freeze the prior note. Identify what the analyst could defend at the earlier checkpoint and which observations were missing.
2. Declare the new release. Add only the cards actually supplied at the new checkpoint; preserve their event and availability times.
3. List the changed claims. Did the new card add a source record, contradict an interpretation, verify a business mismatch, or merely describe another report?
4. Check the three confidence fields separately. A new record may raise confidence in its content being supplied without establishing the meaning or actor.
5. Re-evaluate potential versus verified harm. Name the legitimate business unit affected or still unmeasured.
6. Re-evaluate preservation and containment urgency independently. Record the relevant custodian and authorized test for each.
7. Write the next provisional note. Keep a decision owner, next review time/trigger, proposed authorized request and unresolved limitations.
8. Version rather than overwrite. Save the 09:05 note and the 09:20 revision independently, with a short statement of what changed.

The change from Round A to Round B is not automatically an escalation in every dimension. It is a richer evidence set. R9 adds a specific booking-edit question and R15 introduces an evidence-availability concern that was not released earlier; the human actor remains unknown. A measured service mismatch still requires an approved comparison not present in R1–R16.

This process allows the team to be responsive without treating every new card as equal in significance. A retention notice may change how quickly the team contacts a custodian, while an owner-approved task addendum may change the interpretation of one booking. Neither must move every dimension in the same direction.

2.2a.12 Reassess on conflicting signals without forcing a verdict

Incident sources may pull the interpretation in different directions. R9 reports B19 edited, R10 omits B19 from the supplied plan and R12 records that the staff member does not remember B19. These facts create uncertainty about authorization. They do not independently prove account takeover, identity theft or deliberate action.

A beginner should avoid treating conflicting evidence as a mathematical vote. One high-quality source may be more directly relevant to a specific question than several weak contextual reports, but assessing quality requires scope, producer semantics, completeness, possible bias and timing. A staff recollection is context; a complete, dated approved plan would answer the task-scope question more directly, if it actually exists and is verified.

When sources conflict, write:

• The exact proposition in dispute.
• What each source supports and does not support.
• What observation would discriminate between competing explanations.
• Who can authorize or produce that observation.
• What decision remains safe while waiting.
• What future result would strengthen, weaken or leave the hypothesis unchanged.

The proper output is often a specific unresolved hypothesis, not "medium confidence" in a generalized attack story. This is a valuable result because it makes the next verification work reproducible for another analyst.

The TRI2 CONFLICTING_SIGNALS variant models an incomplete approved-task addendum: the analyst cannot downgrade solely because a document is present if its scope or completeness is not verified.

2.2a.13 Reassess on increased preservation risk without claiming a breach

At 09:20, R15 reports a 24-hour policy for detailed booking-audit records, subject to an authorized copy. The record does not identify the event/ingestion/storage anchor, the exact deletion job, the oldest still-accessible relevant row, or a confirmed effective hold. That uncertainty is itself operationally meaningful.

The response team can request rapid custodian clarification and appropriate preservation authorization before proving an attack. Such a request protects the ability to test competing explanations later; it does not assert that the leading malicious explanation is true. Equally, the notice does not justify collecting unrelated patron information or using an unapproved account to change retention settings.

If the custodian is unavailable, the note should record the failed contact, the accountable incident lead, a designated approved escalation route and the remaining uncertainty. Do not turn the absence of a response into proof that data were deleted. Do not assume that filing a request applied a hold.

The existing HOLD2 chapter addition teaches how to distinguish source hold requests, approval, application and verified effect. TRI2 instead asks how that uncertainty affects the provisional urgency and next review, without replaying HOLD2's test or inventing a successful hold.

A useful phrase is: "Evidence-availability concern is time-sensitive; cause confidence remains unproven; exact deletion deadline unknown." Those three facts can all be true at the same checkpoint.

2.2a.14 A new verified edit is a conditional review trigger, not a command

An incident lead may specify that a future, source-verified unexplained booking edit should cause an immediate reevaluation of containment options. This does not mean such an edit has occurred after the 09:20 Round B review. It is a conditional threshold attached to the provisional decision.

A trigger must say what counts as verified for the specific purpose. At minimum, a relevant custodian would need to check the source, timestamp semantics, selected booking/object, possible approved task and source coverage. The team would then bring the result to the incident lead and service owner for a decision.

The trigger does not authorize an automatic account disable, pause or data collection outside scope. Choosing a containment action requires its own risk and authorization assessment, and the later Module 3 comparison is outside the two checkpoints here.

TRI2 includes a fictional NEW_EDIT_VERIFIED input as an independent scenario. The code marks it variant-only; an attempt to insert the same flag into a canonical snapshot is explicitly rejected. This guards against a common learning error: performing an interesting counterfactual and then treating its event as if it had appeared in the R-series evidence.

The proper human question after a verified new edit is which intervention, if any, would now be proportionate, given potential harm and business costs. The toy classifier deliberately does not make that selection.

2.2a.15 A justified downgrade must specify which concern decreased

"Priority lowered" is not a complete assessment. Which aspect became less concerning, what new evidence justified that change, and what remained unresolved?

Suppose a separately labeled future synthetic variant supplies an owner-approved, complete training addendum explicitly authorizing the B19 task and a properly bounded, complete quiet observation for a specified subsequent interval. Those inputs could reduce concern that B19 was outside the approved training scope, while still leaving the human operator unproven. They cannot establish that every booking is correct or that no other activity occurred outside the tested interval.

The preservation question also remains separate. If detailed records still face an unknown retention anchor and no effective source safeguard has been independently substantiated, the team should not abandon preservation simply because the B19 authorization hypothesis became less concerning.

Another variant might include a separately verified and approved preservation safeguard, reducing source-loss concern within its tested source scope. Even then the team should not call the entire incident resolved. The conclusion is a limited change in one concern, not a global proof of safety.

TRI2 provides two contrasting downgrade cases: one with a declared synthetic source safeguard, and one with the same task-scope evidence but source preservation still unconfirmed. Both may show reduced B19 authorization concern; only the first prints a fixture-only protected-source status. Neither automatically assigns a lower NIST severity, executes containment or closes the case.

A downgrade based solely on R14's quiet summary with unknown filters is unjustified. A contradiction in a source should be resolved by obtaining stronger evidence, not by choosing whichever report supports the desired lower priority.

2.2a.16 What the model can and cannot classify

The TRI2 script deliberately prints descriptive evidence states, not a numeric severity, risk score, attack probability or action recommendation. Its six columns mean:

The flags field lists important reasoning barriers such as a quiet query without known coverage, an unsupported attribution claim or a requested downgrade not justified by the supplied conditions.

None of these values authorizes a control. A result such as K:NEW_EDIT_REVIEW asks for human reevaluation; it is not a request to disable an account. A result such as P:SOURCE_PROTECTED_IN_VARIANT means the invented Boolean input claimed a safeguard, not that the code independently verified a source hold.

The code first checks the evidence release boundary. If a Round A packet references R9, the entire assessment stops with BLOCK_UNRELEASED_SOURCE. It also rejects invented canonical events or impact, a claimed negative result without known query coverage, and a case-wide downgrade while a new edit remains open. Even in a labeled variant, a complete approved addendum must explicitly name B19 before the B19 task-scope concern can narrow. These are input-consistency checks over declared premises, not independent verification of those premises.

The source and event confidence categories do not attempt to measure real probabilities. A real organization would need its own criteria, evidence quality controls, authorized response plan and responsible decision makers. For the rapid course, the aim is to make unsupported claims and reassessment points visible.

2.2a.17 Versioned priority notes prevent hindsight revision

When the team receives new information, preserve the old decision rather than silently replacing it. A minimal revision log might contain:

These descriptions do not claim that no loss risk existed before R15 was released; they say the learner had not yet received that notice. The distinction matters when reviewing whether an earlier decision was reasonable from the information then available.

A revision should identify which evidence caused the change. "Updated priority after new information" is vague. "Added R9/R10/R15 to the permitted set at 09:20; separated unresolved B19 authorization from preservation contact concerning R15" is testable.

A reviewer should also ask whether the new priority note still includes the original bounded approval constraints. A source becoming more urgent does not dissolve the need for permission, and a new suspicion does not identify an attacker.

2.2a.18 Section synthesis: urgency and certainty can move independently

The Module 2 triage skill is not selecting the most alarming label. It is writing a provisional decision note that distinguishes what the records say, what those events mean, who or what caused them, what harm could follow, what harm has been verified, which evidence may disappear, and whether continuing activity requires urgent owner review.

At 09:05, R1–R8 permit a prompt assessment, training-owner question and bounded review. At 09:20, R9–R16 add a B19 authorization question, a second patron report, an imperfect quiet-query summary and a short-retention notice with no confirmed anchor. Preservation concern can rise while cause attribution remains unknown.

A valid reclassification is limited to the evidence that supports it. A wrong-source negative query cannot lower concern about unseen activity. An approved task addendum may narrow the B19 explanation without proving the human actor. A custodian who cannot be reached increases uncertainty about evidence availability but does not prove evidence loss. A verified new edit would demand fresh human attention but would not automatically select a control.

The following offline lab uses these principles as structural review labels. It does not classify a real incident, make an operational decision, or extend any canonical R-series record.

2.2b TRI2 offline laboratory — reassessment under incomplete evidence

Classification: Independent teaching-only fixture. The labels TRI2 and its Boolean variant fields are not original Harbor Library records, measured operational outcomes, or accepted source-hold receipts.

Goal: Show why different dimensions change independently when evidence becomes available; identify unsupported negative-query, attribution, harm and downgrade claims; preserve the Round A/Round B release boundary; and show which human review question remains open.

Environment: Python 3 standard library, entirely in memory; no files, network access, accounts, collection, retention-control changes, notifications or operational actions.

Important model contract: The R:SUPPLIED_NOT_AUTHENTICATED output means a synthetic case card is present for the learner. It does not mean a producer's log has been independently authenticated. H:VERIFIED_BOUNDED and P:SOURCE_PROTECTED_IN_VARIANT are assertions made inside invented variant inputs; the program does not actually conduct an impact comparison or source-hold test. C:ACTOR_UNPROVEN always remains true because no simulated human attribution is established.

Input and predictive exercise

Before executing, predict why R9 is unavailable at 09:05, why R14's quiet summary cannot prove no more edits, why an R15 loss concern cannot become a deletion deadline, and why a valid addendum might justify a narrow B19 explanation reassessment without ending preservation work. Then execute the exact program.

Full Python 3 code

from copy import deepcopy

RELEASE = {
    "A": {f"R{i}" for i in range(1, 9)},
    "B": {f"R{i}" for i in range(1, 17)},
}

BASE = dict(
    stage="B",
    refs=("R9", "R10", "R11", "R12", "R13", "R14", "R15", "R16"),
    record_provided=True,
    owner_state_check=False,
    patron_report=True,
    quiet_summary=True,
    query_coverage_known=False,
    retention_notice=True,
    retention_anchor_known=False,
    source_safeguard_confirmed=False,
    custodian_available=True,
    verified_fresh_edit=False,
    approved_addendum=False,
    training_scope_verified_complete=False,
    addendum_names_b19=False,
    no_new_edits_verified=False,
    claim_human_actor=False,
    request_downgrade=False,
    variant=False,
)

def validate_tri2_input(s):
    """Validate this classroom packet, not a real evidence source."""
    if not isinstance(s, dict) or set(s) != set(BASE):
        return "BLOCK_INPUT_SCHEMA"
    if not isinstance(s["stage"], str) or s["stage"] not in RELEASE:
        return "BLOCK_UNKNOWN_STAGE"
    refs = s["refs"]
    if not isinstance(refs, (tuple, list)):
        return "BLOCK_SOURCE_LIST_TYPE"
    if not refs:
        return "BLOCK_EMPTY_SOURCE_SET"
    if any(not isinstance(ref, str) for ref in refs):
        return "BLOCK_SOURCE_ID_TYPE"
    if len(set(refs)) != len(refs):
        return "BLOCK_DUPLICATE_SOURCE_ID"
    for field in BASE:
        if field not in ("stage", "refs") and type(s[field]) is not bool:
            return "BLOCK_NON_BOOLEAN:" + field
    return None

def review(s):
    problem = validate_tri2_input(s)
    if problem is not None:
        return problem
    if not set(s["refs"]).issubset(RELEASE[s["stage"]]):
        return "BLOCK_UNRELEASED_SOURCE"
    # Declared flags must be supported by cards in this release set.
    released_refs = set(s["refs"])
    if s["retention_notice"] and "R15" not in released_refs:
        return "BLOCK_UNRELEASED_CLAIM:R15"
    if s["quiet_summary"] and "R14" not in released_refs:
        return "BLOCK_UNRELEASED_CLAIM:R14"
    if s["patron_report"] and not ({"R5", "R11"} & released_refs):
        return "BLOCK_UNRELEASED_CLAIM:PATRON_REPORT"
    if (
        s["approved_addendum"] or s["training_scope_verified_complete"]
        or s["addendum_names_b19"]
    ) and not {"R9", "R10"}.issubset(released_refs):
        return "BLOCK_UNRELEASED_CLAIM:R9_R10"
    if s["verified_fresh_edit"] and not s["variant"]:
        return "BLOCK_INVENTED_CANONICAL_EVENT"
    if not s["variant"] and any((
        s["owner_state_check"], s["source_safeguard_confirmed"],
        s["approved_addendum"], s["no_new_edits_verified"],
        s["query_coverage_known"], s["retention_anchor_known"],
        s["training_scope_verified_complete"], s["addendum_names_b19"],
        not s["custodian_available"],
    )):
        return "BLOCK_INVENTED_CANONICAL_PREMISE"
    if s["no_new_edits_verified"] and not s["query_coverage_known"]:
        return "BLOCK_UNBOUNDED_NEGATIVE_PREMISE"
    if s["verified_fresh_edit"] and s["no_new_edits_verified"]:
        return "BLOCK_CONFLICTING_ACTIVITY_PREMISES"
    if s["verified_fresh_edit"] and s["request_downgrade"]:
        return "BLOCK_GLOBAL_DOWNGRADE_NEW_EDIT_OPEN"

    record = (
        "R:SUPPLIED_NOT_AUTHENTICATED"
        if s["record_provided"] else "R:UNVERIFIED"
    )
    interpretation = (
        "I:TRAINING_SCOPE_SUPPORTED"
        if s["approved_addendum"]
        and s["training_scope_verified_complete"]
        and s["addendum_names_b19"]
        else "I:CONTESTED_OR_INCOMPLETE"
    )
    cause = "C:ACTOR_UNPROVEN"

    harm = (
        "H:VERIFIED_BOUNDED"
        if s["owner_state_check"]
        else "H:REPORT_ONLY" if s["patron_report"]
        else "H:NOT_MEASURED"
    )
    preserve = (
        "P:SOURCE_CONTACT_BLOCKED"
        if s["retention_notice"]
        and not s["custodian_available"]
        else "P:SOURCE_PROTECTED_IN_VARIANT"
        if s["source_safeguard_confirmed"]
        else "P:ANCHOR_UNKNOWN_CONTACT"
        if s["retention_notice"]
        and not s["retention_anchor_known"]
        else "P:RETENTION_NEEDS_CHECK"
        if s["retention_notice"]
        else "P:NO_RELEASED_LOSS_RULE"
    )
    contained = (
        "K:NEW_EDIT_REVIEW"
        if s["verified_fresh_edit"]
        else "K:B19_CONCERN_REDUCED"
        if s["approved_addendum"]
        and s["training_scope_verified_complete"]
        and s["addendum_names_b19"]
        and s["no_new_edits_verified"]
        else "K:OPEN_HYPOTHESES"
    )

    flags = []
    if s["quiet_summary"] and not s["query_coverage_known"]:
        flags.append("QUIET_NOT_NEGATIVE_PROOF")
    if s["claim_human_actor"]:
        flags.append("ATTRIBUTION_CLAIM_UNSUPPORTED")
    if s["request_downgrade"]:
        if (
            s["approved_addendum"]
            and s["training_scope_verified_complete"]
            and s["addendum_names_b19"]
            and s["no_new_edits_verified"]
        ):
            flags.append("DOWNGRADE_ONLY_B19_TASK_SCOPE_CONCERN")
        else:
            flags.append("DOWNGRADE_NOT_JUSTIFIED")
    if s["retention_notice"] and not s["custodian_available"]:
        flags.append("ESCALATE_CONTACT_NO_HOLD_ASSUMED")
    if s["verified_fresh_edit"]:
        flags.append("REVIEW_ON_NEW_VERIFIED_SIGNAL")

    return " ".join([
        record, interpretation, cause, harm, preserve,
        contained,
        "flags=" + (",".join(flags) if flags else "NONE"),
    ])

def case(**changes):
    s = deepcopy(BASE)
    s.update(changes)
    return review(s)

ROUND_A = deepcopy(BASE)
ROUND_A.update(
    stage="A",
    refs=("R1", "R3", "R4", "R5", "R6"),
    retention_notice=False,
    quiet_summary=False,
)

CASES = [
    ("ROUND_A_0905", ROUND_A),
    ("ROUND_B_0920", BASE),
    ("UNRELEASED_R9_AT_A",
     {**ROUND_A, "refs": ("R1", "R9")}),
    ("QUERY_FILTER_UNKNOWN", {"variant": True}),
    ("RETENTION_ANCHOR_UNKNOWN",
     {"variant": True, "quiet_summary": False}),
    ("PATRON_REPORT_UNVERIFIED",
     {"variant": True, "quiet_summary": False,
      "retention_notice": False}),
    ("CLAIM_FALSE_ATTRIBUTION",
     {"variant": True, "claim_human_actor": True}),
    ("CUSTODIAN_UNAVAILABLE",
     {"variant": True, "custodian_available": False}),
    ("NEW_EDIT_VERIFIED",
     {"variant": True, "verified_fresh_edit": True}),
    ("NEW_EDIT_NOT_CANONICAL",
     {"verified_fresh_edit": True}),
    ("CONFLICTING_SIGNALS",
     {"variant": True, "approved_addendum": True,
      "training_scope_verified_complete": False}),
    ("PREMATURE_DOWNGRADE",
     {"variant": True, "request_downgrade": True}),
    ("ADDENDUM_OMITS_B19",
     {"variant": True, "request_downgrade": True,
      "approved_addendum": True,
      "training_scope_verified_complete": True,
      "no_new_edits_verified": True,
      "query_coverage_known": True}),
    ("UNBOUNDED_NEGATIVE_PREMISE",
     {"variant": True, "no_new_edits_verified": True}),
    ("INVENTED_CANONICAL_IMPACT",
     {"owner_state_check": True}),
    ("NEW_EDIT_AND_GLOBAL_DOWNGRADE",
     {"variant": True, "verified_fresh_edit": True,
      "request_downgrade": True}),
    ("VALID_B19_TASK_SCOPE_DOWNGRADE",
     {"variant": True, "request_downgrade": True,
      "approved_addendum": True,
      "training_scope_verified_complete": True,
      "addendum_names_b19": True,
      "no_new_edits_verified": True,
      "query_coverage_known": True,
      "source_safeguard_confirmed": True}),
    ("DOWNGRADE_WITH_PRESERVATION_OPEN",
     {"variant": True, "request_downgrade": True,
      "approved_addendum": True,
      "training_scope_verified_complete": True,
      "addendum_names_b19": True,
      "no_new_edits_verified": True,
      "query_coverage_known": True,
      "source_safeguard_confirmed": False}),
    ("OWNER_VERIFIED_IMPACT",
     {"variant": True, "owner_state_check": True}),
    ("SOURCE_SAFEGUARDED_IN_VARIANT",
     {"variant": True,
      "source_safeguard_confirmed": True}),
]

for label, values in CASES:
    result = review(values) if "stage" in values else case(**values)
    print(label + " " + result)

assert review(ROUND_A).startswith("R:SUPPLIED")
assert case(verified_fresh_edit=True) == (
    "BLOCK_INVENTED_CANONICAL_EVENT"
)

controls = [
    ("EMPTY_SOURCE_SET", {**ROUND_A, "refs": (), "patron_report": False}),
    ("TEXT_FALSE", {**BASE, "variant": "False", "owner_state_check": True}),
    ("CANONICAL_ANCHOR", {**BASE, "retention_anchor_known": True}),
    ("CANONICAL_COVERAGE", {**BASE, "query_coverage_known": True}),
    ("CANONICAL_CONTACT", {**BASE, "custodian_available": False}),
]
for label, sample in controls:
    print(label + " " + review(sample))

For the executed output, scenario interpretation and negative controls, read the TRI2 worked result in the final answer appendix. Predict the labels before opening the result.

Same-scope claims: a quiet summary is not verified absence

A contradiction in this exercise means asserting both that at least one qualifying event exists and that no qualifying event exists in the same bounded set. Two reports that look different are not necessarily contradictory. Before supplying verified_fresh_edit=True or no_new_edits_verified=True, freeze the object set, account and event predicate, source-coverage universe, time basis and half-open observation interval in a scope note. Within one TRI2 input, both flags refer to that same scope. A false flag means its positive assertion is not supplied; it does not prove the opposite. The program receives no scope note, manifest or timestamps and cannot verify them.

Worked synthetic example, separate from R1–R16. On one fictional day in UTC, consider edits to invented booking X31 under account Q7 during [10:00, 10:10). A declared verified finding places a matching edit at 10:04. A second declared finding claims complete coverage and no matching edits in that same interval. The 10:04 event is a counterexample to the absence claim. Both positive assertions cannot describe the same set consistently. The new guard returns BLOCK_CONFLICTING_ACTIVITY_PREMISES, preserving the disagreement for investigation rather than producing a combined assessment.

Now change only the absence claim's interval to [10:05, 10:10). The 10:04 event falls outside that later interval, so the claims need not conflict. Keep two scoped notes instead of forcing their flags into one TRI2 input. A half-open interval includes its starting instant and excludes its ending instant. An absence finding for a later interval does not erase the earlier event, identify an operator or close an incident.

The original fresh-edit branch already kept K:NEW_EDIT_REVIEW when a fresh edit was asserted. That conservative output did not make an accompanying same-scope absence assertion consistent. The added check rejects the inconsistent combination before a multidimensional result is printed. It does not change what supports I:TRAINING_SCOPE_SUPPORTED: that separate authorization label still requires the three applicable addendum premises. An earlier guard rejects an absence assertion without declared query coverage as BLOCK_UNBOUNDED_NEGATIVE_PREMISE; when both defects occur, that earlier block is reported first. These labels identify a classroom input problem, not a command to stop a service, delete evidence or choose which source is truthful.

quiet_summary=True is different again: it says a summary was supplied, not that a completed, adequately scoped absence check was verified. It can coexist with a fresh-edit assertion without becoming this contradiction. The original R14 summary remains incomplete evidence; the new check neither authenticates it nor expands its coverage.

Independent practice. Predict all four results below, then write two sentences explaining why the first X31 pair conflicts but the later-window pair need not. Run the complete TRI2 program first, followed by this separate continuation in the same fresh Python session. It uses only copied in-memory synthetic inputs and prints every assessment field, not merely the activity label.

# Run after the complete TRI2 listing in the same fresh Python session.
# These flags refer to one declared object/predicate/coverage/time scope.
same_scope = {
    **BASE, "variant": True, "verified_fresh_edit": True,
    "no_new_edits_verified": True, "query_coverage_known": True,
}
fresh_only = {**same_scope, "no_new_edits_verified": False}
absence_only = {**same_scope, "verified_fresh_edit": False}
quiet_with_fresh = {**BASE, "variant": True, "verified_fresh_edit": True}

for label, sample in (
    ("SAME_SCOPE_CONFLICT", same_scope),
    ("FRESH_ONLY", fresh_only),
    ("ABSENCE_WITHOUT_ADDENDUM", absence_only),
    ("QUIET_SUMMARY_WITH_FRESH", quiet_with_fresh),
):
    print(label + " " + review(sample))

Compare your predictions and interval explanation with the worked scope answer in the final appendix. The complete program still prints its original 25 lines; this continuation prints four additional lines. Retain the three release challenges below. This practice uses the existing supplementary lab rubric's evidence-boundary criterion; it changes neither EX014's two-row table, EX016's short note, EX024's two hypothetical pairs nor the 50-exercise denominator.

Release-guard challenge: After the baseline program, test three explicitly synthetic Round A variants: set retention_notice=True without R15, set quiet_summary=True without R14, and set variant=True, approved_addendum=True, training_scope_verified_complete=True, addendum_names_b19=True, no_new_edits_verified=True and query_coverage_known=True without R9/R10. The three results, respectively, must be BLOCK_UNRELEASED_CLAIM:R15, BLOCK_UNRELEASED_CLAIM:R14 and BLOCK_UNRELEASED_CLAIM:R9_R10. No case becomes a new canonical R-series record. The 20 baseline conclusions remain unchanged; the two former CAUSE tokens are now labeled TASK_SCOPE in the code and transcript. The guard checks the classroom release boundary; it does not authenticate a source or verify a real approval.

The original three release-guard controls remain required. The five additional controls in the complete program test a different boundary: the input schema and the distinction between fixed canonical metadata and separately labeled variants. An empty reference list cannot claim that records were supplied. The text "False" is not a Boolean false value; accepting it as a variant marker would admit invented impact into what a reader might mistake for the canonical packet. R15 does not supply an anchor, R14 does not supply complete coverage, and R1–R16 do not report a failed custodian contact. Those altered premises must not silently enter the canonical case.

custodian_available=True in the original baseline remains a model default, not a verified successful contact. The default produces no collection or hold receipt. Requiring a separately labeled variant for a failed-contact scenario does not authenticate the default; both real contact status and any real preservation result remain unmeasured.

A declared variant can still contain an invented owner_state_check=True or source-safeguard flag. These guards do not verify those assertions. They validate classroom structure and provenance boundaries, not source truth, actual harm, probability, severity or permission. TRI2 remains an original OpenCyber Academy method rather than a NIST classification policy. The renamed TASK_SCOPE labels concern authorization of the task, not a demonstrated causal mechanism or human actor.

Limitations and diagnostic negative tests

The program does not read any case files, query logs, test retention policies, authenticate a source, assess human identity, or verify a business state. Values such as owner_state_check=True, no_new_edits_verified=True and source_safeguard_confirmed=True are invented premises for independent variants, not real evidence collected by the script. It cannot calculate probabilities, incident severity, actual retention deadlines or appropriate live containment.

The result labels are educational and may be rejected or refined by an organization's actual decision policy. The ordering of checks is simplified: first validate release, then flag invented canonical events, then describe dimensions and limitations. Real cases may have multiple independent uncertainties not represented here.

Further negative control: Set request_downgrade=True while leaving training_scope_verified_complete=False. The expected flag is DOWNGRADE_NOT_JUSTIFIED. Do not remove the quiet-query or source-retention caveats merely because a respondent asks for lower priority. Restore the baseline after the exercise.

Required learner output: Reproduce the 20 baseline lines and five input-guard lines from the complete program, then test the three release-guard challenges separately. Classify each scenario's most consequential limitation, explain why preservation and containment urgency can move independently, and write two versioned notes—09:05 and 09:20—with the correct release boundaries, owner, next authorized request and review trigger.

Lab assessment, five points: one point for exact output; one for three separate confidence layers; one for separating reported from verified impact; one for preservation versus containment review; and one for rejecting unsupported de-escalation, attribution and future-source use. This is supplementary assessment and creates no numbered exercise ID.

2.2c Two-role practical activity — frozen priority review and independent reassessment

Purpose: Determine whether a reviewer can explain why a provisional priority changed, stayed open or narrowed using the actually released source cards, without the writer's retrospective coaching or invented production evidence.

Roles: Round A/B Triage Analyst prepares and freezes the two source-bounded decision packets. Independent Review Lead evaluates the packet using the permitted R-series table and produces a separate, frozen reassessment. A facilitator may observe but must not supply missing evidence or reveal later cards prematurely.

Preparation and sealed packet

The analyst creates TRI2-A-v1 with checkpoint 09:05, R1–R8 evidence pointers, reported versus inferred statements, potential harm, separate confidence layers, owner, a proposed authorized training-owner check and 09:15 review condition. The analyst then freezes that packet unchanged.

Only then does the facilitator release R9–R16 for the 09:20 reassessment. The analyst prepares TRI2-B-v1, identifying which statements changed because R9/R10/R11/R12/R14/R15 became available. The packet does not contain R17–R24 or later branch results. It preserves R15's unknown deletion anchor and R14's incomplete query coverage.

The analyst may add a separately marked synthetic variant card illustrating an approved addendum or custodian unavailability, but must give it a distinct name and must not mix its result into the canonical Round B note.

Independent review

Without asking the analyst to explain what they intended, the review lead:

1. Reconstructs the evidence set legitimately available at each checkpoint.
2. Classifies each major claim by record content, interpretation, and cause/attribution.
3. Separates potential business harm from the consequences actually verified.
4. Identifies preservation-urgency evidence and unknown loss clock.
5. Identifies continuing-activity concern without treating R14 as a complete negative finding.
6. Names the permitted next request, its custodian/owner and the relevant approval boundary.
7. Identifies whether the 09:05 provisional note remained justified at the time and why 09:20 warrants a revised note.
8. States the next review time or precise future observation that would trigger earlier reconsideration.

The lead writes TRI2-review-v1 and freezes it before the two roles discuss disagreements. A reviewer who uses R9 to fault the 09:05 analyst for ignoring it fails the chronological requirement. A reviewer who describes the notice as proof that logs were deleted also fails the source-semantics requirement.

Adjudication and improvement

Compare the two frozen notes and receiver answer with the canonical sources. Record whether a problem came from a missing source pointer, an unsupported interpretation, an inappropriate priority change, an incomplete owner/request field or a violation of the release boundary.

If the packet requires correction, create TRI2-A-v2 or TRI2-B-v2 with a documented change. Do not overwrite the old note or pretend that the revised understanding existed earlier.

Bounded pass: Both checkpoints have correct release sets, all three confidence layers are distinguished, reported harm is not counted as verified impact, preservation urgency is separate from containment concern, and the next proposed request and review trigger are authorized and specific.

Critical fail: Attribution is asserted without supporting evidence; R14's quiet result is generalized beyond its unknown query bounds; an exact R15 deletion deadline is invented; a synthetic variant is imported into canonical R1–R16; an earlier decision is justified with later sources; or a production control is selected/executed without the proper fictional approval path.

Limits: This practice tests two learners' written reasoning under a synthetic tabletop, not the actual capacity of an organization to contact a custodian or contain a cyberattack. A correct priority note does not prove the next request was performed.

Worked checkpoint

At the 09:05 checkpoint, classify only released observations and state a provisional priority. At 09:20, reopen the assessment with newly released records. The later conclusion does not rewrite the earlier evidence boundary.

Practice — Lesson 06

EX014 — Triage question

Objective: turn a detector label into testable questions. Inputs: R9–R16 and the Module 1 service map. Output: a two-row table with question, relevant supplied record, authorized owner or source to ask next, and an answer that would change triage. Begin with the label “suspicious booking edit” and avoid using the label as evidence. A score of 2 requires two different discriminating questions and a bounded source for each.

TRI2 refinement: In each of the same two rows, distinguish (a) the supplied record statement, (b) the interpretation the authorized check could strengthen or weaken, and (c) the causal or human-actor claim still unproved afterward. A B19 task-scope check and a booking-state comparison answer different questions. Do not add a third row or report a proposed check as completed.

Worked answer: EX014 in the final appendix.

EX015 — Hypothesis table

Objective: keep competing explanations live. Inputs: H1–H3 from section 2.1 and R1–R16. Output: three rows, each with a supporting record, a contradiction or limit, a narrow next authorized check and what result would weaken that hypothesis. You may state that a record is weak support. A score of 2 requires at least one check that could genuinely discriminate between explanations rather than simply restating the same log.

Discriminator check: In each row, the named check must be capable of producing the stated weakening result. Identify the correct producer and field: R9 reports a booking-audit room change, whereas R11 reports a time-display concern. A task-approval document and identity-session detail answer different questions. This is a requirement within the existing three-row artifact and 0–2 rubric.

Worked answer: EX015 in the final appendix.

EX016 — Priority without false certainty

Objective: set urgency without inventing a severity fact. Inputs: R9–R16 at the 09:20 discovery point. Output: a short decision note with separate fields for potential patron harm, retention or ongoing-activity urgency, confidence in the leading hypothesis, provisional priority, decision owner and an observable review trigger. A score of 2 requires a reason for the priority and a deadline or event, not merely a color or number.

Extension: Require one sentence explaining why retention urgency can be high while evidence of account compromise remains inconclusive. Identify what would cause the priority to increase and what would justify a less urgent review. Do not turn an unknown deadline into a guessed timestamp.

For full credit: The learner identifies R15's possible evidence-loss path, R9/R11's potential booking harm, unresolved attribution, the incident lead's decision authority and the 09:35 review or an earlier verified trigger.

Additional IM2 discriminator for EX016: At Round B, distinguish the R15 concern about detailed booking-audit records relevant to R9 from the retention of R11's help-desk report or R13's identity source, whose policies are not supplied. Separately assess potential booking harm, uncertain cause and the absence of a measured affected-patron total. The independent IM2 fixture supplies no Harbor Library outcome. Keep the same short decision note and 0–2 rubric.

TRI2 refinement: Keep the note short. State separately that the synthetic records are supplied, B19 task authorization is unresolved, and cause or human attribution is unproved. Split time sensitivity into source-preservation contact and a conditional human review of containment; R14's quiet summary has incomplete coverage and R15 has no confirmed deletion anchor. Name the authorized P-A or impact-check request, the incident lead, and the 09:35 or earlier evidence-triggered review. This adds precision to the same artifact and 0–2 rubric, not another exercise.

Worked answer: EX016 in the final appendix.

Continue studying — lesson 06 of at least 20

← Lesson 05 · Course lesson index · Lesson 07 →

Continue to the next authored daily lesson.