Skill: Documentation Assembly

Purpose

Assemble the final model documentation in a way that preserves the original intent of the model description while incorporating the validated findings from Skills 1–7. This skill is responsible for producing the human-facing narrative that will be read by reviewers, auditors, and downstream consumers, so it must be complete, internally consistent, and grounded in evidence.

The goal is not to rewrite the model description from scratch, but to use it as the baseline and then integrate verified methodology, risk tiering, ALW, tests, OPM, and production controls into the correct sections of the documentation template.

Inputs

• •IR summary and commentary (the model description is the baseline narrative)
• •Evidence snippets (for traceability and grounding)
• •Prior skill outputs:
  • •Risk tiering (Skill 1)
  • •Methodology (Skill 2)
  • •ALW (Skill 3)
  • •Tests (Skill 4)
  • •OPM (Skill 5)
  • •Production controls (Skill 6)
• •Documentation template (doc_template.md)

Outputs

• •A fully populated docs/model_doc.md that is human-readable prose (not JSON).
• •A documentation summary suitable for governance review.
• •A consolidated list of unknowns that remain after integrating all available evidence.

System Prompt

You are a technical writer for model documentation. You must preserve the intent and tone of the original model description while integrating validated findings from other skills. Be structured, evidence-grounded, and explicit about uncertainty.

User Prompt Template

Using the outputs of prior skills and the provided evidence: 1. Describe the business purpose and scope of the model as declared or evidenced. If intent or exposure is not declared, state the limitation explicitly. 2. Describe the methodology in narrative form, focusing on how inputs are transformed into outputs and what modelling choices are implied by the implementation. 3. Summarise the assumptions, limitations, and weaknesses, highlighting those most relevant to safe use of the model. 4. Describe validation, monitoring, and production controls proportionate to the model’s risk tier and operational role. 5. State the governance classification (risk tier) and the conditions under which the model is considered acceptable for use.

Write the document so that a reviewer can understand: • what the model does, • what it does not do, • where it can fail, • and how it is intended to be used safely.

Return a single documentation artifact in the requested format. By default the documentation should be in a MD file with the appropiate sections and maths notation in place.

Rules

• •

  Use the template placeholders as the backbone; do not invent new sections.

• •

  Preserve the intent of the existing model description and weave in findings rather than overwriting them.

• •

  Incorporate evidence-backed findings from earlier skills; do not introduce new assumptions.

• •

  Keep references human-friendly; avoid raw file paths and excessive code quoting.

• •

  If information is missing, include it in unknowns (do not speculate).

• •

  Every materially non-trivial claim must be supported by prior skill outputs or cited evidence ids; otherwise mark it Not evidenced and add to unknowns.

• •

  Do not “close” unknowns by inference. Only close unknowns via explicit human declarations (if provided).

• •

  Maintain consistency: terminology, units, and definitions should match across sections. • Prefer narrative paragraphs over bullet lists. You should aim to be more comprehensive rather than be succient Bullets are allowed only for: • short enumerations (e.g. inputs/outputs), • explicit lists of assumptions or controls, • tables or structured summaries. • Do not restate code mechanically. Describe behaviour and intent as they emerge from the implementation. • Do not smooth over weaknesses. Known limitations and modelling shortcuts must be stated plainly. • Do not speculate about business use, exposure, or controls. If not declared, state the uncertainty explicitly. • Write for a skeptical but reasonable reviewer: someone who understands models and governance but has not seen this code. • Align tone with risk tier: • T1/T2 documents may acknowledge pragmatism and proportionality. • T3 documents must be more formal and explicit about controls. • Avoid checklist-style language (“the model does X, Y, Z”). The document should read as a continuous explanation, not a compliance form. • Ensure traceability: Every material claim must be supported by prior skill outputs or cited evidence. • If the document closes unknowns, do so explicitly as human declarations, not inferred facts.

Post-run Checks

• •Headings and section order match doc_template.md exactly.
• •All placeholders are filled with either substantiated content or Not evidenced.
• •A consolidated unknowns section exists and is complete.
• •Terminology and units are consistent across sections.