Module access

Module access controls which of the platform’s modules a project uses, and the default access each role has to them. Not every project needs every module, and this is where you shape a project to fit the work it’s actually for.

Enabling modules per project

A project has a set of enabled modules — Requirements, Architecture, Tests, Risk, SBOM, and the rest — and you turn on the ones the project needs. A disabled module simply doesn’t appear for that project, keeping the workspace focused: a pure requirements-and-test project isn’t cluttered with architecture or SBOM it doesn’t use. This is the project-setup counterpart to the user-facing view in Module access.

Default access by role

For the modules a project does use, you set a default access per role through its module access configuration — so a role can have full access to one module and read-only to another, matching how different people actually work with each area. These defaults combine with the Project permissions overrides to determine what any given person can do in any given module.

Shaping the project

Between enabling the right modules and setting sensible per-role defaults, module access defines a project’s working surface. Configured well, each project presents exactly the capabilities its team needs, governed by access that matches their responsibilities — the last piece of standing up a project alongside its permissions and compliance frameworks.