Governance tools that run in your browser.
Small, single-purpose tools built from the Body of Knowledge. Each one runs entirely in this page, keeps your answers in the link you copy and exports its result in an open format you can file, diff and re-import.
Indicative, not legal advice and not a conformity claim. Nothing you enter leaves your browser.
Prefer to ask in your AI assistant? Connect the MCP server and Claude, or any MCP client, answers from the same registers with the source page of every answer.
The tools
11 tools are live. Each one names the chapter it is built from, what you enter and what you get back.
- Maturity self-check Read your governance function layer by layer against the observable criteria of the maturity model: the ragged profile, the floor it sets and the one move that raises it. For: AI governance engineers, Heads of AI governance, Platform and security leads. You enter: For each of the five stack layers, the highest observable criterion met today. You get: Per-layer profile, drawn; floor and the single next move, with its pattern; jSON profile you can re-import; markdown report; sVG and PNG image; before-and-after comparison of two profiles. Open the tool
- Obligations and deadlines planner Pick your roles in the EU AI Act value chain and what the system is: the register rows that bind you, with the artefact that evidences each, its layer, the date it applies and its status. For: AI governance engineers, Compliance and legal leads, Product and platform owners. You enter: Your roles: provider, deployer, importer, distributor, authorised representative, GPAI model provider (with or without systemic risk); The system classes: Annex III, Annex I, Article 50; An optional reference date. You get: The obligations that bind you, with artefact, layer, date, status and patterns; timeline of the dates, drawn; checklist in Markdown; open-data JSON and a CSV; calendar file (.ics), one all-day event per date. Open the tool
- EU AI Act risk classification checker Walk an AI system or model through the EU AI Act as amended by the Digital Omnibus: indicative roles and risk classes with the reason behind each answer, and a classification decision record to file. For: AI governance engineers, Product and platform owners at intake, Privacy and legal partners reviewing a classification. You enter: The system or model and its intended purpose; Up to 20 questions on definition, reach, role, prohibited practices, high-risk, transparency and GPAI; Reviewer, date, legal-review state and re-review triggers. You get: Indicative scope, EU roles and risk classes, each with its reason and article; the reason behind every answer; classification decision record in JSON and YAML, with its JSON Schema; markdown report; a link that opens the obligations planner with these roles and classes. Open the tool
- Policy Card builder Turn one governance rule into a Policy Card for people and machines, an OPA/Rego module with unit tests, a Cedar stub and the CI hook that runs it. For: AI governance engineers, Platform and security leads, Policy owners. You enter: A rule from six templates, or your own condition on one input field; Owner, scope, review date and the obligation ids the rule answers. You get: Policy Card in Markdown, YAML and JSON, valid against the policy-card schema; oPA/Rego module with a verdict rule and unit tests; cedar stub with tests; example input and a GitHub Actions CI hook. Open the tool
- AI register entry builder Build AI system and agent register entries that validate against the published schemas, keep a register in the browser and map each field to the UK ATRS, a Canada AIA, the EU database, a model card and an ISO/IEC 42001 SoA. For: AI governance engineers, System and agent owners, Privacy and transparency leads. You enter: One AI system or agent: identity, owner, scope, expiry, classification; Optionally, the public-record fields; Or a register file (JSON or CSV). You get: Entry checked against its schema, problems linked to the fields; register in JSON and CSV (re-importable); markdown public summary; field crosswalk in CSV and Markdown. Open the tool
- Impact assessment builder Write a FRIA, an AI system impact assessment or an AI addendum to a DPIA as one record: the elements each instrument asks for, every risk linked to the measure and pattern that mitigate it, and the triggers that reopen it. For: Deployers of high-risk systems, AI governance engineers, Privacy offices and DPOs. You enter: The assessment type (FRIA, AIIA or DPIA addendum); The elements of that instrument; Risks, measures, outcome, approvals and re-open triggers. You get: Record checked against the impact-assessment schema; element coverage and a risk-to-measure matrix; jSON, YAML and Markdown exports. Open the tool
- Model card builder Write a model or system card once and export it as a Hugging Face style card and a CycloneDX 1.7 ML-BOM component, with a checklist of what it covers under Annex IV, Art. 13, Art. 53, ISO/IEC 42001 and the NIST AI RMF. For: Model owners and ML engineers, Model validation, AI governance engineers. You enter: Model details, uses, data, evaluation, limits and oversight; Whether it is part of a high-risk system or a GPAI model. You get: Record checked against the model-card schema; obligation coverage checklist; hugging Face style Markdown with YAML front matter; cycloneDX 1.7 ML-BOM JSON. Open the tool
- Vendor due-diligence request Build a tiered, evidence-first due-diligence request for an AI vendor or model: the artefacts to ask for, cross-referenced to crosswalk topics and CSA AICM controls, and the contract clauses to check. For: AI governance engineers, Procurement and vendor risk, Security and privacy leads. You enter: Supply type, use tier, data sensitivity, autonomy and tool access; Jurisdictions and sector; Optionally, the answers received. You get: Risk tier with its reasons; 20 to 38 artefact requests; contract-clause checklist; markdown request and CSV; response record (JSON, vendor-due-diligence-response.v1). Open the tool
- Incident clock From the awareness time, your role, the system tier and the facts: the incident class, who reports to whom and every deadline as a calendar date, as chapter 17 states the clocks. For: Incident commanders, AI governance engineers, DPOs and legal. You enter: Awareness time, and classification or causal-link times if known; Your roles and the system tier; What happened, read as severely as the evidence allows. You get: Incident class and severity; clocks per regime with calendar dates; calendar reminders (.ics); incident record skeleton (JSON, incident-record.v1); markdown summary. Open the tool
- Agent control profile Describe one agent and get the minimum control set chapter 23 asks for at its autonomy level, the controls its tools, memory and identity add, an agent register entry and a checklist. For: AI governance engineers, Platform and security engineers, Agent owners. You enter: Autonomy level and approval points; Tools and MCP servers with operation class and scope; Data classes, memory, external actions and identity model. You get: Minimum control set with patterns; gaps to close; agent register entry (JSON, agent-register-entry.v1); checklist (Markdown and CSV). Open the tool
- Fairness metric chooser Walk the questions chapter 16 says decide the fairness metric (ground truth, costlier error, allocation or quality of service, legal frame) and get the metric families to use, with their caveats. For: Data scientists and ML engineers, AI governance engineers, Legal and compliance. You enter: Harm type and ground truth; Costlier error; Legal frame and access to the protected attribute. You get: Primary metric families and secondary checks; warnings and legal notes, linked to the chapter; markdown and JSON record of the choice. Open the tool
How every tool works
- In the page, nowhere else. No account and no upload: the tools make no network request with what you enter. Files you import are read by your browser.
- State in the link. Your answers travel in the part of the address after
#, the fragment, which the browser handles itself and does not send when it requests the page [4]. Copy the link to share a result or to come back to it. - Open formats. JSON [1], CSV
[2], iCalendar [3],
Markdown, SVG and PNG. A JSON export carries a
kindand aversion, so the tool can read it back; on import it recomputes every derived value rather than trusting the file. - Readable without JavaScript. Every tool renders its questions and its guide on the server, so with scripts off the page still works as a worksheet. Forms use labelled groups, errors are announced and focus moves to the result.
- Indicative. A result is a reading for planning, not legal advice, not an audit and not a conformity claim. No tool gives a single score, a badge or a certificate.
Adding a tool
Each tool is one entry in the registry (src/data/toolkit.ts), one page wrapped in the shared ToolShell component and one client module that imports the shared helpers (public/toolkit/lib.js): link state, safe storage, downloads, the clipboard and image export. No inline scripts and no third-party code, so the site's content security policy holds unchanged.
Sources
- [1] RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format (STD 90; JSON exchanged between systems outside a closed ecosystem MUST be UTF-8). IETF. 2017-12. https://www.rfc-editor.org/rfc/rfc8259 (verified: primary)
- [2] RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files (Informational; CRLF records, fields with commas, double quotes or line breaks enclosed in double quotes, inner quotes doubled; registers text/csv). IETF. 2005-10. https://www.rfc-editor.org/rfc/rfc4180 (verified: primary)
- [3] RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard; CRLF content lines folded at 75 octets, TEXT escaping, PRODID and VERSION per calendar, a globally unique UID and DTSTAMP per event, DATE values for all-day events, UTC date-times and display alarms for timed ones). IETF. 2009-09. https://www.rfc-editor.org/rfc/rfc5545 (verified: primary)
- [4] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax (STD 66), section 3.5: the fragment is separated from the rest of the URI before dereference and handled by the user agent alone. IETF. 2005-01. https://www.rfc-editor.org/rfc/rfc3986#section-3.5 (verified: primary)