For decades, auditors and governments defined and molded Legacy GRC in their image. Today, engineers and analysts are transforming it into something new: GRC Engineering. This cheat sheet outlines what makes GRC Engineering different.
This README is the canonical content source for the live cheat sheet at cheatsheet.grc.engineering — the site fetches and renders this file at runtime, so any change merged here goes live within minutes. To contribute a tool, term, teaching, or timeline event, edit the relevant section below and open a pull request (see Contributing).
"Governance, risk, and compliance (GRC) are three related facets that aim to assure an organization reliably achieves objectives, addresses uncertainty and acts with integrity."
"Engineering is the practice of using natural science, mathematics, and the engineering design process to solve problems within technology, increase efficiency and productivity, and improve systems."
GRC Engineering is the practice of using science, math, user-centered design, and modern software development to assure an organization reliably achieves objectives, addresses uncertainty, and acts with integrity, all while continuously improving its efficiency, productivity, and systems.
— The GRC Engineering Cheat Sheet
A side-by-side comparison of the legacy GRC mindset and the GRC Engineering approach across the five program areas. Inside each cell, multiple bullets are separated with <br>•.
| Program | Legacy GRC | GRC Engineering |
|---|---|---|
| All | • Framework-centric approaches • Shallow & narrow problem solving mindset • Cumbersome user experience (UX) across GRC processes, tools, etc. • Work products = static documents, manual workflows, disjointed processes, and theatrical controls • Processes are excessively, if not exclusively, manual • Trivial outputs conflated with meaningful outcomes • GRC treated as a program that serves GRC teams' needs and preferences |
• Objectives-centric, risk-focused, and threat-informed approaches • Systems thinking applied broadly (organizational governance, risk analysis, control modeling, etc.) • Design thinking harnessed to make the right thing to do the easy thing to do • Work products = dynamic systems, automated workflows, embedded processes, and enforced guardrails • Processes are automated, early on and often • Measurable, meaningful outcomes (or bust) • GRC treated as a product that serves internal and external customers' needs and preferences |
| Governance | • Mainly consists of static policies, standards, and procedures that everyone "acknowledges" but never remembers • Static governance documentation rarely reflects reality of controls • Committees exist to check boxes but rarely, if ever, drive strategic decisions that effect change • Awareness training checks boxes but is too infrequent, delayed, unengaging, and ill designed to durably change behaviors |
• Mainly consists of strong guardrails (e.g. policy-as-code) that enforce risk tolerance & paved paths that make it easy to do the right thing the right way • Dynamic governance documentation is enforced via policy-as-code, expressed via policy-to-code, and reconciled via policy-from-code • Committees exist to define/refine decision making frameworks & to facilitate strategic decisions • Real-time behavioral interventions prevent improper behaviors, while awareness training leverages science-based pedagogy to durably change behaviors |
| Risk | • Risk program is built on qualitative risk analyses that are heavily, if not entirely, based on unvalidated assumptions, uncalibrated intuition, and generic heatmap frameworks • "Risks" are ambiguous hypotheticals or "control gap findings" that are detached from a real-world understanding of relevant threats, threat vectors, weaknesses, assets, and/or impacts • Numerical risk scores conflated with "risk quantification" • Risk tolerance/appetite are imaginary concepts that exist in policy documents with no real-world grounding • Fear, uncertainty, & doubt (FUD) dominates risk register entries and risk conversations • Risk team operates as "accountability police" that attempts to pressure, shame, or strong arm fellow teams into taking action • Third-party risk management (TPRM) is really just third-party compliance management (TPCM) in disguise, focused entirely on third-party controls/mitigations while overlooking first-party risk mitigation opportunities |
• Risk program is built on quantitative risk analyses that are based in scientifically-sound forecasting methods, statistical modeling, real-world evidence, and proven frameworks (e.g. FAIR) • "Risks" are holistic scenarios that account for threats, threat vectors, weaknesses, assets, controls, and impacts • True risk quantification is in place, with quantitative inputs producing quantitative outputs • Risk tolerance/appetite is derived from real-world and measurable constraints, such as insurance limits, cash reserves, organizational goals, and executive leaderships' values and principles • Evidence, logic, math, & reason (ELMR) dominates risk register entries and risk conversations • Risk team operates as "decision support partners" that enable their organization to make smart risk decisions • TPRM is actually managing risk, focused on holistic scenarios, quantitative risk analyses, and both first-party and third-party controls/mitigations |
| Compliance | • Control monitoring is done periodically, infrequently, and manually • Control design evaluations and testing methods are ignorant of real-world threat models • Control evidence assessments are sampling-based and are partially or totally unscientific, ignorant of effect size, statistical power, etc. |
• Control monitoring is event-driven (i.e. real-time) whenever possible, highly automated, and frequent • Control design evaluations and testing methods are rooted in evidence-based real-world threat models • Control evidence assessments are full population-based. When sampling is unavoidable, sampling methods are scientific and account for effect size, statistical power, etc. |
| Trust & Assurance | • Trust signals are predominantly in the form of questionnaires and static documents • Customers gather trust & assurance artifacts via cumbersome RFP/RFI processes that are largely mediated over email or support tickets |
• Trust signals in the form of historical control monitoring metrics are transparently and programmatically provided, and are consumable in human-readable and machine-readable formats • Customers can easily self-serve their way through gathering trust & assurance artifacts, getting questionnaires automatically completed, etc. |
A history of governance, risk, and compliance milestones — from the first federal IT security standards to the emergence of GRC Engineering as a discipline.
| Year | Date | Event | Actor | Summary | Relevance | Source |
|---|---|---|---|---|---|---|
| Jun 1974 | June 1, 1974 | FIPS 31 | Governments · NIST | Federal Information Processing Standard 31 — the first US government guideline on automatic data processing physical security and risk management. | Established the foundational pattern of government-issued standards driving organizational security practice. | https://csrc.nist.gov/pubs/fips/31/final |
| 1977 | 1977 | Control Objectives | Auditors · IIA | The Institute of Internal Auditors' Systems Auditability and Control study formalized the concept of "control objectives" for IT. | Created the auditor-centric vocabulary that still dominates Legacy GRC. | https://books.google.com/books/about/Systems_Auditability_Control_Study_Data.html?id=IJApAQAAMAAJ |
| Aug 1979 | August 1, 1979 | FIPS 65 | Governments · NIST | First federal risk analysis methodology — a quantitative annualized loss expectancy (ALE) approach to IT risk. | Predecessor to all modern quantitative cyber risk methods (FAIR, ALE, Monte Carlo simulations). | https://csrc.nist.gov/pubs/fips/65/final |
| Aug 1983 | August 15, 1983 | The Orange Book | Governments · DoD | The NCSC's Trusted Computer System Evaluation Criteria (originally CSC-STD-001-83) — defined assurance levels (C1, C2, B1, B2, A1) for trusted systems; reissued as DoD 5200.28-STD on December 26, 1985. | First formal criteria-based certification regime; precursor to Common Criteria and FedRAMP. | https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/dod85.pdf |
| Apr 1988 | April 1988 | NIST SP 500-153 | Governments · NIST | NIST (formerly NBS) publishes SP 500-153 "Guide to Auditing for Controls and Security: A System Development Life Cycle Approach". | Well-defined guidelines and standards for IT auditing in the context of system development lifecycles. | https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublication500-153.pdf |
| Apr 1992 | April 1992 | SAS 70 | Auditors · AICPA | AICPA's Statement on Auditing Standards No. 70 enabled independent audits of a service organization's controls. | Introduced third-party assurance reporting — the direct ancestor of SOC 2. | https://egrove.olemiss.edu/aicpa_sas/73/ |
| Sep 1992 | September 1992 | COSO Internal Control Framework | Auditors · COSO | COSO published its Internal Control — Integrated Framework, the model that still underpins SOX control testing. | Became the reference internal-control model auditors evaluate financial and IT controls against. | https://egrove.olemiss.edu/aicpa_assoc/203/ |
| Feb 1995 | February 1995 | BS 7799 | Governments · BSI | British Standards Institution code of practice for information security management. | Direct ancestor of ISO 27001, the global ISMS standard. | https://knowledge.bsigroup.com/products/information-security-management-code-of-practice-for-information-security-management-systems/standard |
| Apr 1996 | April 1996 | COBIT | Auditors · ISACA | ISACA (then ISACF) released the first edition of Control Objectives for Information and Related Technologies (COBIT). | Established the IT governance framework still widely audited against. | https://www.isaca.org/resources/cobit |
| Aug 1996 | August 21, 1996 | HIPAA | Governments · HHS | US healthcare privacy and security law (Public Law 104-191) signed by President Clinton. | Established sector-specific compliance regulation enforced by HHS. | https://www.govinfo.gov/app/details/PLAW-104publ191 |
| Jul 2002 | July 30, 2002 | SOX | Governments · US Congress | Sarbanes-Oxley (Pub. L. 107-204) imposed financial-reporting internal-control requirements on US public companies. | Birth of the modern compliance industry — created enormous demand for control documentation and audit work. | https://www.govinfo.gov/app/details/PLAW-107publ204 |
| Dec 2002 | December 17, 2002 | FISMA | Governments · US Congress | The Federal Information Security Management Act, enacted as Title III of the E-Government Act of 2002 (Pub. L. 107-347). | Standardized federal agency security programs and seeded the NIST Risk Management Framework lineage. | https://www.govinfo.gov/app/details/PLAW-107publ347 |
| Dec 2002 | December 2002 | OCEG founded | Analysts · OCEG | The Open Compliance and Ethics Group was officially launched to integrate governance, risk, and compliance into one discipline. | Formalized and popularized "GRC" as an integrated practice — the term itself was coined by Michael Rasmussen at Forrester in February 2002. | https://www.oceg.org/20-years/ |
| 2004 | 2004 | OCEG Red Book published | Analysts · OCEG | OCEG published the first GRC Capability Model — the "Red Book." | Established the first formal GRC capability model, the reference architecture later GRC tooling was built around. | https://www.oceg.org/20-years/ |
| Oct 2005 | October 14, 2005 | ISO 27001 | Governments · ISO/IEC | International standard for information security management systems, evolving from BS 7799. | Became the de facto global ISMS certification. | https://www.iso.org/standard/42103.html |
| Jun 2011 | June 15, 2011 | SSAE 16 & SOC | Auditors · AICPA | AICPA replaced SAS 70 with SSAE 16, introducing SOC 1, SOC 2, and SOC 3 reports. | SOC 2 became the dominant trust signal for SaaS vendors. | https://egrove.olemiss.edu/aicpa_prof/472/ |
| Feb 2014 | February 12, 2014 | NIST CSF | Governments · NIST | Cybersecurity Framework v1.0 — voluntary risk-based framework with Identify / Protect / Detect / Respond / Recover functions. | Most widely adopted cybersecurity framework outside of regulated sectors. | https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02122014.pdf |
| May 2016 | May 24, 2016 | GDPR | Governments · EU | General Data Protection Regulation (Regulation (EU) 2016/679) — comprehensive EU privacy law with global extraterritorial reach; entered into force 24 May 2016 (applied from 25 May 2018). | Reset the bar for privacy controls and triggered a wave of similar legislation worldwide. | https://eur-lex.europa.eu/eli/reg/2016/679/oj |
| 2021 | June 1, 2021 | Netflix hires first GRC Engineer | Engineers · Netflix | Netflix posted some of the first job descriptions explicitly titled "GRC Engineer," applying engineering practices to compliance. | Marked the emergence of GRC as an engineering discipline rather than a purely auditor-driven function. | https://www.radicalcompliance.com/2021/06/18/compliance-jobs-report-june-18/ |
| Jan 2023 | January 16, 2023 | DORA | Governments · EU | Regulation (EU) 2022/2554 — the Digital Operational Resilience Act, harmonizing ICT risk, resilience testing, and third-party oversight for EU financial entities; entered into force 16 January 2023. | Made operational-resilience controls and continuous testing a regulatory requirement in finance. | https://eur-lex.europa.eu/eli/reg/2022/2554/oj |
| Jan 2023 | January 16, 2023 | NIS2 Directive | Governments · EU | Directive (EU) 2022/2555 — expanded EU cybersecurity risk-management and incident-reporting obligations across critical and important sectors; entered into force 16 January 2023. | Broadened mandatory security controls and board accountability across the EU economy. | https://eur-lex.europa.eu/eli/dir/2022/2555/oj |
| Nov 2023 | November 23, 2023 | GRC Engineering Podcast launches | Engineer · Community | Ayoub Fandi launches the first podcast dedicated to GRC Engineering with episode S1E1 — "The Who, the Why and the What." | First sustained public conversation series for the discipline; grew the community beyond conference talks. | https://www.youtube.com/watch?v=vupO7TxBWpM |
| Jul 2024 | July 15, 2024 | GRC Engineering Manifesto published | Engineer · Community | A community-authored manifesto codifying the principles of GRC Engineering at grc.engineering. | Crystallized the discipline's values — engineering practices, automation, design thinking — into a shared artifact. | https://grc.engineering/ |
Vocabulary that distinguishes GRC Engineering thinking from legacy GRC.
| Term | Description |
|---|---|
| Active Testing | Exercising controls to confirm they function—not just checking they exist. Analogous to software automated tests. |
| Compliance | Acting with demonstrable integrity so the organization can prove it does what it claims — full-population control evidence, real-time monitoring, and code as the source of truth. |
| Control Monitoring | Observing whether controls operate as intended. GRC Engineering automates this continuously and holistically. |
| Decision Support | Providing data, analysis, and options so stakeholders make informed risk decisions. Replaces the "accountability police" model. |
| Design Thinking | Human-centered problem-solving methodology. Harnessed to make the right thing to do the easy thing to do. |
| ELMR | Evidence, Logic, Math, Reason. The GRC Engineering alternative to FUD—grounded in verifiable data and sound reasoning. |
| Evidence Populations | Complete control records collected automatically over a period. Eliminates sampling risk with full coverage. |
| Evidence Samples | Legacy subset of records selected to demonstrate control operation. Incomplete and vulnerable to selection bias. |
| FUD | Fear, Uncertainty, and Doubt. Legacy fear-based risk communication used to justify budget without rigorous analysis. |
| Governance | Governing with due care so the organization reliably achieves its objectives — paved paths, guardrails, and policy-as-code. |
| GRC as a Product | Treating GRC programs as products serving internal and external customers, with user research, feedback loops, and measurable outcomes. |
| Heatmaps | Legacy likelihood × impact matrices on ordinal scales. Obscure actual risk magnitude behind coarse, subjective categories. |
| Histograms | Frequency-distribution charts conveying risk shape, range, and confidence intervals in objective, data-driven terms. |
| Monte Carlo Simulations | Probabilistic simulations producing distributions and histograms instead of single-point estimates and heatmaps. |
| Policy-as-Code (PaC) | Policies written as executable code; the code is the source of truth, enabling version control, testing, and deterministic enforcement. |
| Policy-from-Code | Deriving policy documentation from code, configurations, or runtime behavior. Closes the gap between docs and control reality. |
| Policy-to-Code | Translating human-readable policy documents into executable code, bridging policy authors and enforcement systems. |
| Qualitative Risk Analysis | Subjective High/Medium/Low scales based on expert judgment. Manual, inconsistent, and difficult to aggregate. |
| Quantitative Risk Analysis | Numerical models, probability distributions, and measurable data. Automated, reproducible, and comparable across scenarios. |
| Risk | Managing risk with due diligence so the organization addresses uncertainty — threat-informed quantitative analysis, evidence-based scenarios, and continuous exposure monitoring. |
| Risk Scenarios | Holistic descriptions combining threat + attack vector + affected asset + impact into a single analyzable unit. |
| Scientific Pedagogy | Evidence-based learning science—spaced repetition, scenario-based exercises, measurable retention—applied to security training. |
| Systems Thinking | Examining how components interrelate and work together over time within larger systems. Applied across governance, risk analysis, and control modeling. |
| Threat-Informed | Grounding policies, controls, and trainings in real-world threat intelligence rather than abstract framework checklists. |
| TPCM | Third-party compliance management. Legacy questionnaire-focused approach that conflates compliance with risk. |
| TPRM | Third-party risk management. Balanced third + first-party focus, evaluating real-world threat scenarios and value-at-risk. |
Open-source and commercial tools that enable GRC Engineering practices — policy-as-code, continuous compliance, evidence automation, quantitative risk, and compliance-as-code.
| Tool | Description |
|---|---|
| Ansible | Policy-as-code via playbooks and roles; continuous compliance through idempotent automated configuration enforcement. |
| Checkov | Static IaC scanner (Terraform, CloudFormation, Kubernetes, ARM…); policy-as-code and continuous compliance in CI/CD. |
| Chef | Continuous compliance via InSpec's human-readable audit DSL; Policyfiles express policy-as-code for environment configuration. |
| claude-grc-engineering | Claude Code plugin suite for evidence collection, SCF crosswalks, multi-framework gap reports, and OSCAL workflows. |
| Cloud Custodian | YAML-based rules engine for cloud governance, security, and continuous compliance with serverless auto-remediation. |
| CloudQuery | Infrastructure-as-data platform syncing cloud and SaaS configurations into queryable databases for evidence pipelines. |
| Compliance to Policy (C2P) | Bridges OSCAL compliance-as-code with policy-as-code engines (Kyverno, OCM, Auditree); generates policies and ingests assessment results. |
| Compliance Trestle | OSCAL-native compliance-as-code platform for CI/CD authoring, validation, and governance of compliance artifacts in git. |
| Corsair | Signs compliance findings as W3C Verifiable Credentials (Ed25519 / JWT) so any party can verify integrity without trusted intermediaries. |
| FAIR | Open standard decomposing risk into measurable factors (threat event frequency, vulnerability, loss magnitude). |
| Gemara | OpenSSF seven-layer logical model for automated GRC engineering — standardised, machine-readable schemas (CUE) for compliance interoperability. |
| GigaChad GRC | Open-source modular GRC platform for compliance (SOC 2, ISO 27001, HIPAA), risk registers, vendor assessments, and audits. AI-powered, containerized, self-hostable. |
| GRC Engineering Lab Builder | Static-site generator for hyper-personalized GRC engineering lab prompts (Claude, ChatGPT, Gemini-compatible) — source. |
| GRClanker | Spec-driven open-source AI GRC CLI — bring your own AI agent (Claude, Codex, Gemini…) to generate Go CLIs for FedRAMP, KEV, EPSS, SCF crosswalks. |
| HashiCorp Sentinel | Embedded policy-as-code framework for Terraform, Vault, Consul, and Nomad — gates infrastructure changes pre-apply. |
| How to Harden | Community-developed open-source hardening guides focused on cloud services and integration / supply-chain attack prevention. |
| Kubewarden | CNCF Kubernetes policy engine; policies as WebAssembly modules in Rust, Go, Rego, CEL, and others. |
| Kyverno | Kubernetes-native policy engine that validates, mutates, and generates resource configurations at admission time. |
| myctrl.tools | Fast, searchable reference site for security compliance controls across frameworks (FedRAMP Rev5, DoD SRG, and more). |
| OPA Gatekeeper | Kubernetes admission controller built on OPA. Enforces Rego policies on cluster resources at admission time. |
| Open Policy Agent (OPA) | General-purpose policy engine for unified policy decisions across the cloud-native stack. |
| Open Source Cybersecurity Training | Free SCORM-compatible interactive security & privacy training modules — phishing, CEO fraud, secure coding, and more (live demo). |
| Prowler | Open-source cloud security platform. Continuous compliance across AWS, Azure, GCP, Kubernetes, M365, and more. |
| Pulumi Policies | CrossGuard policy-as-code for Pulumi infrastructure-as-code, written in TypeScript, Python, or Go. |
| Puppet | Policy-as-code via Puppet manifests; continuous compliance through automated drift detection and remediation. |
| Rego | OPA's declarative policy language. Enables Policy-as-Code evaluation in CI/CD pipelines. |
| riskquant | Netflix's open-source library for quantifying risk via FAIR-based Monte Carlo simulations. |
| Salt Stack | Event-driven configuration management with policy-as-code in SLS files; continuous compliance via reactor and beacon engines. |
| SCF API | API for the Secure Controls Framework (1,400+ controls mapped to 200+ laws, regulations, and frameworks). |
| ScoutSuite | Multi-cloud security auditing tool. Active testing against CIS, PCI DSS, and HIPAA benchmarks. |
| Steampipe | Cloud APIs as SQL tables. Full-state infrastructure queries for evidence populations across 100+ services. |
| Terraform | Declarative infrastructure-as-code for provisioning cloud and SaaS resources. In GRC Engineering, the version-controlled, peer-reviewed source of truth for infrastructure — plan/state output serves as audit evidence, policy-as-code (Sentinel, OPA) gates changes pre-apply, and drift detection surfaces unauthorized configuration changes. |
Books, courses, labs, podcasts, talks, blogs, and communities for learning and practicing GRC Engineering.
| Type | Resource | Author |
|---|---|---|
| Books | GRC Engineering for AWS | AJ Yawn |
| Books | How to Measure Anything in Cybersecurity Risk | Richard Seiersen, Doug Hubbard |
| Books | Measuring and Managing Information Risk: A FAIR Approach | Jack Jones, Jack Freund |
| Books | From Heatmaps to Histograms | Tony Martin-Vegue |
| Books | The Metrics Manifesto | Richard Seiersen |
| Courses | GRC for the Cloud-Native Revolution | Ayoub Fandi |
| Courses | Cybersecurity Foundations: GRC | AJ Yawn |
| Courses | Leveraging AI for GRC | Terra Cooke |
| Courses | Threat Modeling Learning Path | LinkedIn Learning |
| Courses | CGE-P Certification | GRC Engineering Club |
| Labs | GRC Playground | Ashley Pearce · original GitHub repo |
| Labs | GRC Portfolio Labs | AJ Yawn |
| Podcasts | GRC Engineer Podcast | Ayoub Fandi |
| Podcasts | Cyber Stories — GRC Engineering | Day Johnson (feat. Ayoub Fandi) |
| Podcasts | Resilient Cyber — Transforming Compliance | Chris Hughes (feat. AJ Yawn) |
| Podcasts | MYGRCPOV — Rise of GRC Engineering | Monica Reagor (feat. AJ Yawn) |
| Talks & Interviews | BSidesSF 2024 — GRC Engineering in Repository | Varun Gurnaney |
| Talks & Interviews | BSidesSF 2025 — Compliance in DevOps Pipeline | Varun Gurnaney |
| Talks & Interviews | Netflix Security — Risk-based Decision Making | Prashanthi Koutha, Shannon Morrison |
| Talks & Interviews | fwd:cloudsec 2025 — GRC Engineering for AWS | AJ Yawn |
| Talks & Interviews | What is GRC Engineering? | Lloyd Evans |
| Talks & Interviews | Automating Compliance Processes | Lloyd Evans |
| Talks & Interviews | CPA to Cybersecurity Pivot | Steve McMichael (feat. Ayoub Fandi) |
| Talks & Interviews | FAIRCon 2022 — Five Objections to FAIR | Tony Martin-Vegue, Prashanthi Koutha |
| Talks & Interviews | GRC Deep Dive on Cyber Risk Quantification | Steve McMichael (with Richard Seiersen) |
| Blogs & Newsletters | The GRC Engineer Newsletter | Ayoub Fandi |
| Blogs & Newsletters | From Heatmaps to Histograms | Tony Martin-Vegue |
| Blogs & Newsletters | Varun Gurnaney's Medium | Varun Gurnaney |
| Blogs & Newsletters | Netflix TechBlog — Open-Sourcing riskquant | Markus De Shon, Shannon Morrison |
| Community | GRC Engineering Discord | Community Discord server |
| Community | GRC Engineering LinkedIn Group | Community LinkedIn group |
| Community | GRC Engineering Club | Patreon community |
Contributions are welcome. To add or update an entry:
- Fork this repository.
- Edit
README.md— add a row to the relevant table, keeping the existing order (chronological for Timeline, grouped-by-Type for Teachings, alphabetical or thematic otherwise). - Open a pull request with a brief explanation of why the resource belongs in this list.
- Tools: Should be actively maintained, documented, and align with GRC Engineering principles (automation, code-as-source-of-truth, measurable outcomes).
- Teachings: Books, courses, talks, podcasts, blogs, labs, and communities — credible authors and accessible content preferred.
- Terms: Vocabulary that meaningfully distinguishes GRC Engineering from legacy GRC. Keep definitions concise (1–2 sentences).
- Timeline: Verifiable historical milestones with a clear connection to the GRC field.
- Comparison table: Keep bullet items short, parallel in structure between Legacy and GRC Engineering columns, and grouped under one of the five program areas.
The cheatsheet renders this README at runtime, so syntax matters:
- All section tables use standard markdown tables.
- Inside the Comparison table, bullet items within a single cell are separated with
<br>•(literal HTML line break + bullet). - Inline links use
[text](url); bold is**text**; italic is*text*. - Raw HTML (
<u>,<em>,<span class="...">,<br>) is preserved through to the rendered cheatsheet.