Compliance frameworks

This is where the regulatory frameworks your organization develops under are configured, and where the data-integrity controls behind them are set. It’s the admin foundation for everything in the Compliance section.

The configure-once-inherit-per-project model is what keeps a multi-project organization coherent under regulation. If each team interpreted a standard for itself, you’d have as many versions of “compliant with ISO 14971” as you have projects — an untenable position in an audit. Enabling a framework centrally and attaching it to the projects it governs means every one of those projects is held to the same interpretation, so compliance is an organizational property rather than a per-team improvisation.

Regulatory standards

You enable the regulatory standards that apply to your work — the FDA, ISO, IEC, and EU frameworks described in Frameworks — at the organization level, then attach them to the projects they govern. Configuring each standard once and inheriting it per project keeps requirements consistent: every project that adopts a framework is held to the same interpretation of it, rather than each team deciding for itself.

Data integrity

Alongside the frameworks, you configure data-integrity controls — including chain hashing that makes the record tamper-evident, supporting the ALCOA+ principles a regulator expects. These settings underpin the trustworthiness of the audit trail and signatures: they’re what let the platform demonstrate that records haven’t been altered.

The foundation for compliance

Because frameworks and integrity controls are set here and applied everywhere, this area shapes the controlled states, signatures, and checks throughout the product. The user-facing meaning of all this — what the frameworks require and how readiness is proven — is covered in the Compliance section; verification of it is configured in Compliance verification.