view_kanban
Jira app
The relevant rule attaches to engineering tickets automatically — no comment-thread re-explanation.
Atlassian Forge · early access
You're not the bottleneck. The rule layer is missing.
You write the policy. Engineering asks what does that mean concretely? You re-explain it. They half-implement. Six months later the auditor asks for evidence and you reconstruct it from Slack, Jira, and three people's memories. The work isn't legal interpretation. It's archaeology.
replayWhat you keep encountering
The pattern is consistent across every compliance function we've spoken to.
Three vignettes — recognise at least one.
Vignette · 01
The interpretation tax.
You produce a policy that's correct under the regulation. Engineering implements their reading of it, which is correct under their reading. The two are different. You discover the gap during the audit, not before.
Vignette · 02
The evidence-reconstruction project.
The supervisor asks how you ensure access reviews actually happen. You know they do. You have to reconstruct evidence after the fact from Jira tickets, Slack threads, and the institutional memory of two engineers. Half a quarter, every time.
Vignette · 03
The new regulation.
DORA passes. You read the text. You write the policy. You hand it to engineering. You re-explain it three times in three different forums. You repeat the entire cycle for NIS2 the following year. And again for the AI Act.
None of this is failure of legal interpretation. It's the absence of a structured artefact between the regulation and the system that's supposed to satisfy it.
descriptionThe artefact that's been missing
A rule, in three layers. Not prose. Not a checklist.
A structured object compliance can review, engineering can build from, and auditors can verify against — all from the same source.
RuleMesh produces a rule for every obligation in a regulation. Three layers, structured: the obligation itself with citation back to source law; the engineering control that satisfies it (Cloud_Security, NIST_CSF, OWASP_TOP_10); and the evidence that proves it was done.
You read the obligation layer. Engineering reads the control layer. The evidence layer becomes the artefact for the audit. One source, three audiences.
The rule on the right is one of the live IT requirements under GDPR Article 32(2) — risk register and structured risk assessment — as it ships to a design partner today. Note the third panel: a compliance checklist generated alongside the rule, written for the role that signs off, not the engineer who implements.
IT-Requirement · GDPR Art. 32(2) · liveCITED · LIVE
// 01 · OBLIGATION
id: "itreq-32016R0679-art-32-para-32_2-req-1"
cite: "GDPR Art. 32(2)"
source: "eur-lex.europa.eu/.../CELEX:32016R0679"
description: "Maintain a risk register and conduct structured risk assessments that explicitly identify and document risks to personal data including accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or unauthorised access — covering data in all states (transmitted, stored, or otherwise processed)."
riskLevel: "High"
responsibleRole: "Data Protection Officer / Risk Manager"
// 02 · CONTROL · complianceDSL
frameworks: ["NIST_CSF · ID.RA-3", "NIST 800-53 · RA-3 (High baseline)"]
SHALL conduct and maintain structured risk assessments
FOR personal data processing risks
INCLUDING accidental or unlawful destruction, loss,
alteration, unauthorised disclosure,
unauthorised access
IN all data states (transmitted, stored, processed)
USING a documented risk register with threat mapping
and control coverage
// 03 · COMPLIANCE CHECKLIST
[ ]Does the risk register explicitly document risks of accidental or unlawful destruction, loss, alteration, unauthorised disclosure, and unauthorised access?
[ ]Does the risk assessment cover personal data in all states — transmitted, stored, and otherwise processed?
[ ]Are data flow diagrams maintained to identify all personal data transmission and storage points?
[ ]Are risk likelihood and severity ratings documented and used to prioritise controls?
[ ]Is the risk register reviewed and updated when processing activities change?
// 04 · EVIDENCE
evidenceRequired: [
"risk_register",
"threat_model.documentation",
"risk_assessment.reports",
"data_flow.diagrams",
"control_mapping.records"
]
// supervisor: "show me your risk register" → risk_register.json
layersThree layers, one source
The same rule answers three different questions for three different audiences.
01 · Obligation
What the law actually says.
Engineered at the article and paragraph level. Citation back to EUR-Lex on every rule. The layer compliance and legal review for accuracy. No interpretation drift between you and the source.
audience · compliance · legal02 · Control
How a system satisfies it.
Mapped to the engineering frameworks teams already work in. Mapping rationale recorded. The layer engineering builds from. No re-explaining the same article for the third sprint in a row.
audience · engineering · platform03 · Evidence
What proves it ran.
Specified at write-time, emitted at runtime. The artefact, log, configuration, or attestation a supervisor will accept. The evidence already exists, in the shape it's asked for.
audience · audit · supervisorswap_horizWhat changes for the compliance role
The legal-interpretation work doesn't go away. The re-explanation, the back-and-forth, and the reconstruction does.
Before · today
Reading law. Writing prose. Re-explaining it three times.
Most of the day spent restating the same obligation in Jira comments, Confluence pages, audit narratives, and procurement responses. The original interpretation is solid; everything downstream of it is duplicated effort.
After · with the rule layer
Approving the structured rule. Once.
You review the rule as it’s packaged — obligation, citation, control mapping, evidence requirement. You sign off. The rule is then consumed by every engineer, every agent, every audit downstream from a single source. Your interpretation propagates without you re-typing it.
verifiedAudit posture
Audit posture, before the audit.
If a supervisor asks show me you encrypted at rest, you ran your quarterly access reviews, you assessed the third-party vendor before onboarding — you don't open Slack. You don't email three engineers. You retrieve the evidence the rule already specified.
This isn't an audit-automation product. It's a specification discipline applied at the moment a regulation enters your stack. The fact that audits become straightforward is a downstream consequence of the obligation, control, and evidence being structured up front.
What this is not.
Not a SOC 2 platform. Not a GRC suite. Not a replacement for your judgement. The rule layer is the missing artefact between regulation and running system. Everything you do as a compliance professional that isn't re-explanation or reconstruction stays where it is — and gets faster, because the work upstream and downstream of you is on the same page.
hubWhere the rules show up downstream
You approve the rule once. It propagates here, automatically.
view_kanban
Jira app
The relevant rule attaches to engineering tickets automatically — no comment-thread re-explanation.
Atlassian Forge · early access
smart_toy
MCP server
Coding agents consume your approved rule directly. Their output respects the obligation in scope.
stdio · HTTP · live
api
GraphQL API
For internal tooling, audit dashboards, and the questionnaire-response surfaces compliance teams already maintain.
typed schema · design-partner preview
cloud_done
Cloud policy outputs
Configuration enforcement that emits the evidence your rule already specified. No reconstruction.
Terraform · OPA · Azure Policy · design-partner preview
Jira is where we are today because it's where our design partners are. The same surface pattern extends to Asana, ServiceNow, Linear, and the other systems engineering and operations work happens in — those land as design-partner demand pulls them in. If you're already living in ServiceNow's GRC module and need the rules surfacing there, that's the kind of demand-pull that moves an integration up the queue.
One ingestion engine. The graph is updated as regulations evolve. You stay upstream of the change; the surfaces stay current.
flagStage, frankly
GDPR live. DORA, NIS2, and the AI Act next.
GDPR is packaged end-to-end and live. DORA, NIS2, and the EU AI Act are the next packages, with twenty more on the roadmap across the EU, the US, and Australia.
If your team is the one inheriting the next regulation in twelve months, the moment to shape how it lands in your stack is now — while we're still in design-partner mode, while the schema is still moving, and while the founder is the one taking the call.
handshakeDesign Partner Program
Shape the product, don't inherit it.
RuleMesh is shaped by the companies we onboard as design partners. They get first access to new regulation packages, direct input on the roadmap, and a line straight to the founder.
First access to new regulationsDirect roadmap inputLine to the founder
Request a Spot
We take on a small number of partners at a time. Lawrance will reach out directly.