Design the evidence object before the command

Design the evidence object before the command

A support script should answer a defined question using a consistent record. Choose fields such as Computer, ObservationTime, Target, Dns, Transport, Application, Source and CollectionError. Do not merge failed, unknown and not attempted into the same Boolean value.

A function that returns objects can support both human display and machine export. Formatting belongs at the presentation boundary: Format-Table creates formatting instructions, so it should not be piped into Export-Csv as though it were your business objects. Keep raw observations and derived classifications separate so an operator can challenge the classification.

Reasoning model

A support script should make incomplete evidence visible. “No rows returned” can mean no findings, inaccessible source or parsing failure. Use a stable record schema with status and reason, separate collection from decisions, and require deliberate authorization for any remediation. A preview mechanism is useful only when the modifying commands participate correctly; the presence of a switch name does not prove no changes can occur.

Official reference for further study

Trace conflicting evidence

$ErrorActionPreference = 'Stop'
function Get-TriageResult {
    param([pscustomobject]$Evidence)
    $state = 'REVIEW'
    $next = 'Check the application response and affected scope'
    if ($Evidence.Application -eq 'OK') { $state = 'AVAILABLE'; $next = 'Investigate the reported workflow, not ping alone' }
    elseif ($Evidence.Dns -eq 'FAILED') { $next = 'Verify name and DNS source before testing the endpoint' }
    elseif ($Evidence.Application -eq 'UNKNOWN') { $state = 'INCOMPLETE'; $next = 'Collect application evidence' }
    [pscustomobject]@{Computer=$Evidence.Computer; Dns=$Evidence.Dns; Ping=$Evidence.Ping; Application=$Evidence.Application; State=$state; NextAction=$next}
}
$cases = @(
    [pscustomobject]@{Computer='LAB-A';Dns='OK';Ping='FAILED';Application='OK'},
    [pscustomobject]@{Computer='LAB-B';Dns='FAILED';Ping='UNKNOWN';Application='UNKNOWN'},
    [pscustomobject]@{Computer='LAB-C';Dns='OK';Ping='OK';Application='UNKNOWN'}
)
$report = @($cases | ForEach-Object { Get-TriageResult $_ })
$report | Format-List
if (($report.State -join ',') -ne 'AVAILABLE,REVIEW,INCOMPLETE') { throw 'Triage test failed' }

Trace conflicting evidence

The supplied classifier gives an application success precedence over ping failure. That is appropriate for its narrow question, but it does not make every lower-layer observation consistent. Add LAB-D with Dns=FAILED, Ping=UNKNOWN and Application=OK. Possible explanations include cached resolution, a different target or mismatched observation times.

Do not invent which explanation is true. Add a ConsistencyNote and require aligned target/time evidence before closure. The existing AVAILABLE result means that the supplied application test succeeded; rename it or explain its scope if readers could mistake it for complete device health.

Evidence laboratory — attempt before reading the solution

A fictional read-only inventory collects service state from four approved lab hosts. H1: service Agent running; H2: Agent stopped; H3: connection denied; H4: Agent not installed. The business rule is to report stopped installed agents for review, not restart automatically. Produce separate counts for confirmed stopped, collection failure and not installed. An existing script converts every exception into “Stopped” and reports three failures. Explain why that result is unsafe.

Official reference for further study

Exercise: validate rather than guess

$tickets = @(
 [pscustomobject]@{Id=101;Priority=' high ';Owner='Ana'},
 [pscustomobject]@{Id=102;Priority='Low';Owner='Ben'}
)
$tickets | Where-Object { $_.Priority.Trim().ToLowerInvariant() -eq 'high' } |
 Select-Object Id, Owner | Export-Csv './high.csv' -NoTypeInformation

Exercise: validate rather than guess

A CSV row contains Application=SUCCESS instead of the declared OK/FAILED/UNKNOWN values. Should the classifier silently treat it as failure or success?

Worked laboratory solution

Official reference for further study

Workbook already downloaded

Build a reviewable service-desk runbook

Build a reviewable service-desk runbook

Submit the three supplied baseline cases plus contradiction, missing measurement and invalid-enumeration cases. Include expected and actual classifications. Keep operational probes separate from the offline classifier; testing a classifier against synthetic records is not authorization to scan remote machines.

Your handoff should state which workflow was checked, the time and source, which layer remains untested and who owns escalation. If exporting shared reports, remove unnecessary identifiers and secrets. A script that runs without exceptions can still deliver an inaccurate diagnosis when its observations refer to different requests.

Transfer project — changed conditions

Write a read-only collector using mocked inputs first. Add a structured output file and a summary that reconciles all four hosts. Then design—but do not execute—a separate remediation stage that accepts only approved H2-like records, logs each decision and checks the postcondition. Include a stale-record test in which the service starts between collection and remediation. Explain how rechecking state prevents acting on an obsolete assumption.

Practical assessment rubric

Score each dimension 0–2: 0 = absent or materially incorrect; 1 = partly correct with an unresolved gap; 2 = correct, explicit and supported by the supplied evidence or an actual labeled lab result.

1. Evidence/model: identify the relevant entities, inputs, assumptions and boundaries without inventing facts.
2. Main result: derive the case-specific expected result, calculation or decision and show the intermediate reasoning.
3. Failure/boundary: test the changed condition and explain why the original conclusion does or does not transfer.
4. Verification: supply reproducible steps and expected/observed results; label manual traces as manual, not executed.
5. Communication/safety: explain limitations, owners and a proportionate next action without unsafe or unnecessary access.

Target: at least 8/10, with no zero in main result or communication/safety. This is a local learning rubric, not an accredited certification standard. A written/manual solution demonstrates reasoning only; operational competence additionally requires the relevant executable lab in an authorized environment. The native multiple-choice score is separate and does not automatically grade this rubric.

Submission template

• My input/evidence and assumptions:
• Expected result with calculations or trace:
• My implementation/decision and justification:
• Changed-condition result:
• Observed execution, or explicitly labeled manual trace:
• Failure and recovery evidence:
• Unverified limitation and next action:
• Self-score with evidence for each dimension:

Remediation

If the main result is wrong, reconstruct the supplied case from the raw inputs before changing code or controls. If the boundary case is wrong, identify the assumption that changed and rerun both the original and changed case. If verification is missing, do not convert a prediction into an observed result. Reattempt the transfer task without copying the worked solution, then explain it to another person.

Official reference for further study

Assessment: explain your decisions

Choose an answer and write your reason before opening each explanation. Then explain why the other choices do not fit the evidence. Use missed questions to revisit the lesson. This knowledge check is only one part of assessment: complete the practical transfer project as well. It does not predict certification-exam success.

1. Which issue does normalization address?

1. Equivalent spelling and whitespace
2. Every missing value
3. Authorization

2. What should happen to an unknown category?

1. Silently become Low
2. Be flagged for review
3. Be deleted without a count

3. What makes a scheduled file output reliable?

1. A remembered interactive folder
2. Formatting first
3. An explicit configured path

4. Application=SUCCESS arrives under a contract allowing OK/FAILED/UNKNOWN. What should a collector do?

1. Report invalid input rather than silently classify it
2. Treat every unfamiliar value as OK
3. Treat every unfamiliar value as a verified outage

5. Which pipeline preserves business objects for CSV export?

1. Convert every object to an unstructured sentence first
2. Send the result objects directly to Export-Csv
3. Format-Table then Export-Csv

6. DNS says failed but an application test says OK. What should the report retain?

1. Only the preferred observation without explanation
2. A definite root cause of stale cache
3. Both observations with a consistency warning and target/time checks

7. How many hosts are confirmed to have a stopped installed Agent?

1. One: H2.
2. Three: H2, H3 and H4.
3. Four.

8. What should H3’s report convey?

1. The service is definitely healthy.
2. Collection failed; service state is unknown.
3. The service is definitely stopped.

9. Why recheck H2 before an approved remediation?

1. Reports never become stale.
2. Rechecking guarantees every future run will succeed.
3. Its state may have changed since collection.

Use the explained questions above for offline practice. A scored attempt requires the course assessment on CogniSkill.ca.