Impact bounds, denominators and privacy

Week 2, day 5. 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.14 Define the thing you are trying to count

"How many were affected?" is not an answerable technical question until an analyst defines what an affected unit is.

A ticket is a report submitted to a service channel. A booking is an application business object. An edit event is a recorded operation. A patron is a person or account associated with service use. One person may open multiple tickets, one ticket may discuss several bookings, and one booking may have several audit records. These objects must not be treated as interchangeable.

In Harbor Library, R5 contains a patron report about B18; R11 is a second patron report about B19. R3, R4 and R9 describe booking changes. The supplied chapter does not include a complete current authoritative-state comparison or the population of all bookings. Therefore, at the 09:20 checkpoint, the learner can identify specific reported concerns and recorded changes, not an independently measured total of incorrect bookings or affected people.

Before any count, write the measurement question:

"Among the booking IDs included in an authorized, owner-defined comparison interval, how many have a current authoritative value that differs from the approved expected state?"

This is substantially narrower than:

"How many patrons were harmed by the incident?"

The second question requires additional relationships and harm criteria. A room assignment discrepancy could inconvenience a patron, but whether it caused actual harm, whether multiple patrons were associated with the same room, and whether the issue was corrected before use are all separate facts.

The general incident-response goal is to assess scope and consequences based on available evidence. NIST SP 800-61 Revision 3 places response analysis and decisions within cybersecurity risk management; the measurement contract below is original instructional material, not a prescribed NIST impact score.

2.15 Establish four levels of impact claim

It helps beginners to classify claims before attempting to calculate a total.

Lesson table; scroll horizontally to read all columns →

These classifications can apply to the same booking; they are not mutually exclusive replacement labels. A report and an audit event can support investigating one booking, while a later state comparison adds a distinct, stronger claim. The analyst should preserve the original evidence and note which new source justified the upgrade.

A state discrepancy must also have a defensible reference target. "The current room is different from the old room" does not necessarily mean it is wrong: a legitimate staff edit could have been approved. The target needs an owner, version, applicable time and authority. If the target is missing, record the comparison as unverified, not automatically a mismatch.

2.16 The numerator and denominator have different evidence requirements

A count needs a numerator, the items meeting the definition, and a denominator, the items in the defined population against which the count could be interpreted.

Suppose a restricted comparison examines five selected booking IDs and finds two confirmed mismatches. A precise statement is:

"Two of the five selected IDs have a verified mismatch under the supplied comparison rules; the other three require their own status classification."

It would still be incorrect to claim:

"Forty percent of Harbor Library bookings were corrupted."

The selected five could have been chosen because they were suspicious, reported or otherwise convenient. Without evidence that the five represent the entire relevant population or a valid sampling design, their observed proportion cannot be generalized to every booking.

Selection may be case-driven rather than representative. An incident analyst often investigates the most urgent known objects first. That is appropriate for containment and service repair, but it creates a biased basis for estimating prevalence. Case selection and statistical sampling are different activities.

The analyst should separate:

• Known examined frame: the exact identifiers selected and why.
• Comparable items: selected identifiers for which both approved reference and current values are available.
• Confirmed mismatches: comparable items that fail the declared equality or business acceptance check.
• Unverified items: records missing one of those comparison prerequisites.
• Unexamined population: objects outside the selected frame or with unknown existence or completeness.

Do not silently exclude unknown items from the report just to make the ratio look more favorable. Instead state, for example, "two mismatches, two matches and one unverified item within the five listed comparisons; no population-wide estimate available."

This approach is useful even when no percentage is calculated. Counts expressed with explicit scopes let the next analyst decide whether to broaden the inquiry or correct known business state immediately.

2.17 Deduplicating does not mean discarding evidence

A help-desk queue may contain repeated calls, email replies or follow-up tickets about one booking. Deduplication can prevent overcounting booking identifiers, but it must not destroy the fact that multiple reports were received.

Consider two fictional tickets referencing the same booking. For the question "How many distinct bookings have a reported concern?" the two tickets correspond to one booking identifier. For the question "How much help-desk demand was received?" they remain two separate contacts. For the question "How many people were affected?" neither answer is sufficient unless the distinct individuals and relevant outcome are reliably established.

Always preserve the original ticket IDs. A normalized table may group them by booking identifier, but the grouping rule must be explicit and reversible. If a booking ID is absent or misspelled, do not make an automatic identity assumption from a similar time or room number.

A dangerous shortcut is to treat multiple independent reports as multiple verified incidents or to count one booking once for each edit event. Another shortcut is to collapse all reports into one and then claim that only one person was affected. Each changes the unit without informing the reader.

The source/copy/interpretation separation explained in Chapter 02 also applies here. A normalized, deduplicated view is a derived analytical product. Keep the source pointers and transformations visible. NIST SP 800-92 discusses log-management processes and the handling of event records at an organizational level. It does not specify the fictional deduplication procedure in this section.

2.18 Missing information is an impact result, not a reason to guess

An absent owner-approved target, missing current-state row, incomplete query filter or unreliable source timestamp makes some impact claims unverified. This classification does not say the booking is healthy or broken.

A response team must distinguish:

1. Negative observation: a defined, functioning, appropriately scoped test produced evidence supporting an absence or expected result within its bounds.
2. Missing observation: the record or comparison needed for the test was not supplied or could not be trusted.
3. Contradictory observation: a properly conducted comparison produced a result that fails the accepted target.

A query that returns no relevant audit rows while collection health is unknown belongs in the second category for any broad absence claim. A state comparison that explicitly shows a different accepted value may support the third category—but only if the target and current value have adequate provenance.

R14's quiet summary is a reminder: a bounded log query cannot certify that no changes occurred outside its query envelope. R15's 24-hour retention policy adds urgency to preserving the source needed for an impact comparison, but its exact deletion anchor remains unknown. These limits affect what can be measured as well as what can be investigated.

2.19 A defensible impact ledger

A useful impact ledger contains one row per selected business object, with separate columns for the sources that describe it. It should not put a free-form narrative in place of a test result.

Lesson table; scroll horizontally to read all columns →

An analyst should not add patron names or unrelated account details to a shared impact summary when booking identifiers and controlled references are sufficient. The service owner can evaluate business consequences and authorize further checks within the relevant privacy rules. NIST SP 800-86 provides source-aware guidance for incorporating forensic techniques into incident response; it does not provide a blanket authorization to collect personal data.

The impact ledger's selection reason is especially important. If every row was selected because someone complained, a ratio from those rows cannot estimate how common a problem is among people who did not complain. If the source is a partial application audit, the ledger cannot measure omitted write paths or disappeared records. State the missing part of the frame before recommending a new collection.

2.20 Contrastive worked example at the Round B decision

Plausible but incorrect assessment:

"R3, R4 and R9 show three booking edits, and R5 and R11 contain two patron reports. Five patrons were affected, so the incident has a confirmed five-user impact."

This is an invalid unit conversion. The three application changes are not five distinct people. The two help-desk reports are observations of reports, not independent verification of two incorrect authoritative states. R3/R4 may include approved training work. Nothing in the Round B case establishes a complete distinct-patron population or the final approved booking targets.

Correct bounded assessment:

"By the fictional 09:20 Round B review, Harbor Library has source records reporting changes to B17, B18 and B19, plus patron complaints involving B18 and B19. The approved scope and current authoritative state for those bookings have not been fully verified. The incident lead should request a bounded, service-owner-approved comparison of the relevant booking identifiers with the correct target state, preserving its source coverage and retention limitations. No total of affected patrons can yet be established from the supplied material."

This assessment makes a useful decision while refusing a fabricated count. It does not need to delay all protective action until every record is available; urgency, ongoing potential harm and evidence loss remain separate considerations.

2.21 Communicate a lower bound without claiming completeness

If an authorized comparison later verifies that two selected booking states are inconsistent with approved targets, the analyst can sometimes state at least two identified mismatches among the checked items. That is a lower bound for the known, explicitly identified objects under the test assumptions. It is not the total affected booking count unless the investigated frame is complete.

For a public message, even a correct internal count may be too specific if it exposes other patrons or could be misread as exhaustive. An internal service owner may need booking IDs, approved targets and corrective owners; a patron-facing note may only need to acknowledge a possible room-booking discrepancy and describe the owner-confirmed assistance channel. The communications role must not convert "we have identified two incorrect selected bookings" into "only two bookings were affected."

A review should ask which wording remains true if additional relevant source records arrive later. "Two mismatches were identified in the approved five-object comparison" remains true, assuming that comparison was valid. "Only two bookings were affected" can become false as soon as an additional affected object is found. The first is therefore a more resilient and auditable statement.

2.22 Failure modes and acceptance limits

Lesson table; scroll horizontally to read all columns →

A beginner has met this section's objective when they can select the correct unit, preserve source and derived identifiers, distinguish confirmed mismatch from missing comparison evidence, and write a decision-ready conclusion without claiming a measured population they never examined.

2.23 Offline laboratory — IM2: Reports, distinct bookings and confirmed mismatches

Classification: Independently invented, offline-only teaching fixture. IM2 is not an additional Harbor Library R-series release, not an approved production comparison, and not P1/C1 from Chapter 03. Identifiers X01–X05 and X99 are fictitious classroom business objects; T01–T04 are fictitious report references.

Goal: Separate ticket count, distinct reported booking IDs, verified mismatches in an examined frame and unverified comparisons. Demonstrate how removing an approved reference changes the strength of a claim without changing the underlying hypothetical current value.

Environment: Python 3 standard library, in memory. No file operations, network calls, credentials, database writes or real identities.

Input assumptions: The dictionary TARGET supplies an artificial owner-designated comparison target; CURRENT supplies an artificial current-state view. These values are inputs invented for the exercise, not real owner approvals or authenticated exports. A value None means the target is missing. The report tuples are separate source observations; repeated booking references are preserved.

Before running, predict: (a) the number of reports, (b) the number of distinct booking references in those reports, (c) which examined IDs mismatch, and (d) what happens when the reference target for X04 is removed in a variant.

TARGET = {
    "X01": "Room A",
    "X02": "Room B",
    "X03": "Room C",
    "X04": "Room D",
    "X05": None,
}

CURRENT = {
    "X01": "Room A",
    "X02": "Room C",
    "X03": "Room C",
    "X04": "Room B",
    "X05": "Room A",
}

REPORTS = [
    ("T01", "X02"),
    ("T02", "X02"),
    ("T03", "X05"),
    ("T04", "X99"),
]

The report list is preserved as four contacts. The classifier below builds a union of IDs, then checks whether each one has both values needed for a comparison. Run the three code blocks together in order in one Python session.

def compare_one(booking_id, target, current):
    expected = target.get(booking_id)
    observed = current.get(booking_id)
    if expected is None or observed is None:
        return "UNVERIFIED"
    if expected == observed:
        return "MATCH"
    return "MISMATCH"

def classify(target, current, reports):
    ids = sorted(
        set(target) | set(current) |
        {booking_id for _, booking_id in reports}
    )

    counts = {
        "MATCH": 0,
        "MISMATCH": 0,
        "UNVERIFIED": 0,
    }

    results = {}

    for booking_id in ids:
        status = compare_one(booking_id, target, current)
        results[booking_id] = status
        counts[status] += 1

    distinct_report_ids = {
        booking_id for _, booking_id in reports
    }

    print(
        "reports:", len(reports),
        "unique_booking_refs:", len(distinct_report_ids)
    )

    for booking_id in ids:
        print(f"{booking_id}: {results[booking_id]}")

    print(
        "counts:",
        ",".join(f"{key}={value}" for key, value in counts.items())
    )

    return results

The negative control removes a reference from a copy of TARGET; it does not change CURRENT or edit a booking. Predict the change in claim strength before running this final block.

original = classify(TARGET, CURRENT, REPORTS)

# Negative control: remove the approved comparison
# value from a copy, without modifying the baseline.
variant = dict(TARGET)
variant.pop("X04")

negative_status = compare_one("X04", variant, CURRENT)

print("negative_X04_target_removed:", negative_status)

assert original["X04"] == "MISMATCH"
assert variant.get("X04") is None
assert compare_one(
    "X04", {**TARGET, "X04": CURRENT["X04"]}, CURRENT
) == "MATCH"

Compare your result with the IM2 worked transcript and interpretation in the final answer appendix. The silent equality assertion checks the same comparison rule used by the baseline and missing-target variant; an existing target does not always imply a mismatch.

2.24 Privacy-aware evidence selection and reproducible review views

A complete source and a useful analyst view are not the same object

An incident investigation often needs enough information to distinguish competing explanations. That does not mean every analyst needs every field from an application export. A raw system record may contain account labels, booking identifiers, timestamps, request identifiers and additional contact information. Some fields could help answer the immediate incident question; others may reveal personal information unrelated to it.

The existing Chapter 02 already insists on bounded collection and trustworthy source provenance. It explains that byte-identical copies do not prove source completeness and that a quiet query cannot establish absence outside its envelope. This expansion asks a distinct question: After an authorized source has been identified, which fields may a specific reviewing role receive for a specific question, and how can the transformed view remain reproducible without unnecessarily spreading unrelated information?

Three objects should be distinguished:

• Source record: The original record or authorized copy from its named producer, with its actual selection and collection limits.
• Working review view: A derived selection of rows and columns created for a specific decision purpose. It may omit or mask fields, but it must be labeled as a transformation.
• Decision statement: The analyst's bounded conclusion drawn from that view, with references to the source or a custodian who can verify any omitted details.

A review view is not a more authentic original just because it looks tidy. It is an analytical product. If it hides a relevant source identifier, the reviewer may lose the ability to verify what was selected. If it exposes every available patron contact field, the team may exceed its stated purpose. Both are quality failures.

NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) provides primary guidance on identifying and protecting PII according to risk and context. It is focused on U.S. federal agencies and does not establish the privacy law or authorization rules governing the fictional Harbor Library. The field-level exercise below is original OpenCyber Academy instructional material.

Begin with a permitted decision question, not a list of available columns

Consider the question available at the 09:20 Round B review:

"Which recorded operation concerning B19 should the application custodian investigate, and which available account/time identifiers could help test the approved-training explanation?"

This question may require a booking identifier, operation type, timestamp, account label, source name and record ID. It does not automatically require a patron's home address, email, telephone number, newsletter membership or unrelated reservations.

The decision purpose comes first. Then the analyst and custodian identify the minimum relevant sources, permitted rows and columns, approval and whether any sensitive field is truly necessary. The need for personal information may change if a different authorized question is posed—for example, notifying a person about a verified service consequence. That later purpose requires its own authority and evidence.

A weak collection plan says, "Export every user detail in case it becomes useful." This gives future unknown questions control over today's data exposure. A stronger plan identifies a current question and the specific fields that could discriminate among current hypotheses, with a way to request more through an authorized owner if the original selection proves insufficient.

The correct goal is proportionate access without destroying legitimate investigative capability. It is not simply making every exported file as small as possible. An underspecified view can falsely suggest that two events are unrelated because the join identifier was removed. Conversely, a broad export may include sensitive data with no decision value.

At rapid level, the student should state the question, list each requested field, describe its purpose and identify a permitted alternative if that field cannot be shared.

Separate record selection from field projection

Two distinct filtering operations commonly occur when preparing evidence for review.

Row selection determines which events or business objects appear. A proposed Round B selection might concern B17–B19 over an approved interval, rather than every historical booking. The exact source and time filter must be documented. R15's deletion rule creates urgency, but does not specify a deadline anchor or authorize a broader export.

Field projection determines which properties of those selected rows appear in the working view. One reviewer may need event IDs, booking IDs, timestamps, operation names and account labels. A different role may need an aggregate service-status note rather than technical identifiers. Neither view is an original log.

Both transformations must be recorded. A view's reported row count is meaningless without the selection that produced it. A small number of rows may reflect a narrow scope, a data absence, a wrong filter or a broken collection path. Field projection cannot repair any of those problems.

The selection plan should name the producer, approved query interval, relevant account or booking filters, source clocks, collection/ingestion limitations, collector and reviewer roles. Chapter 02 already develops those concepts for R13/R14, VQ2 and T1/T2. This supplement adds a required second line: Which exact columns are retained or withheld for the receiving analyst, and which original source custodian can recheck an omitted field if needed?

A changed selection or projection produces a different analytical artifact and must be versioned, not silently substituted for the first output.

The minimum view must still answer the question

Removing irrelevant data is valuable only if the remaining view can support a defensible conclusion. Suppose an analyst wants to associate an application change with a reported booking symptom. If the view removes the booking identifier, the analyst may not be able to connect the records. A row with only an operation and time can be insufficient, especially when multiple requests occurred nearby.

A required correlation field is a field necessary to compare the selected records under the approved method. Its presence does not make a correlation valid by itself. Two systems may use similarly named IDs with different namespaces or semantics. The existing Q1 laboratory demonstrates that an overlapping time window and account label can leave more than one candidate session. A privacy-aware view must not erase that uncertainty or use masking as an excuse to guess which session was involved.

An application-account label such as desk-a can itself be sensitive operational context. It may be appropriate for a restricted technical reviewer but unnecessary for a patron-facing message. The fact that a field is not a full legal name does not make it safe for unlimited distribution.

A field checklist therefore needs two explanations: why retained and why not retained. For example, keep a stable source event identifier so another reviewer can retrieve the correct raw row through an authorized custodian. Keep an operation type to distinguish edit from view. Omit a contact address if the current question does not need it. If a field's necessity is unknown, pause the release decision and ask the approving role rather than selecting it automatically.

Pseudonymization is not the same as anonymity

Sometimes a team wants to replace a directly identifying value with a less revealing label. For example, a review table might use an internal case alias instead of a patron contact address, while a restricted custodian maintains the approved mapping. Such a transformation may reduce unnecessary exposure, but it does not establish that a person can no longer be identified.

A consistent alias may link a person's activities across multiple rows, even when the person's name is absent. Other available fields—time, booking pattern or account metadata—may allow association with a real individual when combined with additional sources. A pseudonym should therefore still be treated according to its remaining disclosure risks.

Nor is a cryptographic digest of a contact address necessarily an anonymous value. Predictable inputs may be guessable, a shared digest can link repeated activity, and any reversible mapping creates a reidentification route. It would be incorrect to say, "The email was hashed, so the export contains no sensitive data." A secure pseudonymization scheme, if needed, requires a separately approved design, key protection, access control and threat assessment, beyond this introductory exercise.

The MIN2 laboratory deliberately omits contact fields rather than generating pseudonyms. It checks that the intended reviewer receives only declared analysis columns and that the source retains its original teaching values unchanged. This is easier to audit and avoids suggesting a toy hashing operation can solve privacy risk.

Anonymity is a much stronger claim than "a visible name has been replaced." Nothing in this chapter's fixture establishes irreversible anonymity.

Keep the original available under an appropriately controlled procedure

A bounded review view should not overwrite or replace the original record set. An analyst may need to verify whether a transformation omitted a relevant field or merged two events incorrectly. If the original was deleted, that review may no longer be possible.

For a real authorized collection, the relevant custodian should follow organizational retention, access, preservation and evidence-handling rules. The preservation may require restricted access to fields that are not distributed to every analyst. Protecting the source and minimizing the working copy are complementary, not contradictory, when they are each justified by their purpose and authority.

This does not mean preserving all personal data indefinitely. The original collection itself must be authorized and proportionate, and retention obligations depend on the organization's rules and applicable requirements. The book does not provide a general legal preservation order or permission to copy unrelated patron data.

In Chapter 02, the E1 exercise already distinguishes a synthetic transcription from an authenticated original and shows that matching SHA-256 values support limited byte consistency. A new working view should have a transformation manifest and source pointer; it cannot inherit authenticity merely because its source file had a digest check.

An effective manifest records: source identity, query selection, collection status, reviewer access scope, fields retained, fields deliberately omitted, transformation version, creator and creation time if actually performed, and the known limits. A planned transformation with no created output must remain planned, with no fabricated timestamp or digest.

Privacy and investigative value can fail in opposite directions

A review view can fail through excess or insufficiency.

An excess-field failure occurs when the output includes contact information outside the approved purpose. The analyst may still be able to investigate, but the disclosure is broader than necessary. A missing-key failure occurs when the output omits the booking or event identifier needed for the intended comparison. This may appear more protective at first glance, but it can make the authorized review unreliable.

These failures do not cancel each other. One cannot justify unnecessary contact data simply because the view contains other useful columns. One cannot call an unusable view successful just because it exposes fewer fields.

A third failure occurs when the row filter expands beyond the approved objects. A view may have an entirely appropriate set of columns but include records for an unrelated booking. Field-level restrictions do not automatically justify overbroad row selection.

The negative controls in MIN2 test all three conditions separately: removing the required booking key, adding a contact field and including an unapproved booking ID. The program rejects each variant instead of quietly producing a wider or less useful view.

This is an original data-handling acceptance contract. It does not attempt to determine every possible category of personally identifiable information or replace a full privacy impact assessment.

Contrastive worked example: "we have only the facts we need"

Incorrect hypothetical assessment:

"For R9, export the full patron profile, all contact details and all newsletter fields. The analyst might need them later. After copying them, delete the original and keep only a masked table; the mask proves the evidence is anonymous and complete."

The first step lacks a specific decision purpose for unrelated contact data. The second risks destroying the source context and provenance. The third converts a superficial masking operation into unsupported claims of anonymity and source completeness. None of those steps is authorized by R9 or the Round B release.

Defensible decision proposal:

"At 09:20, R9 reports a B19 booking edit, while R10–R13 provide limited training, patron-report, recollection and session context. The analyst requests that the application custodian confirm the approved source and select only the records and fields needed to investigate the B19 operation within a bounded interval. A technical review view may retain stable event/booking IDs, event time, operation and appropriate account context, while unnecessary patron contact details remain outside that view. The source and any transformation are preserved only according to the approved collection and access rules. No export or identity finding is claimed completed."

The proposal answers a specific question, names the custodian and leaves missing proof visible. It also prevents the opposite error: removing every identifier and then attributing events through timestamps alone.

Release boundaries still govern restricted views

A projection cannot make later evidence available earlier. At the 09:05 Round A checkpoint, R9–R16 do not exist in the learner's released set, even though R9 reports an event at 09:03. A review view derived from R9 is therefore not available for the Round A decision.

At the 09:20 Round B checkpoint, R1–R16 are available as supplied synthetic cards. The learner can design an authorized review request but must not claim that a custodian delivered unprovided raw fields. R13 lacks device and location detail; privacy minimization does not entitle the learner to fill those fields with guesses. R14's query scope is incomplete; a nicely projected table cannot repair that coverage limitation.

R15 adds a separate urgency to determine source retention, but its 24-hour deletion rule lacks a documented anchor. No projection can compute a defensible exact deadline without that missing policy detail.

The MIN2 rows are exercise-only symbols. They are not the same as the original R-series booking values, and they cannot be used to assert how many Harbor Library patrons were affected. The IM2 exercise addresses a separate counting problem, with its own X-series data and limits; MIN2 addresses how a narrowly scoped review view should be constructed and rejected when its field or object policy is violated.

Different reviewers should not automatically receive identical views

Operational teams contain distinct roles. A technical analyst investigating whether a booking edit and session event might be related may need an account label and source identifier. A service owner deciding whether booking state should be corrected may need booking IDs and approved targets. A communications contact preparing a patron-facing update may need a description of the service consequence, not an internal account name or raw contact list.

A single all-purpose export can encourage unnecessary forwarding between those roles. The better practice is to specify the receiving role and purpose before preparing the view, with explicit escalation when a reviewer needs more.

Do not treat role restriction as a replacement for source integrity. The service owner still needs valid authoritative booking data. The privacy contact may need to assess an allegation through a different approved process. A communications role's lack of raw data must not be "fixed" by inventing missing facts.

The fictional case does not define an organizational data-classification scheme or actual permissions. A course learner can design candidate views and approval questions while leaving operational implementation pending. It would be misleading to name a specific privacy law or notification threshold without the jurisdictional and organizational facts required.

Source identifiers and account labels retain uncertainty

A source event identifier lets a reviewer ask a custodian for the precise original row. It does not by itself authenticate the producer or prove that the data were complete. A booking ID connects a review row with a business object under that source's semantics; it may not be globally unique across all environments or time periods.

Similarly, an account label says what the source attributed to an account or session context. It does not identify the human operator. In Harbor Library, desk-a is an account reference. The absence of device/location detail in R13 remains an unresolved question even if a derived view perfectly retains the account field.

These limits are important because a carefully minimized view may look authoritative. Exact row IDs, tidy column names and consistent aliases can make a table appear complete. A disciplined reviewer asks which producer emitted each field, whether the join identifiers are actually comparable, whether the source query covered the intended interval and what was omitted.

MIN2's actor_account column is therefore a fictional correlation candidate, not a human attribution result. Its inclusion is allowed only within the exercise's explicitly defined technical-review policy, not as permission to publish account details widely.

Record transformation without pretending the source changed

A derived review view is not a modified original source; it is a new analytical artifact. A transformation log should allow another authorized reviewer to repeat the same row selection and field projection if the original is still available under the applicable retention rules.

For a small classroom review, record:

1. The permitted question and receiving role.
2. The approved booking/object scope.
3. The source record count and declared producer.
4. The exact fields retained and omitted.
5. Any normalization of timestamps or identifiers.
6. Whether the required correlation fields remain available.
7. The output row count and any errors.
8. The transformation code/version.
9. The result's limitations and who may resolve missing fields.
10. The fact that no real collection or release occurred.

A report saying only "personal details removed" omits too much. It does not identify which personal details, which source rows, which version or whether the transformed view can answer its intended question. A report saying "privacy protected" is even less testable.

The test should include negative cases. If the policy requires a booking ID and it is removed, the view must fail the task's acceptance condition. If a contact email is added, it must fail the field-minimization gate. If an unrelated booking is selected, it must fail the row-scope gate. Rejecting an unsafe requested view before producing it is a legitimate successful outcome for this exercise.

An authorized extension is not automatic scope creep

Sometimes the initial view is genuinely insufficient. Perhaps an authorized investigator cannot distinguish two records without a session identifier held in a different source. The right response is not to silently broaden every analyst's access. The investigator should document which decision depends on the missing field, why the current view is insufficient, and which custodian and approver can evaluate a targeted extension.

Such a request may be granted, denied or returned for clarification. Any newly approved selection is a distinct transformation version with its own source and limits. An extension does not imply that the old view was dishonest or that the newly supplied data retroactively existed at an earlier checkpoint.

A useful stopping rule is: if the evidence required for a claim is not inside the authorized current view, stop that claim and request additional permission or mark it unresolved. Do not use a field guessed from context to fill a missing column. If the current question can already be answered under its limits, do not collect unrelated information merely to make the record larger.

A practical incident process balances confidentiality, integrity and availability of evidence. Preserving too little can prevent a needed investigation; distributing too much can create another exposure. A well-specified purpose and validation rule keeps both risks visible.

Section synthesis: minimize the view without minimizing the truth

Evidence work needs two kinds of discipline at once. The source and its provenance must remain trustworthy and correctly scoped, while each review copy should contain only the information required for that receiver's approved question. Neither a complete original nor a minimal view automatically produces a correct causal conclusion.

For Harbor Library at 09:20, the right result is still a bounded investigation proposal, not a completed source export, a confirmed human actor or a population-wide impact count. MIN2 shows how a review can fail because it contains an unnecessary contact field, lacks a join identifier or reaches an unrelated booking.

The transferable beginner skill is to explain what was included, what was omitted, why both choices matter, and what the reviewer still cannot establish.

MIN2 Offline Laboratory — Select a Review View Without Losing Correlation

Status: Entirely synthetic and isolated. MIN2 is not R1–R16, not a real patron export and not the earlier E1, Q1, VQ2 or IM2 fixture.

Goal: Produce only the approved minimal technical-review fields for an approved synthetic booking selection; reject a missing join field, unnecessary contact field and expanded object scope. Preserve the original artificial source rows unchanged.

Environment: Python 3 standard library, memory only; no files, external requests, accounts or production data.

Input meaning: Q11 is the only approved booking ID in this exercise. The invented patron_email values use reserved example.test addresses. The actor_account field is a fictitious technical label, not a human identity. A READY label does not prove the source is authentic, the selection complete or the query authorized in a real setting.

Executable Python code

EVENTS = [
    {
        "event_id": "SYN-A", "booking_id": "Q11",
        "event_time": "09:03", "operation": "EDIT",
        "actor_account": "staff-x",
        "patron_email": "ava@example.test",
    },
    {
        "event_id": "SYN-B", "booking_id": "Q11",
        "event_time": "09:06", "operation": "VIEW",
        "actor_account": "staff-x",
        "patron_email": "ava@example.test",
    },
    {
        "event_id": "SYN-C", "booking_id": "Q12",
        "event_time": "09:08", "operation": "CANCEL",
        "actor_account": "staff-y",
        "patron_email": "bea@example.test",
    },
]

SOURCE_SNAPSHOT = [dict(row) for row in EVENTS]

ALLOWED = {
    "event_id", "booking_id", "event_time",
    "operation", "actor_account",
}
SCOPE = {"Q11"}
REQUIRED = {"event_id", "booking_id", "event_time", "operation"}

def review(label, fields, bookings):
    if not bookings:
        print(f"{label}: REJECT_EMPTY_SELECTION selected=0")
        return
    if not bookings.issubset(SCOPE):
        print(f"{label}: REJECT_SCOPE selected=0")
        return

    extras = fields - ALLOWED
    if extras:
        print(f"{label}: REJECT_EXTRA_FIELD {','.join(sorted(extras))}")
        return

    missing = REQUIRED - fields
    if missing:
        print(f"{label}: REJECT_MISSING_KEY {','.join(sorted(missing))}")
        return

    subset = [
        {key: row[key] for key in sorted(fields)}
        for row in EVENTS
        if row["booking_id"] in bookings
    ]
    if not subset:
        print(f"{label}: REJECT_NO_SOURCE_ROWS selected=0")
        return
    print(
        f"{label}: READY rows={len(subset)} "
        f"fields={','.join(sorted(fields))}"
    )
    print(
        f"{label}: bookings="
        f"{','.join(sorted({x['booking_id'] for x in subset}))}"
    )
    return subset

review("MINIMAL", ALLOWED, {"Q11"})
review("DROP_BOOKING", ALLOWED - {"booking_id"}, {"Q11"})
review("ADD_EMAIL", ALLOWED | {"patron_email"}, {"Q11"})
review("EXPAND_SCOPE", ALLOWED, {"Q11", "Q12"})

print(
    "SOURCE_UNCHANGED:", len(EVENTS),
    "rows; sensitive field retained in synthetic source only"
)
assert len(EVENTS) == 3 and "patron_email" in EVENTS[0]
assert EVENTS == SOURCE_SNAPSHOT
view = review("VIEW_CHECK", ALLOWED, {"Q11"})
assert view is not None and len(view) == 2
assert all("patron_email" not in row for row in view)
review("EMPTY_REQUEST", ALLOWED, set())
saved_events = EVENTS
try:
    EVENTS = [dict(saved_events[2])]  # only Q12 in this variant
    review("NO_Q11_ROWS", ALLOWED, {"Q11"})
finally:
    EVENTS = saved_events
assert EVENTS == SOURCE_SNAPSHOT

Predict the six baseline and four additional output lines; explain the three original rejected variants and the two new empty-selection controls before checking the MIN2 worked result in the final appendix. The fixture contains no real personal data. The returned projected view is for the approved fictional review role only; READY does not establish source authenticity, complete collection or real custodian permission.

2.24a Evidence availability is not the same as event time

Learning outcome: Before making a triage or preservation decision, distinguish when a fact allegedly occurred, when the producer recorded it, when a custodian acquired it, and when the responder could actually use it. The same record can have a very early event time and still be unavailable at a prior decision. This is not a pedantic issue: the ability to defend a proportionate decision depends on knowing which facts the decision maker could have seen.

At the first 09:05 checkpoint, R1–R8 are supplied. R9 describes an edit at 09:03 but is withheld until Round B. The analyst cannot treat that event as observed at 09:05 simply because its clock precedes the review time. At 09:20, R1–R16 make the B19 question visible; R17's later approved-task detail has not yet been released. At 09:37, the R1–R24 release supports a containment proposal, not a completed change. P1/C1 and V1 are later exercise cards and cannot justify that proposal.

When building an evidence ledger, record these separate attributes: source event time, ingestion/indexing time where known, case acquisition or receipt, learner/facilitator release, role authorized to view, source-query coverage, and status of the asserted observation. A blank value remains unknown rather than a value silently supplied from another card. A negative query needs declared source and clock coverage; “no result” is not evidence that nothing occurred outside the selected window or after the ingestion cutoff.

Contrastive example: A participant prepares a 09:05 note saying "R9 proves an unauthorized B19 edit." This fails twice: R9 was not released and it does not identify an unauthorized human. A valid note says "R1–R8 show the named booking events and the possibility of scheduled training; ask the service owner whether the work was permitted and set a bounded review." When R9 becomes available, the participant versions the note and adds B19 as a new reported edit, preserving the earlier snapshot. A second false shortcut uses R17 to pronounce at 09:20 that all authorized tasks are known. The later task list cannot cure the earlier uncertainty retroactively.

Why privacy matters: An authorized, source-complete producer copy and a minimized analyst view are different objects. A non-privileged learner can receive a pseudonymized booking/state projection without obtaining raw patron contacts or every identity field. A projection must retain its query, transformation, source object identifier, date and limitations. If the source was never collected, a tidy projection with plausible rows is no substitute. The analysis should never reconstruct withheld identity data from guesses to make its graph feel complete.

NIST SP 800-61 Rev. 3 provides the current risk-management setting for incident response; NIST SP 800-86, published in 2006, supplies foundational but dated discussion of forensic source handling. The release schedule below is an original OpenCyber Academy teaching rule, not a NIST timetabling requirement.

R2X offline lab — prove the decision's evidence horizon

Use Python 3 offline, with no imports, files or network. The values are pedagogical release levels for selected case cards, not actual service event times. The two D stages are intentionally separated: D1 is the branch-only checkpoint, D2 follows P1/C1 release. V1 remains a later independent card.

FIRST = {"R1": 0, "R9": 1, "R17": 2, "P1": 4}
LEVEL = {"A": 0, "B": 1, "C": 2, "D1": 3, "D2": 4}

def release(stage, card):
    return "RELEASED" if LEVEL[stage] >= FIRST[card] else "WITHHELD"

cases = [
    ("EVENT_BEFORE_RELEASE", "A", "R9"),
    ("ROUND_B_R9", "B", "R9"),
    ("PREMATURE_R17", "B", "R17"),
    ("PREMATURE_P1", "C", "P1"),
    ("LATER_P1", "D2", "P1"),
]
for label, stage, card in cases:
    print(label, release(stage, card))

Literal tested output:

EVENT_BEFORE_RELEASE WITHHELD
ROUND_B_R9 RELEASED
PREMATURE_R17 WITHHELD
PREMATURE_P1 WITHHELD
LATER_P1 RELEASED

Adversarial challenge: An analyst substitutes R9's event time for its Round B release stage and incorrectly calls EVENT_BEFORE_RELEASE a pass. This is a semantic failure, not a clock-parsing bug. A second challenge promotes P1's 09:40 owner-target time into a 09:37 decision; the classifier correctly says WITHHELD. The code does not authenticate a source, approve collection or determine whether a reported edit was malicious.

Reproducible practice: Produce the five printed lines, a two-snapshot note at 09:05 and 09:20 and a one-paragraph comparison of source acquisition, learner release and actual query coverage. Award full credit when the learner preserves the earlier decision version and identifies a bounded owner-approved next source request without copying personal data. This laboratory creates no new EX identifier, event, evidence receipt or booking change.

Synthesis: More data at a later checkpoint can improve the next decision. It cannot establish that an earlier decision was supported by information the responder did not yet have.

Worked checkpoint

When two supplied reports describe the same booking, count one distinct booking and retain both pointers. If the authoritative state is unavailable, place the booking in an unknown bucket rather than the confirmed-correct or confirmed-wrong count.

Practice — Lesson 10

EX023 — Impact check

Objective: size possible service harm without exporting unrelated patron data. Inputs: R9, R11, R14–R16 and the service map. Output: a short query request naming approver, custodian, booking identifiers or short event range, necessary fields, expected result table and privacy/access limit. The table should distinguish an audit edit, an owner-approved state and an unresolved mismatch. A score of 2 does not claim a completed count or that R14 covers the whole period.

Extension: Define a positive result and a negative result for the proposed booking comparison. A positive result must distinguish recorded edits from the current authoritative state; a negative result must explain how a mismatch or missing state affects the confidence of the claim. Record which patron fields remain outside scope.

For full credit: The learner cannot supply a measured affected-patron count from R9/R11 alone or treat R14 as complete coverage.

Additional measurement contract for EX023: State the unit (distinct booking ID), the selected comparison frame and why it was selected, the owner-approved target/current-state fields, and separate reported concern, recorded edit, verified mismatch and unverified comparison. A case-selected numerator is not a population prevalence estimate. As optional offline practice, use IM2 to show how repeated tickets and missing targets remain visible; never import X01–X99 into the R-series case.

MIN2 supplementary task (after the required artifact):

Additional task: Add a field-by-field justification for a proposed restricted booking-impact comparison. Distinguish what the analyst needs to classify a selected booking discrepancy from any contact details needed for separate patron communication. The latter require a different permitted purpose and must not be silently included in the technical comparison.

For full credit: The learner still defines the measurement unit and selected frame as taught in IM2, keeps unverified rows visible and does not infer affected people from ticket count or claim a completed comparison from R1–R16.

Worked answer: EX023 in the final appendix.

EX025 — Correct a faulty note

Faulty hypothetical note to repair (exercise text, not an R-series record):

“R9 proves an attacker stole the desk-a account. The attacker edited every booking. R8 and R11 prove the patron database was exfiltrated.”

This deliberately defective note asserts account theft and an identified actor, all-booking scope, and confirmed data exfiltration without supporting evidence. Rewrite it using only R9, R11, R13 and R8; then list the three claims you discarded. Do not replace the note with an equally unsupported assertion that no transfer occurred.

Objective: repair unsupported attribution and scope. Inputs: R9, R11, R13 and R8. Output: a replacement of at most three sentences with one observed booking fact, one evidence limit and one next authorized check. Then underline or list the three unsupported claims removed from the faulty note. A score of 2 does not equate R8's missing destination detail with proof of no transfer either.

Worked answer: EX025 in the final appendix.

EX026 — Reproducible review

Objective: challenge an overconfident peer conclusion constructively. Inputs: R6, R9, R10 and R12. Output: a four-field review note: claim, directly supported facts, missing discriminator for B19, and authorized way to obtain it. Explain what outcome would change your view. A score of 2 preserves the possibility that training explains B17/B18 while leaving B19 unresolved; it does not assume the staff member is lying.

Worked answer: EX026 in the final appendix.