Foundation Design

Build the proof commons in a neutral home.

OpenCompliance should not look like one vendor's side project with a good essay attached. If the semantic layer is meant to be shared by vendors, customers, auditors, and end users, it needs a public home, explicit anti-capture rules, and a review process that punishes hand-waving.

0 sponsor-weighted votes in the proposed model

7 day-one public repositories in the proposed org map

3 artifact classes kept separate: proofs, attestations, judgment

1 hard honesty rule: say what is not built yet

Why A Foundation

Shared semantics should not live inside one vendor's black box.

The public value in OpenCompliance is the semantic layer: open schemas, open mappings, Lean 4 control corridors, conformance tests, and replayable public artifacts. That layer becomes more credible if it is stewarded in a neutral home rather than treated as a feature inside one company's product stack.

The aim is to elevate the whole market. Commercial platforms still compete on workflow, integrations, services, trust-centre UX, and customer support. The foundation only governs the shared substrate.

Who Benefits

Vendors, customers, and users all get something real.

Vendors: less duplicated mapping work, less semantic lock-in pressure, and fewer incentives to defend opaque trust claims.
Customers: clearer artifacts, better portability, and a more direct way to challenge weak evidence or over-broad claims.
End users: a stronger and more inspectable chain of trust, even if they never read the specs themselves.

What Exists Today

The project already has a public docs site, a detailed PRD, a trust model, a publication strategy, seeded public repos for specs/examples/conformance/schema work, synthetic ExampleCo bundles for public review, and an initial Lean 4 corridor showing how a narrow proof slice can stay smaller than the surrounding compliance story.

What Does Not Exist Yet

There is no incorporated foundation, no elected steering group, no dues model, no public conformance programme, and no stable reference implementation. Any public language that implies otherwise is wrong.

Charter principles

Principle 1

Do not flatten epistemology

Proofs, signed attestations, and judgment calls are different things. The commons must keep them separate instead of compressing them into one status light.

Principle 2

Keep semantics public

Mappings, proof boundaries, schemas, and conformance rules should be versioned, reviewable, and reusable by anyone.

Principle 3

Sponsors fund work, not meaning

Commercial support is welcome. Buying extra control over normative text is not.

Principle 4

Stay explicit about limits

If something is incomplete, mark it incomplete. If legal judgment is still required, say so directly.

Principle 5

Publish inspectable trust chains

Prefer signed artifacts, canonical digests, append-only transparency, witness reruns, and visible revocation over static PDFs and unverifiable prose.

Principle 6

Optimise for the full trust chain

The project should improve trust for vendors, their customers, and the people at the far end of the chain who bear the real-world consequences.

Sponsor model

Participation

Four classes, one public process

Maintainers: earn influence through sustained public work.
Sponsors: fund staff time, infrastructure, or workstreams, but do not buy votes.
Public-interest reviewers: privacy, standards, buyer-side, and academic voices who can challenge the work without paying.
Adopters: use the outputs, file issues, and feed back operational reality.

Anti-Capture

The sponsor rules need to be boring and hard.

No sponsor-weighted voting.
No closed normative process.
No secret compatibility carve-outs.
Mandatory conflict disclosure for maintainers and reviewers.
No certification, endorsement, or trust-mark implication from sponsorship.

Public organisation layout

opencompliance-foundation/
  site                public docs and project explanation
  governance          charter, governance, sponsor model, conflicts
  specs               normative public artifact formats
  lean4-controls      formal control corridor in Lean 4
  evidence-schema     typed evidence claim schemas
  conformance         tests and verifier behaviour checks
  examples            synthetic bundles and replay fixtures

later, only when justified:
  reference-verifier
  connectors

Live Entry Points

The org map is not theoretical anymore.

The public organization exists, and the site, governance, specs, examples, conformance, evidence-schema, and Lean 4 controls repos are all live. The repository map page links each one directly.

GitHub org Repository map Governance repo

Canonical Rule

The website should never hide the repos.

If someone can read the public site but cannot find the public repos quickly, the publication surface is underspecified. The site now links the GitHub organization and repo map directly because the source should be easy to inspect.

Governance Repo

Day-one documents should be concrete.

Charter: the project mission, scope, and anti-theatre boundaries.
Governance: roles, decision types, review periods, and maintainer rules.
Conflicts: disclosure, recusal, and anti-capture hygiene.
Sponsor model: how vendors can fund work without buying meaning.
Release and sign-off: how public artifacts become real releases instead of mutable draft prose.

Export Boundary

Manifest discipline still matters.

The first exports started with the public site and governance repo, but the same rule now governs every public seed repo: site, governance, specs, examples, conformance, evidence-schema, and Lean controls all ship from explicit allow-lists.

The boundary rule stays the same: if a path is not on the allow-list, it does not ship. The public examples layer adds one more rule on top: synthetic by default, or explicit public approval if not.

Boundary

The private working repo should remain private. Public repos should be fed by explicit export manifests and release checks, not by wishful thinking or whole-repo mirroring.

Publication strategy

Trust

The foundation and the trust model are linked. If the public home cannot explain its signer rules, replay story, and revocation story clearly, the project is not ready to claim that it improves the industry.

Trust model

Peer review discipline

Round 0

Honesty gate

Run a blunt pre-flight review first. Kill hype, separate current reality from aspiration, and make every document say what is not built yet.

Round 1

Verifier and trust chain

Pressure-test the formal methods story, signed artifacts, transparency, witness reruns, and conformance claims.

Round 2

Law, privacy, and compliance

Force the docs to survive hostile readings from privacy, legal-formalisation, and compliance-semantics perspectives.

Round 3

Security and incentives

Ask how the trust claims can be gamed, how the incentives can drift, and which shortcuts the market will try the moment the docs look successful.

Round 4

Foundation realism

Check that the governance and funding model could survive real contributors, real sponsors, and real maintenance burden.

Round 5

Actual industry review

Bring in vendors, buyers, auditors, privacy counsel, standards maintainers, and public-interest reviewers before treating the documents as settled.

The right public tone is not "trust us more." It is "here is the exact machinery, here are the limits, and here is how to challenge it."