The mental model that the rest of the docs assume you already have: what a **project** scopes, how **frameworks** like ISO 9001 / 14001 / 27001 are structured inside Regnora, what a **gap analysis** actually produces, how **documents** and evidence relate to controls, and where **agents** fit in. Read this once and the rest of the documentation will move faster.

Five concepts cover almost everything in the product. They nest cleanly: a project holds the frameworks you're working against, the documents you're working from, and the gap analyses you run to compare them. Agents are the reusable AI helpers that sit alongside all of it.

## Projects

A project is how you keep separate compliance efforts isolated from each other — your own ISO 27001 work, a client engagement, an audit you're sharing with an external party. Everything you do in Regnora — uploading documents, enabling frameworks, running gap analyses — happens inside a project, and switching the active project switches every view in the sidebar at once.

Projects come in two flavours. An **internal** project is your organisation's own compliance work — your ISO 27001 ISMS, your quality management system, your environmental management system. An **external** project is an engagement tied to an outside organisation: a client whose system you're assessing, an auditor you're sharing evidence with, a supplier you're reviewing. Every organisation has at least one default internal project; external projects appear when you add the external organisation they belong to.

Projects are also the unit of access. Organisation owners and admins see every project; everyone else only sees the projects they've been explicitly added to. That makes a project a safe place to put work that should stay separated — different clients, different business units, a draft assessment you're not ready to share.

**Manage:** [Projects](https://app.regnora.com/projects)

## Frameworks

A framework is the standard or regulation you're working against — ISO 27001, ISO 9001, GDPR — represented in Regnora as its full set of requirements so you can evidence each one and run gap analyses against it. Regnora maintains the catalogue centrally; you don't import the standard text or keep it up to date yourself.

To bring a framework into a project, you **enable** it. That creates a framework adoption — your project's own instance of that framework, against which you'll evidence controls and run gap analyses. The same framework can be enabled independently in multiple projects, so an ISO 27001 adoption for your own ISMS doesn't get tangled up with an ISO 27001 adoption you're running for a client.

Inside a framework, requirements are organised hierarchically — chapters, sections, clauses, controls, articles, annexes — matching how the published standard is structured. The ones the standard frames as actual obligations are flagged as such, and that's what gap analyses assess against. You can layer multiple frameworks on a single project; overlapping requirements aren't deduplicated, but they all show up against the same evidence base.

**Manage:** [Library frameworks](https://app.regnora.com/library/frameworks) · [Enabled in this project](https://app.regnora.com/frameworks)

## Gap analyses

A gap analysis is how you find out where your current evidence does and doesn't satisfy an enabled framework. Regnora's AI walks through every requirement in the framework, checks your project's documents for evidence, and gives each one a verdict — so instead of doing this manually for hundreds of clauses, you review and decide on the results.

A gap analysis moves through four stages, visible as tabs on every analysis: **Plan** (you scope what to assess and the AI proposes a plan you approve), **Analyze** (the AI works through each requirement check using your project's documents as evidence), **Review** (you go through the assessments, mark them attested or flag them for rework), and **Act** (you turn the remaining gaps into follow-up). Each requirement assessed gets one of three verdicts in the UI: **Pass**, **Gap**, or **N/A**.

A few behaviours worth knowing up front. A gap analysis can have multiple **runs** — re-running it produces a fresh set of assessments without losing the history of the previous run, and exactly one run is the "active" one at any time. Runs can be scoped to a subset of documents, or left unscoped to search every document in the project. And every analysis has a status: `draft`, `active`, or `closed` — closing one and starting a new one is the normal way to mark a cycle finished.

**Manage:** [Gap analyses](https://app.regnora.com/gap-analyses)

## Documents

Documents are your evidence — policies, procedures, records, audit reports, meeting minutes, anything you'd hand to an auditor. When you upload a document, Regnora extracts and indexes its text so the AI can search by meaning, not just filename, when it runs assessments or answers questions about your evidence.

Documents are versioned. Re-uploading a policy produces a new version of the same logical document rather than a duplicate, and only one version is "current" at a time — older versions stay available for audit trail. You can organise documents into directories, and a document can be in one of a few states: `staged` (uploaded but not yet committed — typical when an agent has proposed a change for you to approve), `draft`, `active`, or `archived`.

Documents are scoped to their project, which matters more than it sounds. A gap analysis assesses against the documents in its own project; an agent reading evidence only sees the project it's running in. There is no cross-project document search.

**Manage:** [Documentation](https://app.regnora.com/documentation)

## Agents

An agent is a reusable AI assistant configured once and pointed at compliance work over and over. Use them for recurring tasks specific to how your team works — a particular review checklist, a vendor-questionnaire-to-document flow, anything you don't want to re-explain every time. Regnora ships built-in agents for the core flows (gap analysis, document revision); custom agents are the ones you build yourself.

A custom agent is defined by a name, a description, and a set of markdown **instructions** that become its system prompt — there's no prompt engineering toolkit and no code. When you create one you also pick its **capabilities** (today: reading your documents, reading enabled frameworks, researching the public web) and its **deliveries** — the kinds of output it's allowed to produce, which is what lets it propose document changes for a human to review rather than acting silently.

Agents are versioned with a draft / active lifecycle, so you can iterate on instructions without disturbing the version that's wired up to real work. They're typically composed into workflows — that's how an agent moves from "a thing I can test" to "a thing that runs when a trigger fires" — but you can also run an agent directly against a chosen input to see what it would do.

**Manage:** [Agents](https://app.regnora.com/library/agents)