Open Standard
Gemara
GRC Engineering Model for Automated Risk Assessment
The schema and taxonomy backbone that makes the entire compliance automation stack interoperable.
What it is
Gemara — GRC Engineering Model for Automated Risk Assessment — is a seven-layer taxonomy for describing how compliance works, written in CUE and designed to be machine-readable from end to end. The layers move from abstract to concrete: the first three define risks, controls, and threats at a conceptual level; Layer 4 identifies sensitive activities as the pivot point between policy and enforcement; and Layers 5 through 7 cover measurement, evaluation, and audit. Every standard, control catalog, and toolchain in the Meridian ecosystem maps into this model.
The taxonomy is expressed in CUE — a constraint-based schema language — which means Gemara definitions are not documentation. They are machine-checkable schemas. A policy written against Gemara can be validated automatically. A control catalog that implements Gemara Layer 2 can interoperate with any other tool that does the same, regardless of vendor.
Why it matters
Before Gemara, compliance automation was fragmented by design. Every GRC platform had its own data model. Every scanner output a different format. Connecting them required custom glue code at every seam, and that glue code became the thing that broke when a regulation changed or a vendor updated their API. The root cause was the absence of a shared language — not a shared tool, but a shared way of describing what compliance means.
Gemara is that language. It does not prescribe which controls you must implement or which frameworks you must comply with. It defines the structure in which those decisions are expressed, so that any tool implementing the model can read, validate, and act on them. The practical effect is that compliance becomes composable: a control defined in Meridian Chancery flows automatically to Meridian Patrol for monitoring, to Meridian Loft for architectural validation, and to Meridian Admiralty for executive reporting — not because those components were hardwired together, but because they all speak the same underlying language.
Meridian's role
Gemara was created by Meridian's founding team. We built it because we needed it — we were doing compliance automation work across regulated industries and kept running into the same problem: no common model meant every engagement started from scratch. Rather than treat it as proprietary infrastructure, we contributed Gemara to the OpenSSF foundation, where it now operates under independent governance.
That decision was deliberate. A taxonomy that one vendor controls is not a standard — it is a proprietary schema with a public relations strategy. By placing Gemara under OpenSSF governance, we made it something the industry can build on without being dependent on Meridian's roadmap. We remain active maintainers and contributors, but the model belongs to the community.
How it connects to the platform
Gemara is the connective tissue of the entire Meridian platform. It is not a component you interact with directly — it is the model that every component implements. When Meridian Chancery authors a policy, it is expressed as a Gemara schema. When Meridian Patrol detects drift, it reports against a Gemara-defined approved state. When Meridian Admiralty summarizes posture for a CISO, it aggregates evidence structured according to Gemara's audit layers.
This means that evidence collected by any Meridian component is structurally consistent with evidence collected by any other — and with any external tool that implements the model. When an auditor asks for proof that a specific control was evaluated, the answer is not a manually assembled spreadsheet. It is a structured, machine-generated record that traces back through every layer of the taxonomy.
Meridian