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, certification bodies, regulators, 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
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. There is also no OpenCompliance accreditation role, no OpenCompliance-issued SOC report or CPA opinion, and no regulatory blessing embedded in the current public artifacts.
Boundary 1
No accreditation or certification decision
OpenCompliance can publish better mappings, artifacts, and replay paths. It does not accredit certification bodies, and it does not replace the certification decision of a UKAS-, ANAB-, or other accredited body.
Boundary 2
No CPA opinion or SOC report
The proof layer can narrow evidence, surface overlap, and clarify trust boundaries. It does not issue a SOC report, sign a CPA opinion, or turn a technical corridor into whole-framework assurance by rhetoric.
Boundary 3
No regulator shortcut
OpenCompliance can make obligations, artifacts, and proof limits clearer. It does not replace legal review, regulatory enforcement, or human accountability for privacy, AI, or sector-specific obligations.
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.
Privacy
Hostile privacy-rights scrutiny
The site should survive a reading that asks about user rights, accountability, processors, transfers, and where legal judgment still sits instead of quietly collapsing privacy into security controls.
Cyber
Operational resilience, not badge collection
The documents should read as though they help real teams start with Cyber Essentials, CAF, logging, configuration, and incident readiness, not as though they exist to decorate a launch page with framework names.
Accreditation
Certification and assurance roles stay separate
The public story should make it obvious that accredited certification bodies, CPA firms, and other assurance actors still own their own decisions. OpenCompliance improves their evidence substrate, not their institutional role.
Public Sector
Machine-readable packages must help real workflows
OSCAL, assessment results, conformance checks, and replay bundles should reduce friction for agencies, CSPs, assessors, and tool builders. If they do not, the machine-readable story is ornamental.
AI
AI obligations are role-based and partly non-automatable
The AI layer has to stay honest about provider and deployer duties, human oversight, transparency, and conformity work. The site should make clear where technical checks stop and governance obligations continue.
Market
The wedge must still be useful to real platforms
The project should read as shared infrastructure for vendors, customers, and auditors, not as an anti-vendor club. If the category story makes coalition-building harder, the docs are failing the market test.
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
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, certification and accreditation readers, privacy counsel, standards maintainers, public-sector assessors, and public-interest reviewers before treating the documents as settled.