{
  "schema": "yarn-pack/2",
  "id": "framework-support",
  "version": "0.1.0",
  "name": "The ISO/IEC 42000 family (framework self-assessment)",
  "engagement": "AISG — framework self-assessment: workshop prep, workshop, or diagnostic strand",
  "intro": "A guided conversation against The ISO/IEC 42000 family, not a form. Answer in your own words and name the document or record that shows it if you can. About 16 minutes. The SC 42 standards around ISO/IEC 42001: does the organisation use each, or need it. Not 42001, 23894 or 5259 in depth (own rubrics), and not agentic AI (asset 12).",
  "tone_default": "professional",
  "prefill_fields": {
    "department": [
      "Executive",
      "Finance",
      "Operations",
      "Customer / Sales",
      "Technology / IT",
      "Data & Analytics",
      "People & Culture",
      "Risk & Compliance",
      "Marketing",
      "Product"
    ]
  },
  "scales": [
    {
      "id": "maturity5",
      "name": "Maturity (distilled model)",
      "levels": [
        {
          "value": 1,
          "label": "Does not exist",
          "gloss": "No capability. Absent, or purely ad hoc / accidental."
        },
        {
          "value": 2,
          "label": "Partially exists",
          "gloss": "Emerging and inconsistent. Pockets of activity, not joined up."
        },
        {
          "value": 3,
          "label": "Fully exists",
          "gloss": "Defined, documented and operating across the organisation."
        },
        {
          "value": 4,
          "label": "Fully exists & optimised",
          "gloss": "Measured, refined and improving against targets."
        },
        {
          "value": 5,
          "label": "Fully exists & adaptive",
          "gloss": "Continuously self-adjusting; a source of advantage."
        }
      ],
      "signals": {
        "1": [
          "no ",
          "not ",
          "none",
          "never",
          "don't",
          "do not",
          "nothing",
          "absent",
          "unaware",
          "haven't",
          "ad hoc",
          "ad-hoc",
          "nonexistent",
          "no idea",
          "not really"
        ],
        "2": [
          "some ",
          "starting",
          "beginning",
          "emerging",
          "pilot",
          "trial",
          "informal",
          "inconsistent",
          "pockets",
          "a bit",
          "occasionally",
          "early",
          "experiment",
          "trying",
          "patchy"
        ],
        "3": [
          "documented",
          "defined",
          "standard",
          "standardised",
          "established",
          "policy",
          "framework",
          "process",
          "consistent",
          "across the",
          "in place",
          "formal",
          "governed",
          "rolled out"
        ],
        "4": [
          "measured",
          "metrics",
          "optimis",
          "improving",
          "kpi",
          "monitored",
          "reviewed",
          "refined",
          "benchmarked",
          "targets",
          "tracked",
          "mature",
          "regularly review"
        ],
        "5": [
          "continuous",
          "adaptive",
          "self-",
          "automated end",
          "best in class",
          "best-in-class",
          "competitive advantage",
          "industry leading",
          "always",
          "real-time monitoring",
          "feedback loop"
        ]
      }
    }
  ],
  "categories": [
    {
      "id": "published",
      "name": "Published supporting standards",
      "order": 1,
      "target_default": 3
    },
    {
      "id": "developing",
      "name": "In development (verify status)",
      "order": 2,
      "target_default": 3
    }
  ],
  "audiences": [
    {
      "id": "lead",
      "name": "Governance / risk lead",
      "desc": "Owns the policy, the register or the risk framework",
      "deep_dive_sections": []
    },
    {
      "id": "owner",
      "name": "System or use-case owner",
      "desc": "Runs an AI system or use case day to day",
      "deep_dive_sections": []
    },
    {
      "id": "exec",
      "name": "Executive / sponsor",
      "desc": "Accountable for the outcome, not the mechanics",
      "deep_dive_sections": []
    }
  ],
  "sections": [
    {
      "id": "core",
      "title": "42000 elements",
      "blurb": "Everyone answers these. The AIMS owner or governance lead, whoever is scoping certification, the data lead, and an engineer who can speak to the ML reference model and the data life cycle.",
      "optional": false,
      "questions": [
        {
          "id": "42000-22989",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 22989 AI concepts and terminology",
          "text": "When your policy says ‘AI system’ or ‘model’, where is that defined, and does the definition match the one in your contracts and registers?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "AI terms in policy, contracts and registers are undefined or defined differently by each document; no glossary cites 22989.",
            "3": "One AI glossary exists, cites 22989 for its definitions, and the AI policy, AUG and registers use those terms consistently.",
            "5": "The glossary owner tracks the 22989 revision (including agent terminology) and re-issues affected documents when the definitions change."
          },
          "help": "Evidence that would show it: AI glossary or definitions section citing ISO/IEC 22989; AI policy or AUG with a definitions clause; Use case or vendor register with a defined term set.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-42005",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 42005 AI system impact assessment",
          "text": "Before a new AI system goes live, what do you write down about who it could affect and how, and is that the same document every time?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No impact assessment is run per AI system, or each one is written from scratch with no shared template or method.",
            "3": "A repeatable impact-assessment template exists, follows 42005, and a completed assessment is on file for each in-scope AI system.",
            "5": "Assessments are re-run on a trigger (material change, incident, new use) and the template is revised from what those re-runs find."
          },
          "help": "Evidence that would show it: Impact-assessment template referencing ISO/IEC 42005; Completed impact assessments per AI system; Intake or stage-gate record showing the assessment as a gate; Re-assessment trigger list or review log.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-42006",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 42006 AIMS audit and cert bodies",
          "text": "Is 42001 certification something you are aiming for, and if so, who would audit you, against what boundary, and when?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "Certification is not a stated goal, or it is a goal with no scoping of the audit body, the AIMS boundary or the audit calendar.",
            "3": "A certification-readiness scope exists naming the AIMS boundary and a 42006-conformant body, and audits sit on the assurance schedule.",
            "5": "Readiness gaps found in internal audit feed the assurance schedule automatically and the certification scope is reviewed each cycle."
          },
          "help": "Evidence that would show it: Certification-readiness scoping note citing ISO/IEC 42006; Assurance schedule with 42001 audit entries; Correspondence or proposal from a certification body.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-23053",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 23053 framework for ML-based AI systems",
          "text": "If I asked two of your engineers to describe how an ML system is put together, would they draw the same picture, and is that picture written down anywhere?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "ML systems are documented ad hoc, or not at all; no common reference model for describing components and pipelines.",
            "3": "Model cards or system documentation follow one reference model, citing 23053 or an equivalent, for every in-scope ML system.",
            "5": "Documentation is generated from the pipeline itself and updated on each deployment, with the reference model reviewed as systems change."
          },
          "help": "Evidence that would show it: Model card or system documentation template citing ISO/IEC 23053; Lifecycle SOP naming the reference model; Engineering standards or architecture guide for ML systems.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-8183",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 8183 AI data life cycle framework",
          "text": "For the data behind one of your AI systems, can you tell me where it came from, who owns it now, when it is refreshed, and what happens to it when the system is retired?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No defined data life cycle for AI; data sourcing, retention and disposal for models and corpora are decided case by case, if at all.",
            "3": "A documented AI data life cycle, aligned to 8183, names stages and owners, and each corpus or dataset register row shows its stage.",
            "5": "Stage transitions (refresh, withdrawal, retirement) trigger downstream actions automatically and the life cycle is revised from incidents."
          },
          "help": "Evidence that would show it: AI data life cycle procedure citing ISO/IEC 8183; Corpus or dataset register with stage and owner columns; Decommissioning checklist covering data handling.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-5259",
          "type": "scored_text",
          "category": "published",
          "name": "ISO/IEC 5259 data quality for ML",
          "text": "Before data goes into training or retrieval, what do you check about it, who signs off, and where is that recorded?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No data-quality measures for ML data; quality is assumed from the source system or not considered.",
            "3": "Data-quality requirements and measures for ML data are documented against 5259, and results are recorded per dataset before use.",
            "5": "Quality measures run continuously on live data with thresholds that block or flag use, and the measures are tuned from model outcomes."
          },
          "help": "Evidence that would show it: Data-quality requirements for ML datasets citing ISO/IEC 5259; Data-quality results recorded per dataset or corpus; Sensitivity or curation rules applied before indexing.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-42105",
          "type": "scored_text",
          "category": "developing",
          "name": "prEN ISO/IEC 42105 human oversight",
          "text": "For each AI system, who can step in, at what point, and how was that decided? Is anyone watching the draft oversight standard?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "No documented human oversight model; whether a human is in, on or out of the loop is not decided or recorded per AI system.",
            "3": "A human oversight model is documented per AI system with the rationale, and the owner is tracking 42105 for alignment when published.",
            "5": "Oversight settings are reviewed on incidents and material change, and the model is updated as 42105 moves through its stages."
          },
          "help": "Evidence that would show it: Human oversight model per use case with rationale; Standards watch list naming prEN ISO/IEC 42105; Review log showing oversight settings revisited.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        },
        {
          "id": "42000-42102",
          "type": "scored_text",
          "category": "developing",
          "name": "prEN ISO/IEC 42102 AI capability taxonomy",
          "text": "If I asked what kinds of things your AI systems can do, could you answer from a register, and does that answer change what approvals they need?",
          "scale": "maturity5",
          "scored": true,
          "star": false,
          "rubric": {
            "1": "AI systems are not classified by capability; the use case register and tooling list, if they exist, carry no capability field.",
            "3": "The use case register and approved tooling list carry a capability classification, and the owner is tracking 42102 for the mapping.",
            "5": "Capability classes drive risk tiering and approvals, and the taxonomy is re-mapped as 42102 changes stage."
          },
          "help": "Evidence that would show it: Master use case register with a capability field; Approved tooling and model list with capability classes; Standards watch list naming prEN ISO/IEC 42102.",
          "adaptive": {
            "allow_probe": true,
            "allow_skip": false,
            "max_probes": 1
          },
          "ai_drafted": false
        }
      ]
    }
  ],
  "grids": {},
  "outputs": [
    "Level per element and per category, gated",
    "Contested-element view (spread of 2 or more)",
    "Coverage of evidence: confirmed, stated, inferred",
    "Where to start, foundations first",
    "Printable client report"
  ],
  "report_defaults": [
    "rpt-maturity-standard"
  ],
  "playbook": {
    "sequence": [
      "published",
      "developing"
    ],
    "sequence_note": "Cite the published standards; do not build explainers for them. Watch the two drafts and 42005, the one to promote if impact assessment becomes a recurring service.",
    "actions": {
      "published": {
        "to_3": [
          "Adopt 22989 as the definitions source for policy, AUG and registers",
          "Build one impact-assessment template on 42005 and run it per system",
          "Scope certification readiness against a 42006-conformant body",
          "Align data life cycle and data quality documents to 8183 and 5259"
        ],
        "to_5": [
          "Trigger re-assessment and re-issue on change, incident and revision",
          "Feed internal audit findings straight into the assurance schedule"
        ]
      },
      "developing": {
        "to_3": [
          "Document human oversight and capability per system now",
          "Add 42105 and 42102 to a standards watch list with an owner"
        ],
        "to_5": [
          "Review oversight and capability settings as each draft changes stage"
        ]
      }
    }
  }
}