Issue write-up

A second-line issue is the artifact that turns a confirmed exception into something the firm tracks, owns, remediates, and answers for. The shape is old: condition, criteria, cause, effect, recommendation. Internal audit has used it since the IIA standardised the communication-of-results convention. AICPA AU-C 265 carries the same frame for financial-statement-related internal control matters. Federal supervisors lean on it whenever a matter requiring attention or matter requiring immediate attention lands in a supervisory letter. The reader on the other side of the artifact, whether audit committee, regulator, or remediation owner, expects to read it in that order, with severity, owner, and target date attached.

The issue write-up is a primitive. The exception-analysis chain calls it once a control-test exception is confirmed. Internal audit calls it as the deliverable shape for fieldwork findings. Vendor monitoring calls it when a SOC report or KPI threshold is breached. Model validation calls it for findings that warrant tracking outside the validation report. Regulator-response files call it when the firm restates an examiner-issued matter in its internal format. The artifact shape is the same; the source label, the severity calibration, and the reviewer machinery shift with the source.

The write-up is the deliverable; the format is whatever the engagement and audience need. An audit-committee read or regulator-response file is memo-natural and lands as Word; an internal remediation tracker may want formatted markdown that ports cleanly into a GRC platform. The skill drafts against templates/default-output.md and emits the structured record at schemas/issue.schema.json. The artifact is a draft until a named reviewer signs off; severity assignment always carries independent attestation.

Ask first

A few facts settle before drafting. Most of them are on the table by the time someone is writing up an issue, but the discipline is to name them.

• What confirmed the condition. A test result with a sample, a failed reconciliation, a vendor SOC report opinion, an examiner letter, a self-disclosure. The source decides the source label, the severity ladder, and which reviewers attest. An unconfirmed observation is not yet an issue; it sits in engagement notes until the condition is confirmed.
• What rule, principle, standard, or policy the condition violates. Criteria is a named source with a section, not a generic "per firm policy". If the criterion is the firm's own policy, name the policy version and section; if the criterion is regulatory, name the rule and section and reference references/source-anchors.md or a sector-overlay file by path.
• What the source posture allows in the artifact. Public-only sets the ceiling at obligation, control objective, and observable condition; firm-policy-overlay or mixed lets named owners, system-of-record names, dollar amounts, and last-test results land in the body. Confidential-supervisory content (open MRA detail, MRIA scope, regulator correspondence) does not land in any artifact that will read at a lower posture.
• Who owns remediation, in role terms. The owner is the role accountable for closing the issue, not the team that found it. Where the role taxonomy is firm-specific, it lives in references/firm-overlay.md.
• Whether the issue source is an examiner letter. If yes, the MRA / MRIA classification field is populated and the closure-evidence framing matches the regulator's expected response register.

When scope is supplied, the skill consumes it for institution, persona, source posture, sector overlay, and cross-cutting overlay. Otherwise it asks the questions above and defaults to public posture if the practitioner declines. The artifact notes scope was not formalised; it does not silently assume.