Review the profile pull request

Objectives

A pull request against the production OSCAL stack touches the catalog, the profile and the SSP in one change. It is due to merge before the assessment window opens, and the author has already had it approved once by a colleague who reviewed it for typos.

Accept the entries that are legitimate tailoring decisions. Reject the ones that damage the stack, whatever the commit message says.

Verdicts are accept or reject. Every rejection needs one reason code from: catalog-edited-in-place | tailoring-without-rationale | broken-control-reference | untracked-parameter.

O-1  Adds AC-2 to include_controls, rationale cites the internal access standard.
O-2  Rewrites the AU-6 control statement inside the vendored catalog file "so it matches how we review logs".
O-3  Sets the AC-2 inactivity parameter to 15 days at the profile layer, rationale names the standard.
O-4  Removes SC-7(3) from include_controls; commit message reads "n/a", no rationale field recorded.
O-5  Leaves an SSP implementation statement for SC-7(3), which the same PR removes from the profile.
O-6  Pins source_catalog to the published rev5 identifier instead of a local copy path.

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

1. Step 1

   Read the request before the artefact

   This PR mixes genuine improvements with changes that quietly break the joins between layers. Review it as a stack, not as six independent lines.

2. Step 2

   Judge every line, including the boring ones

   Six entries, six verdicts. Two of them are the behaviour you want the team to repeat, and an unremarked accept is how good practice gets re-litigated next quarter.

   Every line in the fixture carries a verdict

3. Step 3

   Separate what is wrong from what is merely ugly

   Ask three questions of each entry: does it change somebody else's requirements, does it record why the organisation chose something, and does it leave a reference pointing at a control that no longer exists in the layer above?

   Setting a parameter in the profile with a rationale is exactly right; rewriting a control statement in the catalog is exactly wrong, even though both change a value.

   Accept and reject land on the right lines

4. Step 4

   Say why, in the vocabulary the programme uses

   Use the reference code for the entry that survives a removal made elsewhere in the same PR, and the rationale code for the removal that explains itself with two letters in a commit message.

   Each rejection cites a valid reason code

Rules summary

• XP on pass

  40 bonus XP the first time every check goes green.

• Paid hints

  2 available. Each costs 25% of the lab XP (about 10 XP).

• Reveal solution

  Scores 0 XP and unlocks only after 3 check runs.

• Attempt cap

  60 check runs per learner. The runner warns you in the last 10.

• Drafts

  Your editor content is saved in this browser, so a reload will not lose work.

• Walkthrough

  Always free and never penalised: use it before spending a hint.