Compliance as a system of systems

Compliance lives in many systems

Beyond documents and the QMS, much of the information that shapes a company's compliance lives in other systems, and compliance work has to stay aligned with all of them. Each of those systems was built for its own purpose, and none of them for monitoring or running compliance:

• GitHub and GitLab let developers write, review and release code together.
• Jira tracks requirements, issues and the work done on them.
• Xray and other test-management tools hold test cases and record test runs.
• Excel holds traceability matrices, risk analyses and supplier lists.
• Confluence and SharePoint store documents and team knowledge.
• ERP and PLM systems hold suppliers, parts, product structures and change orders.
• Quality management systems store controlled documents and are adding workflows on top (on why that falls short, see Model the domain first).

Each is good at its job. But none of them is built to express, or record, what its data means for the company's compliance.

Compliance lives in between

As we described in Compliance is a graph, compliance is the sum of all that information and the relationships within it. Spread across systems, that sum exists nowhere. In one industry survey, 62% of large medical device companies said they struggle with siloed data.¹

Each system holds part of the picture, but none says what its data means for compliance, let alone how it relates to the data in the others. Whether a requirement in Jira is covered by a test in Xray, implemented in a change on GitHub, and described in the right procedure is left to human judgement, often pieced together only for the annual review or the next audit.

Start from the source systems

For an established company, this is not an invasive change. Everything keeps running as it is: the same tools, the same processes, the same people. What the company gains is an overview across its systems, and an ongoing compliance state.

The source systems stay the source of truth. We build integrations to them, learn what data each one holds and how they interact, and model that information as a graph through an iterative mapping the company approves: one state that can express compliance, consistency and coherence across all of them (see Model the domain first). The model we are working towards has agents map and model the source data, with our engineers and the company's own people alongside them.

One piece at a time

As forward-deployed engineers, our aim is to embed with a team and learn which tasks take the most effort, and where AI can do more than speed up the existing process. We find where coverage and overview matter most, and model that part first: map the sources, add nodes for what the information represents, and relationships that express what we expect of it. Then we add the rules: deterministic checks where possible, AI judgement where it is needed. And then we extend from there.

At every step, the team can audit what the agents mapped, checked and concluded, and make the resulting assertion of compliance their own (see Trusting AI in compliance).

That only works if the model can keep growing without breaking the data already in it. How our database makes that possible is the subject of a later note.

Where this is going

What we are building towards is an operating system for compliance: one that shows the company's compliance posture at any moment, with every issue traced back to the source system and the data it came from.

We have not built it yet, but the same graph could also write back to the source systems, through typed and secured operations. The AI would never write directly. It would propose, say, how to update a test in Xray; a competent person reviews and confirms; Xray is updated, and the compliance posture follows. That is the same principle as everywhere else in Lumidocs: agents propose, people decide (see Trusting AI in compliance).

Sources

1. Greenlight Guru, 2025 Medical Device Industry Benchmark Report, more than 500 respondents (vendor-run survey): Greenlight Guru. ↩