Operating the Platform: A Leverage Guide

1. What this platform is, in one line

The platform is the operating system for our AI Security & Safety Center of Excellence: a vetted skill substrate, the AI Controls Matrix (AICM) control spine that organises it, and a deployment method that turns it into measured capability — one function at a time. Three surfaces carry it: Library (the substrate), Engage (the deployment plan), and Insights (the strategy and the proof).

2. The four moves

Everything here serves one loop. The platform’s value is the loop, not the catalogue.

3. The asset map

Three surfaces, three jobs. Reach for the one that matches your question.

4. Navigate by what you need: the three lenses

The Library offers three lenses over the same substrate. The data truth never moves: every skill belongs to exactly one control domain. The lenses are ways of reading it — never second partitions.

By domain: the AICM control spine

Start here. Every skill maps to exactly one control domain; this is how we reason about coverage, ownership, and gaps. Browse a domain to see everything we hold for it.

By framework: the obligation you answer to

Switch to this lens when a regulation or standard is driving the work — the General Data Protection Regulation (GDPR), EU AI Act, National Institute of Standards and Technology (NIST) AI Risk Management Framework, ISO/IEC 42001, MITRE ATLAS, the OWASP LLM Top 10. It surfaces every skill that maps to that obligation, regardless of domain.

By instrument: verify, don’t just implement

Use this lens when you need to test a control, not just build it: the tools, in three lanes — testers (probe a skill or target), corpora (fixed input sets that fix a baseline), and controls (mitigations a tester grades).

5. The skill as the unit of work

A skill here is not a runbook. It is a governed object with five attributes. Read them in order — and to leverage a skill, work down the same list against our own environment.

Autonomy is a setting, not a guess — climb the trust ladder one rung at a time: human-in-the-loop (AI proposes, a person approves), then human-on-the-loop (AI acts, a person monitors), then bounded autonomy (hard limits, mandatory rollback, full audit). Reversibility is the precondition for autonomy. The full mechanics live on the deployment plan.

6. Per-role quick-start

Three moves each — the fastest path to value by who you are.

CISO / sponsor

• —Read where we stand — Engage, the maturity path (Initial → Efficient).
• —Pick the first function to pilot — sharpest before/after wins.
• —Hold us to the honesty rules: a measured number from our own pilot, never a borrowed one.

CoE lead

• —Anchor on the AICM spine — Library, by domain — as the single control taxonomy.
• —Classify each AI system by our role in the supply chain (are we the customer, the application provider, or the model provider?).
• —Sequence the rollout — assess → pilot → scale — and gate each step on coverage and reversibility.

SOC lead

• —Find the triage, enrichment, and hunt skills — Library, by domain (SEF, LOG, TVM).
• —Baseline the first workflow honestly — current triage time, MTTR, false-positive rate.
• —Start at human-in-the-loop; expand autonomy only where the action is cleanly reversible.

Security engineer

• —Browse by domain for the control you own; read the skill record.
• —Fit the encoded judgment to our stack and wire the execution to our tools.
• —Map our coverage against the spine — a control with no skill is a gap to close.

Privacy / legal

• —Browse by framework — GDPR, EU AI Act — for the obligation you carry.
• —Pull the skills that produce the evidence an examiner will ask for.
• —Co-own the autonomy limits wherever regulated data is in scope.

Analyst

• —Let the agent load the relevant skill rather than hunting for it.
• —Own the exceptions and the novel — the work that resists proceduralisation.
• —Feed friction back so the skill improves from real incidents.

7. The leverage checklist

The moves that extract maximum value — work them in order.

• —Anchor on the AICM control spine — one master taxonomy, not a scatter of frameworks.
• —Classify each AI system by our supply-chain role — it decides which controls we own.
• —Baseline before, honestly — triage time, MTTR, false-positive rate, measured not assumed.
• —Treat each skill as a governed object — encode the judgment, set the autonomy boundary, record the control.
• —Gate autonomy on reversibility — never move past human-in-the-loop until rollback is engineered.
• —Measure before and after — report the real number, including the early dip.
• —Map coverage to the spine — a skill with no control tag is either out of scope or a coverage hole.

8. The categorisation reference

Learn these three axes — not an authoring sub-category list. The first is the partition (the data truth); the other two are lenses over it.

The control spine (partition)

The AICM control domains. Every skill belongs to exactly one:

The framework lens (many-to-many)

The regulations and standards a skill maps to — privacy law (GDPR, HIPAA, CCPA, …) and security/AI frameworks (NIST AI RMF, MITRE ATLAS, ATT&CK, D3FEND). One skill can carry several.

The instrument lanes

The tools, kept structurally distinct: testers, corpora, and controls. A control is never graded by itself — that separation is the integrity check.

9. The honesty rules

What we do not do — straight from the doctrine that keeps this defensible.

• —Never headline a count. Skill count, domain count, coverage percentage are supporting context — never the value claim. The value is fit and measured impact in one function.
• —Never present a modelled number as measured. Illustrative figures are labelled illustrative; proof is a per-pilot before/after on our own data.
• —One primary domain per skill. Cross-cutting associations are display-only context, never a second partition.
• —Borrowed numbers are for the “why now.” Our numbers are for “it works here.” Keep the two visibly apart.

Next: the full build sequence in the CoE Modular Build Playbook, or stand a function up with the deployment plan.