The vocabulary of structured compliance.
The terms RuleMesh uses, what they mean, and where each one comes from. Written for engineers, AI agents, and auditors who want to understand the category without re-reading three policy documents and an IETF draft.
- Term 01
Compliance infrastructure
The structured, citation-backed rule layer that sits between regulation as written and software as built.
RuleMesh's category. Distinct from GRC platforms (which operate at the policy layer — documents, certifications, questionnaires) and from security tools (which prevent breaches). Compliance infrastructure ships executable rules consumable by engineers, AI agents, and auditors. Comparable in the systems sense to Stripe (financial infrastructure), HashiCorp (cloud infrastructure), or Plaid (financial-data infrastructure) — a layer that other systems run on, not a tool wrapped around them.
- Term 02
Rule graph
A structured graph of rules — each rule traceable to source law, mapped to engineering controls, carrying its own evidence specification.
The product asset. Two things have to be true at once: authoritative translation (every rule traces to primary legal text and is produced as a defensible engineering artifact, not an LLM prompt) and executable delivery (the same rule is consumable by Jira tickets, AI coding agents, platform APIs, and cloud policy engines). Translation without execution is a better-formatted PDF; execution without translation is automation pointed in the wrong direction. The rule graph is the combination — and the combination is the layer that doesn't exist today.
- Term 03
Execution layer
The running system itself — code, configuration, data flows, automated workflows — where regulated work actually happens.
Where compliance is satisfied or not satisfied. Contrasts with the policy layer. The production database that should be encrypted; the vendor onboarding workflow that should run a third-party assessment; the AI deployment that should retain its Annex IV documentation. Compliance failures rarely happen because the policy is wrong — they happen because the obligation never reached the surface where the work actually runs. RuleMesh delivers rules at the execution layer, where engineers, AI agents, and infrastructure can act on them at the moment the work is done.
- Term 04
Policy layer
The prose-and-document layer — internal policies, certifications, questionnaires, audit reports.
Where most existing GRC tooling operates (Vanta, Drata, OneTrust, ServiceNow GRC). Useful for demonstrating compliance after it has been achieved, for tracking certifications, and for producing reports auditors recognize. Necessary, but not sufficient. A written policy is evidence that a policy exists; under ISACA Standard 1205 and now under primary statute (GDPR Article 5(2), DORA, EU AI Act, NIS2), it is not sufficient evidence that the policy has been executed. The policy layer is where the obligation is named. The execution layer is where it is satisfied.
Read more/manifesto - Term 05
Structured rules (vs prose)
Rules expressed in a form a system, an agent, or an automated workflow can consume and act on directly.
The opposite of prose. Where a policy document says "ensure appropriate technical measures for the protection of personal data," a structured rule expresses what to implement, where, with what configuration, against which framework-specific control, and what evidence to emit when the control runs. Structured rules separate RuleMesh from every incumbent (GRC tools, Big Four consultancies, legal AI) whose output is prose for humans to read. An engineer can build from a structured rule. An AI coding agent can pull it into context. An auditor can verify the evidence the rule specifies.
- Term 06
Citation-backed
Every rule traces to its source article in primary law.
Auditor-defensibility by construction. A rule about encrypting personal data isn't asserted as a best practice — it is mapped to GDPR Article 32(1)(a), with the exact text of the obligation attached, and the evidence requirement the supervisor will ask for spelled out. Citation-backing also separates RuleMesh from LLM-wrapper products: large language models cannot reliably cite primary sources, and an unverifiable citation in a compliance context is worse than no citation at all. Every claim in the rule graph is traceable, versioned, and defensible to a court if it ever has to be.
Read more/cloud-mappings - Term 07
Evidence emission
The structured artifact a system emits when a control runs, written in the form a supervisor or auditor recognizes.
Self-evidencing rules. Where traditional compliance reconstructs evidence at audit time (months after the fact, often from incomplete logs), RuleMesh rules specify what evidence the consuming system must emit at the moment of execution — file names, configuration values, signal scores, signed attestations. Evidence is emitted as a consequence of the system acting, not produced separately by a human filling out a questionnaire. This is the only evidence model that meets ISACA's "sufficient and appropriate" standard at the rate modern systems change.
Read more/how-it-works - Term 08
Evidence Signals Report
A shareable artifact that captures the current compliance posture of a codebase against a regulation.
The output of a RuleMesh MCP scan. Lists requirements, partials, gaps, and the file-level signals that back each finding. Not a certification — a snapshot of where the system is against where the regulation says it should be, with citations and the evidence checklist for each open item. Designed to be readable by an engineer (so the gaps are actionable), defensible to an auditor (so the citations and evidence specifications survive scrutiny), and parseable by an AI coding agent (so the next iteration of work picks up exactly where the report left off).
Read more/how-it-works - Term 09
MCP server
A server that speaks the Model Context Protocol so AI coding agents can pull RuleMesh's rules into their context.
MCP — Model Context Protocol — is the open protocol Claude Code, Cursor, and other agents use to consume external context. The RuleMesh MCP server exposes the rule graph through MCP, so when an agent is implementing a feature that touches personal data, it can ask the MCP server which GDPR rules apply, get back structured requirements with citations, and write code that satisfies them by construction. The MCP server reads codebase metadata only — it never modifies, stores, or uploads source. It reports file names where evidence of a control was detected, not the contents.
- Term 10
HCAP — HTTP Compliance Authorization Protocol
An IETF standards-track draft for runtime, cross-organizational compliance verification over the wire.
Authored by RuleMesh and submitted to the IETF as draft-nyakiso-hcap-00. Where MCP solves consumption inside a single agent, HCAP solves verification across organizational boundaries: a financial institution requiring its payment processors to hold current DORA compliance credentials at API call time; an AI provider requiring its deployers to hold current AI Act documentation; a healthcare platform requiring downstream integrators to satisfy HIPAA continuously, not quarterly. HCAP is vendor-neutral by design — RuleMesh ships a Registry implementation, but the protocol is open. A vendor-neutral standard the company authored is a stronger long-term position than a proprietary protocol only the company speaks.
Read more/reports/hcap-http-layer - Term 11
Framework-specific control
An engineering control tailored to where the system actually runs — AWS vs Azure, Postgres vs DynamoDB, Kubernetes vs ECS.
The opposite of generic advice. A regulation says "use appropriate encryption"; a framework-specific control says "enable AWS S3 server-side encryption with KMS keys, rotate every 90 days, and emit an event to CloudTrail when the key configuration changes." Framework-specific controls are what make RuleMesh's rules implementable rather than aspirational. The mapping layer connects 192 GDPR requirements to 281 controls across AWS, Azure, GCP, NIST CSF, and OWASP — so an engineer reading a rule on a Jira ticket sees exactly what to do in their actual stack.
- Term 12
Design partner
A team that onboards directly with the founder, in exchange for shaping the roadmap and locking in early-cohort terms.
Not a customer in the conventional sales sense. Five teams at a time, capped because that is the number the founder can personally support without diluting the work. Design partners get founder-led onboarding, 50% off the GDPR Intel add-on for year one, 50% off future regulation add-ons for 12 months from launch, and direct influence on which rules ship next. In exchange, they bring real engineering work that exercises the rule graph against production codebases — which is how the translation quality compounds.
Read more/apply - Term 13
The three audiences
Engineers, AI agents, and auditors — the three readers RuleMesh serves with the same rule graph.
The audience trio is structural, not marketing. Engineers consume rules on Jira tickets and in MCP context. AI coding agents consume rules to write implementations correct by construction. Auditors consume the evidence the rules emit, with citations back to source law. Most existing compliance tooling serves one of the three — security tools serve engineers, GRC tools serve compliance teams, legal AI serves lawyers. RuleMesh serves all three because compliance only works when all three are reading from the same shared specification.
Read more/about - Term 14
Duty to demonstrate
The statutory obligation to produce evidence that compliance has been achieved — not merely that a policy exists.
Codified in GDPR Article 5(2) ("the controller shall be responsible for, and be able to demonstrate compliance") and amplified by DORA, the EU AI Act (Article 11, Annex IV), NIS2, and the SEC's 2023 cybersecurity rule. The duty to demonstrate is the legal corollary of ISACA Standard 1205's "sufficient and appropriate evidence" requirement. It is the reason policy-layer compliance is no longer enough on its own — and the reason execution-layer infrastructure (rules that emit evidence as they execute) has become a regulatory requirement, not just an operational improvement.
Read more/manifesto - Term 15
Translation gap
The first of three gaps between the legal text and the running system that must satisfy it.
Compliance writes "ensure appropriate technical measures." Engineering reads that and asks: appropriate by whose standard? What control? What evidence? What configuration? The policy document doesn't answer. The legal text doesn't answer. Somewhere between Article 32 and the production database, a specific decision has to be made, and there is no party whose job is to make it. Engineering guesses, or a consultant translates per client (expensive, stale, not reusable), or a prose policy gets filed and engineers go back to guessing. RuleMesh closes the translation gap by making the translation a structured, versioned, citation-backed engineering artifact.
- Term 16
Coverage gap
The second of three gaps — the obligation reaches the central system but not the hundred surfaces around it.
GDPR doesn't only apply to the production database. It applies to the spreadsheet sales uses, the vendor onboarding workflow, the access review, the AI system in pilot, the customer support tool, the data warehouse, the marketing automation. Policy gets mapped to what someone thought to map it to. The rest get nothing. A company can pass SOC 2 with central systems in order and still be systemically non-compliant at the periphery. RuleMesh closes the coverage gap by being available at every surface where regulated work happens — Jira tickets, MCP context, APIs, cloud policies, custom automations.
- Term 17
Verification gap
The third of three gaps — verification happens after the fact, on a cycle that has nothing to do with when the risk was taken.
The economic consequence is that cost of compliance is structurally backloaded. Everything is expensive to find late, expensive to remediate late, expensive to defend late. There is no mechanism in the current architecture that lets compliance be satisfied at the moment it should be — when a system is designed, deployed, or changed. RuleMesh closes the verification gap by emitting evidence as a consequence of the system acting, not reconstructing it three months later in a questionnaire. Self-evidencing rules turn verification into a continuous property of the running system, not a periodic external event.
Read the source documents.
Every term here is supported by a longer document — the manifesto on policy vs execution layer, the agent-agnostic compliance whitepaper, the HCAP draft, and the MCP integration guide.