Why Compliance Needs an Open Foundation

The compliance industry does not only have a workflow problem. It has a semantics problem.

Commercial platforms have done real work. They automate evidence collection, reduce audit overhead, keep policies in one place, and save teams an enormous amount of time. That matters. I do not think the right move is to sneer at Vanta, Drata, Secureframe, Ceel, or anyone else trying to make this market less painful.

But there is still a deeper weakness underneath the dashboards.

Too much of compliance still depends on private rule engines, private mappings, consultant lore, and polished outputs whose epistemic status is hard to inspect. A customer sees a green result, a trust page, or a report package, but often cannot tell what was mechanically checked, what was uploaded manually, what was signed by a human, what was inferred by software, and what remained a judgment call.

That is a bad place for the market to stay.

The case for an OpenCompliance Foundation is not that every vendor is doing something wrong. The case is that the industry would be stronger if more of the reasoning substrate were public, portable, and contestable.

For now, "foundation" means a public project, a governance direction, and a proposed commons. It does not yet mean a formed legal foundation entity.

The Core Distinction

The most important distinction in OpenCompliance is also the simplest:

• some controls can be proved from machine state,
• some controls can only be supported by signed attestations,
• some controls remain matters of human judgment.

Those are not the same thing, and a serious assurance system should stop pretending that they are.

If a control says that MFA is enforced for a scoped set of identities, that may be machine-checkable. If a control says that staff completed training, that is more naturally an attested claim. If a control asks whether risk treatment is appropriate or whether a policy is adequate in context, that is judgment. A trustworthy artifact should say which bucket each claim belongs to.

That is the heart of OpenCompliance. Not "AI does compliance faster." Not "replace auditors." Not "fully automate ISO 27001." The narrower and more defensible claim is this: build an open proof layer that makes the boundary between proof, attestation, and judgment visible.

What OpenCompliance Is

OpenCompliance is not an all-in-one compliance operating system. It is not a replacement for a trust center. It is not an audit opinion. It is not a promise that all of ISO 27001, SOC 2, IRAP, or GDPR can be reduced to theorem proving.

It is a proposal for a shared public substrate underneath those workflows. The intended substrate includes:

• open control mappings,
• typed evidence claim schemas,
• Lean 4 control encodings for the narrow machine-checkable corridor,
• trust-surface reports that distinguish proof from attestation from judgment,
• tamper-evident proof bundles and revocation records,
• conformance tests so different implementations can be checked against the same artifact formats.

Those are target artifact types and target interfaces. They are not all implemented today.

That means the right comparison is not "Is this better than a vendor dashboard?" The right comparison is "Should the semantics underneath vendor dashboards be locked up in private systems forever?"

I do not think they should.

Why An Open Layer Helps The Whole Stack

An open proof layer would help three different groups at once.

1. Vendors

The obvious objection is that vendors would not want this because it commoditises them.

I think that is only partly true. An open layer does commoditise one thing: opaque semantics. That is a feature.

But it still leaves a lot of room for commercial value:

• integrations,
• workflow design,
• evidence collection UX,
• auditor relationships,
• policy management,
• support,
• continuous monitoring,
• trust-center presentation,
• implementation services,
• managed review operations.

In other words, vendors can still compete where software companies usually should compete: on execution, reliability, user experience, support, and distribution. What becomes harder is competing by hiding the control mapping and hoping nobody asks how the sausage was made.

That is healthy.

2. Customers

Customers benefit because they get more portable and more legible artifacts.

Instead of being trapped inside one vendor's internal interpretation of a standard, a customer can see:

• what exact control mapping was used,
• what evidence was in scope,
• which claims were proved,
• which claims were attested,
• which claims still required judgment,
• and what changed between one verification run and the next.

That makes switching vendors easier, but more importantly it makes understanding the result easier.

3. End Users And The People Behind The Supply Chain

The final beneficiaries are the people furthest from the procurement process and closest to the consequences.

If an AI vendor, law firm, healthcare provider, or infrastructure company presents better assurance artifacts to its customers, those customers can make better decisions. If those customers make better decisions, the users who rely on those services get a more trustworthy system at the far end of the chain.

That is the beneficiary chain I care about:

• vendors get a clearer substrate,
• customers get clearer evidence,
• end users get a stronger trust chain.

If the foundation does not improve that chain, it is not worth building.

Formalisation Is Not Politically Neutral

It is worth stating this directly.

Making compliance semantics more public is not a neutral move. It shifts power.

It makes it harder for vendors to treat their internal control logic as a moat. It makes it easier for customers to compare artifacts across tools. It gives auditors and buyers a clearer place to disagree with a result. It also removes some of the ambiguity that lets weak claims hide inside polished language.

I think that shift is good, but it is still a shift. The foundation should not pretend it is merely adding a technical convenience layer. It is changing who gets to inspect, challenge, and reuse the reasoning that sits underneath assurance claims.

This Does Not Start From Zero

OpenCompliance is not a claim that the field has been empty until now.

The project is explicitly downstream of prior art:

• OSCAL already gives us a machine-readable way to represent controls and related assessment artifacts.
• Lean 4 gives us a serious proof language and kernel for the parts of the corridor that really are formalizable.
• Sigstore, in-toto, and SLSA already show how signing, provenance, transparency, and replay can work without resorting to blockchain theatre.
• Existing compliance platforms already know how painful evidence collection, audit coordination, and customer questionnaires are in practice.

The point is not to replace that body of work. The point is to combine the best parts of it into a more inspectable assurance layer.

What Exists Today

This needs to be stated plainly.

Today, OpenCompliance exists as an early public proposal, not as a mature foundation and not as a production-grade verifier.

What exists today:

• a public GitHub organisation,
• a live public site at opencompliancefoundation.com,
• a repository directory page at opencompliancefoundation.com/repositories.html,
• draft governance documents,
• seven populated public repositories for site, governance, specs, lean4-controls, evidence-schema, conformance, and examples,
• a public organisation profile and direct repository entry point at github.com/opencompliance-foundation,
• a detailed private PRD and design model for the first verification corridor,
• a concrete trust model for proof bundles, transparency, witnesses, and public-safe artifacts,
• a narrow buildable Lean 4 proof corridor for synthetic controls,
• a populated public conformance layer with validators and vectors,
• synthetic public example corridors, OSCAL-shaped seed artifacts, and replayable proof bundles.

That is real work. It is not nothing.

But it is still early.

What Does Not Exist Yet

This also needs to be stated plainly.

What does not exist yet:

• no stable public reference verifier,
• no reviewed clause-level public mapping corpus for ISO 27001 or SOC 2,
• no released Lean 4 control library that covers a broad, auditor-meaningful slice of ISO 27001 or SOC 2,
• no public witness network or independent log monitors,
• no live public connector layer against real customer systems,
• no broad maintainer community,
• no legal foundation entity or independent institutional governance beyond the initial proposal documents,
• no basis for claiming that the project is already an industry standard.

Calling this a finished foundation today would be dishonest.

At the moment, it is a proposal with public infrastructure, draft governance, and a clear technical direction. That is enough to start a serious conversation. It is not enough to declare victory.

Why The Open Part Matters

The hardest part of formal compliance is not theorem proving after the meaning is already known. The hardest part is specifying what a control actually means in a way that survives scrutiny.

What exactly does one control require?

Which fragment of it is machine-state?
Which fragment is an attestation?
Which fragment is legal or managerial judgment?
Which fragments overlap between ISO 27001 and SOC 2?
Which fragments only look similar until you try to encode them?

Right now, too much of that sits in private spreadsheets and proprietary policy engines.

That is a strategic mistake for the industry. Shared semantics should be argued over in the open, versioned in the open, and improved in the open. Not because open source magically solves hard institutional problems, but because it makes the hard parts visible.

Why The Foundation Model Matters

The foundation framing matters because this should not read as a feature page for one company.

If OpenCompliance lives only as a proprietary module inside one vendor, then every claim about neutrality, transparency, and shared semantics becomes weaker. The whole point is to create a space where vendors, auditors, customers, formal methods researchers, privacy lawyers, and security engineers can contribute to a common layer without first agreeing to buy one platform.

That is also why anti-capture rules matter from day one.

Sponsors should be able to fund the work. They should not be able to buy control over the spec because they wrote the largest cheque. If this becomes a pay-to-steer standards body, it will reproduce the same trust problem in a more respectable outfit.

A Commons Needs Maintenance, Not Just Ideals

A serious open foundation cannot run on vibes and spare evenings.

If the work becomes useful, it will create ongoing maintenance costs:

• reviewing mapping changes,
• publishing releases,
• triaging schema questions,
• handling normative disputes,
• running conformance checks,
• and keeping governance boring, predictable, and fair.

That means the project needs more than one founder with a strong opinion. It needs maintainers, documented review paths, sponsor funding that does not buy control, and a clear expectation that stewardship is real work. An open standard that depends on one exhausted person eventually becomes another abandoned repository with a noble README.

The Public And Private Boundary

The public/private boundary also has to be explicit.

Public:

• specs,
• schemas,
• governance docs,
• conformance fixtures,
• public-safe examples,
• trust model documents,
• witness and revocation formats.

Private:

• customer-specific evidence,
• personal data and processor details that are not safe to disclose publicly,
• customer secrets,
• connector credentials,
• unpublished implementation work,
• internal review notes that are not safe to disclose,
• any artifact that would expose sensitive operational detail.

The goal is not radical transparency about customer systems. The goal is radical clarity about the artifact formats and reasoning model.

That matters especially for GDPR-heavy assurance work. Cross-border transfers, processor chains, retention practices, and lawful-basis questions often combine machine state with legal interpretation and sensitive data. A public proof layer should make those boundaries clearer, not accidentally dump private operational or personal data into a public artifact stream.

How To Make It Hard To Cheat

If OpenCompliance is real, it cannot just be open source in the lazy sense of "the code is on GitHub somewhere."

It has to be hard to shortcut.

That means:

• evidence claims should be signed,
• proof bundles should be reproducible,
• public digests should be logged append-only,
• revocations should be visible,
• certificate outputs should fail closed when required intermediate artifacts are missing,
• and third parties should be able to replay a public-safe verification bundle and get the same result.

That is the closest thing compliance has to the discipline that supply-chain security has been building around provenance and transparency.

No, this does not make fraud impossible.

It does make silent mutation, vague hand-waving, and magical dashboard outputs much harder to get away with.

Goodhart Still Applies

A formal proof layer does not solve Goodhart's Law. It may intensify it if used badly.

The danger is obvious: teams optimise for the slice of compliance that is easiest to formalise, then mistake a clean proof surface for actual trustworthiness. That would be a mistake.

The answer is not to avoid formalisation. The answer is to keep the categories honest.

A trust-surface report should never flatten everything into a single green badge. It should say:

• this was proved,
• this was attested,
• this required judgment,
• this was excluded,
• this remains unresolved.

If a system cannot say that, it should not pretend to be more rigorous merely because it emits cryptographic hashes.

Productive Ambiguity Is Real

Some ambiguity in compliance and governance is not accidental. It is load-bearing.

Standards often leave room for context because organisations differ, risks differ, jurisdictions differ, and reasonable professionals sometimes disagree. A foundation that tries to formalise everything would end up either lying or trivialising the standards.

So the right goal is not to eliminate ambiguity. It is to expose where ambiguity still governs the outcome.

That is why the proof, attestation, judgment split matters so much. It preserves the boundary instead of pretending the boundary disappeared.

It also matters for privacy. Some GDPR-related questions can be supported by machine evidence, but many still depend on legal interpretation, documented purpose limitation, contractual processor arrangements, and context-specific judgment. Any system that implies otherwise is overstating what it knows.

Three Strong Objections

The strongest version of this idea has to answer its own objections.

Objection 1: "This is just an open-source clone of existing compliance vendors."

It should not be. If that is what it becomes, it has missed the point.

The right target is the shared substrate underneath the workflow layer, not the workflow layer itself. Commercial platforms are still the natural place for integrations, onboarding, operational support, trust-center UX, and audit execution. The foundation should make those systems more legible, not try to replace them with a worse copy.

Objection 2: "If most controls still need people, this is not very useful."

That would only be true if the only useful output were a fully automated certificate.

In practice, a system that cleanly separates machine proof from attestation from judgment is already a major improvement over one that flattens all three into one undifferentiated status light.

Even partial precision is valuable when the alternative is epistemic mud.

Objection 3: "Open artifacts will leak sensitive customer detail."

Only if the public boundary is designed badly.

The foundation should publish public-safe schemas, example bundles, digests, witness receipts, and replay mechanisms. It should not publish private customer evidence or confidential operating detail. Public transparency about formats is compatible with private handling of sensitive payloads.

What People Can Build Now

This should not wait for a mythical finished platform.

There are concrete contributions people could make immediately:

• map one narrow SOC 2 or ISO 27001 control family into a public machine-readable schema,
• write public-safe example evidence bundles,
• define canonical serialisation rules for one claim type,
• publish conformance vectors for a trust-surface report,
• build witness tooling for replaying a public bundle,
• review the governance documents for anti-capture failure modes,
• document where a control stops being machine-checkable and becomes attestation or judgment.

That is enough to make progress. The first useful version of this work will come from many small acts of semantic clarification, not from one grand launch.

If you want to inspect the current public state rather than just read this essay, start with opencompliancefoundation.com, then the repository directory at opencompliancefoundation.com/repositories.html, then the public GitHub organisation at github.com/opencompliance-foundation.

What I Would Like To See Happen

I would like to see this become a place where competitors can still collaborate.

That means:

• compliance vendors contributing to shared formats without giving up their product differentiation,
• auditors helping define where formal proof stops and professional judgment begins,
• formal methods researchers helping make the provable corridor real,
• privacy and security critics stress-testing the governance so the project does not drift into theatre,
• customers insisting on artifacts that are portable and inspectable rather than merely polished.

If vendors such as Vanta, Drata, Secureframe, Ceel, and others eventually chose to support this kind of commons, that would be a good sign for the whole market. Not because they would stop competing, but because they would be competing on top of a clearer floor.

Why I Think This Is Worth Doing

I care about this because I spend my time at the boundary between formal methods, AI systems, and operational reality. The same pattern keeps showing up: the tooling gets better, the interface gets cleaner, the sales pitch gets sharper, but the reasoning surface often stays opaque.

Compliance is too important to remain mostly opaque.

The right ambition is not to abolish auditors, automate judgment, or pretend that every standard is secretly a theorem. The right ambition is smaller and better: make assurance artifacts more inspectable, more replayable, more portable, and more honest.

That would help the vendors.

It would help their customers.

And most importantly, it would help the people downstream who rely on both.

That is what I want the OpenCompliance Foundation to try to do.

About the author: Eduardo Aguilar Pelaez is CTO and co-founder at Legal Engine Ltd. He writes about formal methods, AI systems, legal technology, and the boundary between proof and operational reality. The public OpenCompliance proposal lives at opencompliancefoundation.com, with public repositories under github.com/opencompliance-foundation.