AIGovernrAIGovernrDocs
Ctrl K
Open workspace
Getting started
AIGovernr documentationQuickstartNavigating the appCore conceptsHow everything connects
Workspaces
CompaniesProjectsTeams & responsibilitiesDashboards & assignments
Account & administration
Plans & billingAccess control & rolesAccount securityNotifications
AI systems
AI SystemsRegister an AI SystemAI System classificationAI System Governance planGovernance plan vs PlaybookSystem documentation & testing recordsVendors & dependenciesShadow AI & asset graph
Obligations
Frameworks & obligationsRequirements & tasksGovernance knowledgeRegulatory updates
Assurance
Assure overviewControlsAssurance methodsTechnical evaluationsDPIAEvidence managementISO/IEC 42001 readinessGovernance maturity
Issues & actions
Findings vs risksCorrective actions
Decisions
ApprovalsApproval PoliciesDecision LedgerExceptions & reassessment
Continuous governance
MonitoringIncidentsAgent & MCP governance
Reusable governance
AI governance policiesPolicy templatesPlaybooks
Reporting
Reports, certificates & audit export
Client collaboration
Client portal & engagement
Guides
Run a client governance engagementOperate an AI governance programmeFramework implementation guides
Discovery tools
Website Compliance Scanner
AI assistance
AI Assistant
Developers
Integrations & APIs
Help
Troubleshooting & FAQ
DocsGetting started
Getting started

Core concepts

The terms used throughout AIGovernr, what each record represents, and how they differ from one another.

Context and the governed object

  • Company: your organisation. It holds members, roles, the subscription and every project. The app labels it Organisation in settings.
  • Project: a governance workspace, usually one client engagement or one internal programme. It can contain several AI Systems.
  • AI System: a business use of AI, such as a CV-screening tool or a support chatbot. Governance work ultimately traces back to it.
  • Governance plan: the per-system view of which frameworks, workspaces, controls and open work apply, and why.

Obligations and assurance

  • Framework: an authoritative source of expectations, such as the EU AI Act or ISO/IEC 42001.
  • Requirement: something a framework expects. A Task is work assigned to a person to meet it.
  • Control: a recurring, practical measure that meets requirements or reduces risk.
  • Framework assessment: a structured self-assessment against a framework. A Control Test checks one control. A Technical Evaluation measures system behaviour.
  • Evidence: proof that supports a claim, with an owner, version history and a review status. An upload alone is not evidence until it has been reviewed.

Issues, authority and continuity

  • Finding: an observed deficiency. Risk: a possible harmful outcome, scored by likelihood and impact.
  • Corrective action: the remediation plan for a Finding. It closes only after its fix has been verified.
  • Approval Policy: the rules a decision request must satisfy. Approval request: one request for authority. Decision: the lasting, accountable outcome recorded in the Decision Ledger.
  • Exception: a time-limited, owned waiver with a compensating control.
  • Monitoring: runtime signals and thresholds that show whether a decision is still valid. Reassessment: the work reopened when it might not be.
  • Playbook: a reusable sequence of governance steps for a known scenario.

Last reviewed 2 October 2026

Next stepHow everything connectsThe lifecycle turns system facts into obligations, obligations into tested controls and evidence, and evidence into an accountable decision that is monitored over time.
Navigating the appHow everything connects
On this page
Context and the governed objectObligations and assuranceIssues, authority and continuity
Capability status

Check current availability and limitations before relying on a feature.

View matrix