Appearance
Core Concepts
This page defines the building blocks you’ll see throughout Modulos and how they connect.
Quickstart5 min
Create your first project and complete one control
From Zero to Audit-Ready30–60 min
End-to-end walkthrough from scoping to exports
Guided Paths
Role- and lifecycle-based workflows
Glossary
Definitions of key terms used across the platform
Concept map
Organization
Peopleusers, roles, permissions
Settingslanguage, currency, organization profile
Shared librariesframeworks, risk taxonomy
ProjectsAI applications or org initiatives
GovernanceFrameworks → Requirements → Controls → Evidence
RiskRisks → Threats → Quantification (monetary) → Treatment decisions
TestingSources → Metrics → Tests → Results
AutomationScout + agents + integrations
Mental model
Frameworks define what’s required. Controls define how you satisfy it. Evidence proves it. Review makes it auditable.
Organization
An organization is your workspace boundary in Modulos. It defines who can access the platform and sets global defaults.
Typically, your organization contains:
- Users and permissions (organization-level and project-level access)
- Organization settings (language and currency defaults)
- Shared libraries (framework library and organization risk taxonomy)
Learn more: Organizations
Users, roles, and permissions
Modulos is designed for cross-functional work. Access is typically defined at two levels:
- Organization-level: configuration and administration
- Project-level: day-to-day work on controls, evidence, risks, and testing
Best practice
Use project roles to limit who can approve status changes. This preserves separation of duties for audit trails.
Learn more: User Management
Projects
A project is the unit of work in Modulos. It typically corresponds to a single AI system (or a defined governance scope).
Projects are commonly created in two forms:
| Project type | When to use | Typical output |
|---|---|---|
| AI application | Govern a specific AI system in its deployment context | Control implementation + evidence, risk register, testing results |
| Organization | Govern organization-wide requirements (policies, vendor posture, global controls) | Organization-level evidence and reports |
Learn more: Projects
Frameworks
A framework represents a regulation, standard, or internal policy structure (for example EU AI Act, ISO 42001, NIST AI RMF). Frameworks are how you scope “what applies” to a project.
In Modulos, frameworks can be mapped so that one control can contribute to multiple frameworks. This reduces duplication and keeps implementation consistent across compliance programs.
Learn more: Frameworks in Modulos
Requirements
Requirements are the "what" of a framework — the high-level obligations that come directly from the source document.
Framework-specific
Requirements represent articles, clauses, or chapters from the original regulation or standard. They preserve the structure and language of the source document for traceability.
Example: The EU AI Act Framework has a Requirement representing Article 10 of the Act, "Data and Data Governance".
Requirements typically:
- map directly to articles, clauses, or chapters in the original framework document
- group related obligations into a single trackable unit
- map to one or more controls that operationalize implementation
- provide traceability for audit evidence
Learn more: Requirements
Controls
Controls are the "how" — the concrete measures you implement to satisfy requirements.
Designed for reuse
Unlike requirements, controls are not tied to a single framework. A well-designed control can satisfy requirements from multiple frameworks simultaneously, reducing duplicated work across compliance programs.
Example: Control "MCF-24 Data Design Choices" maps to relevant Requirements in multiple Frameworks, including the Article 10 Requirement of the EU AI Act.
A control commonly includes:
- Guidance (what “good” looks like and how to implement it)
- Ownership (who is responsible)
- A report/narrative (your explanation of implementation)
- Linked evidence (the supporting artifacts)
- Status and review workflow (for audit-ready approvals)
- Links to risks and tests (to connect implementation to outcomes)
Learn more: Controls
Evidence
Evidence is the proof. It can be a policy, screenshot, export, log sample, contract, test result, or any artifact that supports a control’s implementation.
Evidence should answer:
- What is this artifact?
- Which control(s) does it support?
- What claim does it substantiate (and for which timeframe)?
Learn more: Evidence
Status, readiness, and review
In Modulos, status is concept-specific, and review is the workflow that makes status changes auditable.
- Controls track execution: Not executed → Executed (or Out of scope).
- Requirements track fulfillment: Not fulfilled → Fulfilled (or Out of scope). Requirements typically become ready for review once all linked controls are in a final state; the requirement owner then finalizes fulfillment.
Across both, you’ll also see a review/readiness workflow used to request and approve changes (for audit trails):
In progress
In review
Completed
Out of scopewhen not applicable
Use “Out of scope” sparingly
Treat “out of scope” as a decision that may be challenged. Record the rationale in the control/report so the audit trail is complete.
Learn more: Reviews & Statuses
Risk
Modulos supports risk management at both the organization and project level.
- Organization taxonomy: the shared catalog of categories, risks, and threats your organization uses for consistency.
- Project risks: the risks that apply to a project, broken down into threats for quantification.
Learn more: Risk
Risk quantification
Risk quantification turns qualitative risk statements into monetary impact so you can prioritize treatment and investment.
Why monetary?
5×5 risk matrices are not quantification and are often misleading.
Money is the point because it:
- serves as a universal unit across risk types
- forces abstract harms (reputation, trust, mission delay) into stakeholder-relevant terms
- connects directly to organizational risk appetite, which is ultimately expressed through resource allocation
Learn more: Risk Quantification
Testing
Testing lets you continuously verify key properties of your AI system (or its operational environment) using metrics and rules.
The testing model is:
- Sources connect to systems that provide metrics and context (for example Prometheus and Datadog for pull metrics, Modulos Client for pushed metrics, and GitHub and Azure for project context).
- Metrics are the measurements available from a source.
- Tests define conditions over metrics (thresholds, comparisons, schedules).
- Results are the historical outcomes you can reference in controls and audits.
Learn more: Testing
Connectors vs sources
Sources are project-level service accounts used to power Testing (metrics → tests → results) for that project. Connectors are user-level accounts connected to a user (typically via OAuth) and used to bring external context into Scout.
AI agents and automation
Modulos includes AI agents to accelerate documentation and investigation workflows, with human-in-the-loop controls.
- Scout: conversational assistant grounded in your project context (controls, evidence, requirements).
- Evidence agent: helps summarize and associate evidence.
- Control assessment agent: supports structured control assessments.
Learn more: AI
Reporting and audit readiness
Audit readiness is an outcome of consistent traceability:
- requirements → controls → evidence → approvals → exports
Learn more: Reports & Exports