Effortless SOC2
Deterministic SOC 2 from a Business-Readable Rulebook
Author meaning once—in Airtable/Excel or JSON using your business vocabulary—and compile the whole stack: schema, RLS, views, SDKs, tests, and auditor-grade evidence. Same rulebook → same system → same proof.
Meaning
Canonical glossary + rule types (definitional, behavioral, derivation) owned by the business.
Mechanization
Compiler targets Postgres/Supabase deterministically with bitemporal schema and deny-by-default RLS.
Proof
Time-boxed audit trails, matrix tests, and evidence bundles that map each decision to a human-readable rule and a policy hash.
Who benefits and how
Use the tools you already live in; get the guarantees you've never had. The rulebook stays business-readable; everything generated is content-addressed and portable.
Product & Operations
Model your business where you already work—Airtable or Excel. See changes reflect in your app instantly, with a readable history of what changed, when, and why.
Engineering
Treat rules as code you didn't have to write. Get deterministic columns, compiled views, automatic migrations, preview environments, and instant rollbacks—pinned to rulebook versions.
GRC & Audit
Traceability from requirement → policy → compiled SQL → data effect. Faster walkthroughs, cleaner sampling, explainable controls, and exportable evidence packs.
Program controls are automated; human procedures—approvals, risk reviews, access certifications, and incident practice—remain in your program and can be linked to our artifacts.
SOC 2 Coverage Matrix
25 features across the compliance landscape
Matrix reflects platform-level technical controls compiled from the rulebook. Program activities remain customer-owned; we provide hooks and signed evidence references.
| Feature | Manual | Self-hosted PG | Supabase | Effortless SOC2 |
|---|---|---|---|---|
| Row-level security (RLS) & roles | ✗ | ✓ | ✓ | ✓ |
| Data integrity & constraints (FK/UNIQUE/CHECK) | ✗ | ✓ | ✓ | ✓ |
| Integrated auth & user management (OAuth/SSO) | ✗ | ✗ | ✓ | ✓ |
| API autogeneration (PostgREST/RPC) | ✗ | ✗ | ✓ | ✓ |
| TLS for client connections | ✗ | ✗ | ✓ | ✓ |
| Encryption at rest | ✗ | ✗ | ✓ | ✓ |
| Automated backups & point-in-time recovery | ✗ | ✗ | ✓ | ✓ |
| Centralized audit logs & access logs | ✗ | ✗ | ✓ | ✓ |
| Real-time subscriptions honoring RLS | ✗ | ✗ | ✓ | ✓ |
| Storage buckets & access policies | ✗ | ✗ | ✓ | ✓ |
| Ontology management (entities, lineage, PII) | ✗ | ✗ | ✗ | ✓ |
| Versioned security policy editor (explainable) | ✗ | ✗ | ✗ | ✓ |
| No-code business rules → DB migrations | ✗ | ✗ | ✗ | ✓ |
| Columns as pure functions (deterministic) | ✗ | ✗ | ✗ | ✓ |
| Single composed view per table (facts + inferences) | ✗ | ✗ | ✗ | ✓ |
| Auto-migration on Airtable & RLS changes | ✗ | ✗ | ✗ | ✓ |
| Policy static analysis (conflicts/gaps) | ✗ | ✗ | ✗ | ✓ |
| Data classification & lineage reports | ✗ | ✗ | ✗ | ✓ |
| Drift detection & rollback (schema/policy) | ✗ | ✗ | ✗ | ✓ |
| Evidence bundle export (control mapping) | ✗ | ✗ | ✗ | ✓ |
| Preview/staging sync of policies & rules | ✗ | ✗ | ✗ | ✓ |
| Change management program (tickets/approvals/evidence) | ✗ | ✗ | ✗ | ✗ |
| Risk assessment & vendor management | ✗ | ✗ | ✗ | ✗ |
| Periodic access reviews (joiner/mover/leaver) | ✗ | ✗ | ✗ | ✗ |
| Incident response testing & tabletop records | ✗ | ✗ | ✗ | ✗ |
Feature highlights
✓ via Supabase: Row-level security (RLS) & roles, Data integrity & constraints (FK/UNIQUE/CHECK), Integrated auth & user management (OAuth/SSO), API autogeneration (PostgREST/RPC), TLS, encryption at rest, backups & PITR, centralized audit/access logs, real-time subscriptions honoring RLS, storage policies
✓ via Effortless SOC2: Ontology management (entities, lineage, PII), versioned security policy editor, no-code rules → DB migrations, deterministic columns, single composed read-view per table, auto-migration on Airtable & RLS changes, policy static analysis, data classification & lineage reports, drift detection & rollback, evidence bundle export, preview/staging sync, business-readable rule exports (RuleSpeak/SBVR-style) emitted with every build
Out of scope (linkable): Change management program, risk & vendor management, periodic access reviews, incident response testing/tabletops. We model these as obligations and link signed evidence from your systems into the bundle.
Reference: Supabase SOC 2 Compliance Documentation. Our artifacts are content-addressed; provenance is enforced by rulebook SHA across docs, SQL, policies, tests, and SDKs.
What you get
🎯 Deterministic compliance
Same rulebook → same schema, policies, SDKs, and tests every time—stamped with commit SHA and policy version.
Determinism here means: given the same rulebook SHA, you can regenerate schema, policies, SDKs, and tests bit-for-bit, and reproduce audit decisions via time-travel queries.
🔍 Explainability by construction
Every allow/deny decision traces to a line in your rulebook and a policy hash in the audit log. Each decision references the rulebook SHA and policy version active at the time.
Every allow/deny includes the natural-language rule, structured rule type, glossary links, and the policy hash—so auditors never decode SQL to understand a decision.
📊 Continuous evidence
Schema diffs, policy text, migration scripts, test results, and audit trails—versioned and auditor-ready. Evidence packs are exportable per environment and time window for auditor sampling.
🔒 Zero live-PII exposure
Your systems run in your tenancy. We ship the controls, not your data.
Common questions
Product & Operations
Engineering & Architecture
GRC & Audit
Governance, Meaning, and Independence
Safety & Multi-Tenancy
Platform & Ecosystem
Technical Deep Dive
For the technically curious: how we achieve deterministic compliance
Framing: the rulebook is the source of meaning and is implementation-independent. Postgres/Supabase are realizations. Every artifact is a derivation stamped with the rulebook SHA. Time is bitemporal (valid_time, txn_time), so "what was true when—and why" is provable.
How it works (rulebook → controls)
- Author meaning: Define a glossary and rule types—definitional (truth), behavioral (must/must-not), derivation (calculations)—in JSON or Airtable/Excel. Each rule has an ID, natural-language statement, and structured form.
- Generate everything: Compiler renders bitemporal schema (tenant_id everywhere), deny-by-default RLS, one canonical read-view per table (S/D/L/A/F = Select/Describe/List/Aggregate/Filter), indexes, OpenAPI, and language SDKs—each artifact stamped with the rulebook SHA.
- Emit human-readable rulebook: Side-by-side RuleSpeak/SBVR-style markdown for auditors and stewards; every policy links back to the natural-language rule and glossary terms.
- Prove it runs as declared: Matrix tests execute
(role × entity × op)across time slices on synthetic data; results are hashed and included in evidence bundles. - Operate with receipts: Append-only audit tables capture subject, tenant, rulebook_sha, policy_version, valid_time, txn_time, and request_id. Time-travel queries re-derive past decisions.
Implementation independence: the rulebook never references tables, views, or RLS. Those are compiled artifacts. Conformance proofs show that each artifact is a faithful realization of the rulebook's semantics.
Controls your auditor cares about
- ✓Access control: RBAC compiled to Postgres RLS; column-level exposure enforced in the read-view layer; deny-by-default.
- ✓Change management: Expand/contract migrations derived from the rulebook, with CI diffs of schema, views, policies, and seeds; rollbacks included.
- ✓Audit logging: Append-only audit tables and database-level logging configured; request IDs propagate from edge → API → SQL; optional read-logging where required.
- ✓Data integrity & retention: FK chains, CHECKs, exclusion constraints for time dimensions; retention policies encoded in the rulebook and materialized as lifecycle jobs.
- ✓Availability & recovery: PITR and restore drills scripted; hot rollups optionally materialized with defined refresh SLOs when flagged in the rulebook.
- ✓Vendor boundaries: JWT claims, key rotation schedules, and subservice inventories represented explicitly in the rulebook; artifacts embed versions for traceability.
The toolchain that keeps everything in lockstep
ssotme:// pipeline—business-readable rulebook in, content-addressed artifacts out. Each step emits deterministic outputs stamped with the same rulebook SHA.
# 1) Ingest business meaning from where you work
$ effortless airtable-to-effortless-rulebook \
-p baseId=app123xyz321 \
-i effortless-rbac.json \
-o effortless-rulebook.json
# Input: glossary + rules in Airtable/Excel/JSON
# Output: canonical rulebook (implementation-independent) + SHA
# 2) Generate human-readable docs for stewards and auditors
$ effortless effortless-rulebook-to-markdown \
-i effortless-rulebook.json \
-o README.md
# Output: RuleSpeak/SBVR-style rules + glossary with stable IDs
# 3) Compile the realization for Postgres/Supabase
$ effortless effortless-rulebook-to-postgres-schema \
-i effortless-rulebook.json \
-o postgres-migration.sql
$ effortless effortless-rulebook-to-postgres-policies \
-i effortless-rulebook.json \
-o drop-recreate-postgres-policies.sql
# Outputs: bitemporal schema + deny-by-default RLS + composed views
# 4) Create synthetic data and run matrix tests
$ effortless effortless-rulebook-to-postgres-mock-data \
-i effortless-rulebook.json \
-o merge-postgres-mock-data.sql
$ effortless effortless-rulebook-to-python-test-suite \
-i effortless-rulebook.json \
-o tests/run-tests.py
# Outputs: (role × entity × op) tests with time slices; results hashed
# 5) Ship client/server SDKs pinned to the rulebook SHA
$ effortless effortless-rulebook-to-go-module -i effortless-rulebook.json -o /go-src/*
$ effortless effortless-rulebook-to-dotnet-ef -i effortless-rulebook.json -o /dotnet/*
$ effortless effortless-rulebook-to-typescript-sdk -i effortless-rulebook.json -o /src/*
# Outputs: SDKs and EF models exactly matching compiled schemas/policiesEach artifact carries the rulebook SHA. Each deploy proves its own pedigree.
Proof-obligations we satisfy on every change
- →Determinism: Input rulebook → reproducible outputs; hashes match across surfaces.
- →Completeness: Exactly one read-view per table exposing declared S/D/L/A/F; exactly one effective policy per
(role, entity, op). - →Soundness: Nothing appears in the API, SDKs, or views that isn't declared in the rulebook.
- →Bidirectional conformance: Executed policy matrix equals the rulebook's ACL matrix.
- →Monotonic auditability: Past decisions are re-derivable via time-travel reads tied to policy versions.
Bottom line: we keep meaning sovereign and make it executable. The rulebook is business-readable and implementation-independent; everything else is a deterministic derivative with proofs. Time is bitemporal, so evidence is not a screenshot—it's a re-derivation.
Where this lands you
A SOC-2-ready platform whose technical controls are code, whose evidence is automatic, and whose semantics never drift.
The rulebook defines truth; everything else follows.
The Conceptual Model Completeness Conjecture (CMCC)
The Conceptual Model Completeness Conjecture (CMCC) is the formal proposition that any well-defined business rule—no matter how complex—can be faithfully decomposed into five fundamental elements in an ACID-compliant datastore where time is treated as just another dimension.
The Five Elements (S/D/L/A/F)
- Schema: The structural definition of entities, attributes, and their constraints
- Data: The actual facts stored in tables with temporal versioning
- Lookups: Foreign-key relationships that connect entities across the model
- Aggregations: Computed rollups, counts, sums, and derived metrics
- Lambda (Calculated Fields): Pure functions that deterministically derive values from other fields
The CMCC Stress Test
Pick the wildest rule you can think of, and then toss it aside as conceptual child's play and pick something ontologically even more outrageous. Then, make a good faith effort to decompose it into Schema, Data, Lookups, Aggregations and Lambda Functions in an ACID Store with Time treated as just another dimension, and watch even the most ludicrous of hypotheticals melt like butter in a warm pan under S, D, L, A, F.
The CMCC is the theoretical foundation that makes Effortless SOC2 possible. By demonstrating that all business logic can be decomposed into Schema, Data, Lookups, Aggregations, and Lambda Functions—each independently testable, auditable, and time-versioned—we can generate not just code, but proof that the implementation matches the business intent.
Why This Matters for Compliance
When your entire system is provably decomposable into S/D/L/A/F within an ACID datastore where time is just another dimension, every audit question becomes a deterministic query. "What was true when—and why" is not approximated—it's re-derived from the exact Schema, Data, Lookups, Aggregations, and Lambda Functions that were active at that moment.