view_kanban
Jira app
If your sprint touches user data, the GDPR rules show up on the ticket. If it touches a third-party vendor, the rules show up. No separate place to remember to look.
Atlassian Forge · early access
When the compliance team is the engineering team.
You don't have a privacy officer. You don't have a fractional CISO. The founding engineer who shipped the auth flow last sprint is the same person reading GDPR Article 32 this sprint, hoping they got it right. RuleMesh gives them the answer instead of the article.
priority_highWhere this bites
You don't notice the gap until something specific lands.
For most teams it's one of four moments.
Moment · 01
The first enterprise security questionnaire.
Three hundred questions. Half of them want evidence you've never been asked to produce. You miss a week of building, send a partial answer, and watch the deal stall while procurement asks for clarifications.
Moment · 02
The first EU customer.
Their legal team wants a Data Processing Addendum and a Record of Processing Activities. You search for templates. Templates are written for compliance officers, not engineers, and they assume controls you haven't formalised yet.
Moment · 03
The first AI Act question.
A prospect's procurement form asks how you classify your model under the AI Act, what your Annex IV documentation pack contains, and how human oversight is implemented. Three of those terms didn't exist in your vocabulary last quarter.
Moment · 04
The Cursor / Claude Code moment.
Your team ships a feature largely written by an AI coding agent. The code looks fine. Nobody knows whether the auth handler it generated satisfies any specific obligation, or whether the data-handling logic passes a scrutiny test you have no framework to apply.
Each of these is a small fire. You put it out and ship anyway. Then the next one arrives.
descriptionWhat we give a team without specialists
The thing missing isn't a compliance team. It's the specification a compliance team would produce.
RuleMesh ships a rule for every obligation in a regulation, citation-backed to source law, mapped to engineering controls your team already recognises (OWASP for authentication, CIS for cloud hardening, NIST for access), with the evidence requirement already specified. Compliance and legal could read these rules. Auditors will. The intent is that your engineers can build from them without re-derivation.
You stop guessing what appropriate technical measures means. You start working from the same thing a privacy officer would have given you, except they didn't, because you don't have one.
smart_toyFor teams building with AI agents
Code generated alongside an obligation has the obligation in scope.
This is the part that matters for a team building with Claude Code, Cursor, or Copilot.
We ship an MCP server. Coding agents pull rules into their context with citations. When a developer prompts Claude Code to add a vendor onboarding workflow for a new SaaS subprocessor, the agent has the relevant GDPR Article 28 rule available in scope — what to implement, the control pattern, the evidence the system has to emit.
The architecture matters: agents pull rules from a single source of structured truth, not from whatever interpretation showed up in a Stack Overflow thread. As your team leans more on agents to ship, the compliance layer either keeps up at machine speed, or it becomes the thing your agents route around.
claude-code · mcp · rule.lookup · 2026-04-29CITED
> add vendor onboarding workflow for new SaaS subprocessor
// claude-code → mcp.rulemesh.lookup({domain:"processors"})
RULE GDPR-28-003
OBLIGATION
description: "Engage processors only under a binding contract with documented technical and organisational measures."
cite: "GDPR Art. 28(1)–(3)"
CONTROL
frameworks: ["NIST_CSF · ID.SC-3", "Cloud_Security · vendor.review"]
pattern: "vendor.assessment.tier · contract.dpa.clauses · sla.continuity"
responsibleRole: "Privacy Engineer / DPO"
EVIDENCE
emit: ["vendor_register.entry", "tier_assessment.signed", "dpa.clauses.json"]
retention: "5y · post-termination"
// agent now has the obligation in scope before generating code.
trending_upWhat good looks like
Three concrete shifts once the rule layer is in place.
Shift · 01
Security questionnaires.
You answer from a structured source instead of writing prose from scratch. The same questionnaire — third time it lands, with different framing — takes hours rather than days, because the underlying evidence is already there.
Shift · 02
New regulations.
When the next regulation enters force, your engineers don't have to re-interpret it from scratch. We package it. They consume it on the same Jira tickets and through the same MCP context they already use.
Shift · 03
Audit posture, before the audit.
You don't have a SOC 2 yet. That's fine. The point is that when you do go for one, your evidence isn't a reconstruction project. It's already attached to the rules.
We're frank about the stage: these are the outcomes design partners are working toward with us. The product is live, GDPR is packaged end-to-end, and the next regulations on the roadmap are DORA, NIS2, and the EU AI Act.
hubWhat this looks like in your workflow
You don't have to learn another tool.
view_kanban
Jira app
If your sprint touches user data, the GDPR rules show up on the ticket. If it touches a third-party vendor, the rules show up. No separate place to remember to look.
Atlassian Forge · early access
smart_toy
MCP server
Plugs into Claude Code, Cursor, and any other MCP-aware client. Your existing agent workflows pull rules into scope without prompt-engineering them in.
stdio · HTTP · live
api
GraphQL API
If your platform team wants to surface rules in your own tooling. Typed schema, regulation/control/evidence types.
typed schema · design-partner preview
cloud_done
Cloud policy outputs
For AWS, Azure, and Kubernetes. Rules become the configuration enforcement your IaC pipeline already runs.
Terraform · OPA · Azure Policy · design-partner preview
Jira is where we are today because it's where our design partners are. If your team is on Linear (or Asana, or something else), that's a conversation worth having early — the same surface pattern extends, and the order we build new integrations in tracks design-partner demand.
One ingestion engine. The graph is updated as regulations evolve. You don't track the diffs; we do.
check_circleThe right fit at this stage
If three or four of these describe you, write directly.
- check5–20 people, EU- or US-headquartered SaaS or AI company.team_size
- checkAlready on Jira and a major cloud.stack
- checkCompliance has shown up as a deal-blocker, an EU customer requirement, or an AI Act question on at least one active opportunity.trigger
- checkThe team building the product is also the team handling compliance, because there is no separate team yet.no_specialists
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.