-
Notifications
You must be signed in to change notification settings - Fork 2
SDK
For whoever changes Cairn's code. Each page walks one extension point from end to end, in the order you actually touch the files, and finishes with what the change has to prove before it ships.
| Page | Extension point |
|---|---|
| Dashboard widget | Add a tile to the home dashboard |
| Entity | Add a domain entity, end to end : model, lifecycle, interface, API, MCP tool, seed, spec |
| Lifecycle | Declare or change a governance lifecycle |
| REST endpoint | Expose a resource on /api/v1/
|
| MCP tool | Expose a capability to assistants and scripts |
| Report | Generate a PDF, DOCX, PPTX or XLSX deliverable |
| Assistant provider | Plug a different LLM backend into Ask Cairn |
| Interface conventions | The patterns a new screen is expected to follow |
Almost nothing in Cairn is wired by hand. A widget, a lifecycle, a permission, an MCP tool and a URL route are all declared in a registry and discovered from it. That is why adding one is short, and why forgetting to declare one is the failure mode rather than forgetting to call it.
It is also why the reference can be generated : the same registries the application reads at runtime are what the documentation reads at build time. A registry entry you add shows up in the documentation without you writing a line of it, and CI fails until you regenerate.
They come up on every page, so they are stated once here.
Every feature gets an MCP tool and a REST endpoint. Not eventually. A capability that exists only in the interface is one that scripts, integrations and assistants cannot reach, and it quietly makes the API a partial view of the platform.
Every user-facing string is translated. Wrapped with _() or {% trans %},
with a French entry added in the same change. See
internationalisation.
Governance is never bypassed. State changes go through a lifecycle transition, permissions are checked with the declared codename, scope filtering is applied, and history is left intact. A shortcut here is not a shortcut, it is an audit finding.
Read the architecture for the cross-cutting patterns every module inherits, and get the application running with the demo dataset (installation) : most of these pages assume you can see what you changed.
Built from docs/ at v0.36.0. Edits made here are overwritten by the next release : open a pull request against the source instead.
- Administration
- Ask Cairn
- Assets and suppliers
- Compliance
- The dashboard
- Finding your way
- Getting started
- Incidents
- How records move
- Organisational context
- Reports and management review
- Risks
- Trust Center
- Architecture
- Configuration
- Contributing
- The documentation system
- Installation
- Internationalisation
- Operations
- Release process
- Security
- Testing
- Adding an assistant provider
- Adding a dashboard widget
- Adding a domain entity
- Declaring a lifecycle
- Adding an MCP tool
- Adding a REST endpoint
- Adding a report
- Interface conventions
- Dashboard widgets
- Lifecycles
- MCP tools
- MCP tool parameters : Assets
- MCP tool parameters : Compliance
- MCP tool parameters : Governance and context
- MCP tool parameters : General
- MCP tool parameters : Incidents
- MCP tool parameters : Reports and management review
- MCP tool parameters : Risks
- MCP tool parameters : System and administration
- MCP tool parameters : Trust Center
- Management commands
- Models
- Permissions
- REST endpoints
- Environment variables
- MCP server
- REST API
- Assistant module (Ask Cairn)
- Module 0: User Management and Access Control
- Module 1: Context and Organization
- Module 2: Asset Management
- Module 3: Compliance
- Module 4: Risk Management
- Module 4 bis - EBIOS Risk Manager
- Module 5 : Trust Center
- Module 6 : Security Incident Management
- Management review : ISO 27001:2022 compliance (clause 9.3)