Product Pitch
The short version
OpenCompliance is a proof-carrying compliance engine, not a checklist dashboard. It ingests controls and evidence, routes each obligation into proof, attestation, or human review, then returns either a certificate or a typed punch-list together with a trust-surface report that states exactly what was proved, assumed, attested, excluded, or deferred to judgment.
The point is not maximal automation. The point is epistemic honesty with better artifacts. The first useful deployment is a narrow, buyer-facing assurance package that startups, trust-management vendors, auditors, and certification bodies can all inspect without pretending the whole framework has been mechanised.
Why This Matters
The industry problem
Most compliance tooling collapses very different kinds of reasoning into one dashboard status. A runtime proof, a stale screenshot, a manually uploaded PDF, and a partner attestation often end up looking identical in the UI.
OpenCompliance tries to break that habit by making the boundary between proof and assertion visible and machine-readable. That makes it complementary to trust-management platforms, audit workflows, and certification programmes rather than a claim to replace them with one new dashboard.
OSCAL Boundary
OSCAL is necessary, but not sufficient
OSCAL gives OpenCompliance a standards-aligned wire format for catalogs, profiles, mappings, and assessment-style artifacts. It does not by itself provide typed evidence semantics, theorem proving, trust-policy evaluation, trust-surface reporting, signatures, transparency logging, or witness replay.
OpenCompliance keeps OSCAL as the external contract, then adds those missing verification and publication layers on top.
Builders
They get an architecture target
Engineers need more than “be compliant.” They need a concrete shape for proofs, attestations, rights handling, action logs, retention, and escalation paths.
Buyers
They get inspectable evidence
Security and procurement teams can ask for scoped artifacts, replay bundles, and trust-surface reports instead of accepting one undifferentiated badge.
Auditors And Regulators
They get reconstruction, not slogans
Reviewers benefit when purpose, lawful-basis context, approvals, overrides, and action history are explicit enough to inspect after the fact.
People Affected
They get a better chance to contest outcomes
The end user benefit is not a prettier certificate. It is a system that is easier to question, explain, correct, erase, and stop when something has gone wrong.
Step 1
Ingest the corridor
OpenCompliance imports the target control profile and the matching OSCAL mappings for the in-scope corridor.
Step 2
Collect typed evidence
Machine evidence, human attestations, and exclusions are stored as typed claims with signer, actor role, trust-policy, scope, source, freshness, and control mappings.
Step 3
Classify each obligation
Every control is routed into one of four buckets: decidable, attestation, judgment, or mixed.
Step 4
Run Lean 4 on the technical slice
Only the decidable corridor enters the proof kernel. The proof bundle now records which proved claims entered the public Lean batch, which LegalLean typed modules define the current proof-versus-boundary vocabulary, and which public-corridor claims are now runtime-consumed from Lean rather than re-decided only in Python.
Step 5
Bind the output to artifacts
Proof bundles, certificates, and revocations become signed artifacts with canonical digests that can be logged and replayed later.
Step 6
Return a clear verdict
The output is a certificate or typed punch-list plus a trust-surface report saying what is proved, attested, judgment-dependent, or out of scope.
Boundary
OpenCompliance does not replace licensed CPA firms, ISO certification bodies, accreditation bodies, regulators, or internal human judgment. It improves the quality, structure, and inspectability of evidence that those parties review.
Physical controls, policy adequacy, board oversight, and other normative questions remain partly or wholly attestation-driven or judgment-driven.
MVP Corridor
The initial scope is deliberately narrow: the technical overlap corridor between SOC 2 Security and ISO 27001. Access-control invariants, MFA enforcement, typed access-review exports, scoped password policy, managed web-application-firewall state, unique named infrastructure identities, customer and environment segmentation, centralized monitoring, repository protections, CI policy guarantees, secure baseline configuration, update hygiene, AI output disclosure, and similar inspectable controls come first. The public fixture set now also includes dedicated synthetic cyber-baseline and AI-governance corridors, and the medium/issued/cyber/AI slices now prove additional access-review, repository-integrity, CI-policy, secure-baseline, security-update, malware-protection, and disclosure predicates instead of leaving that wave as aspirational only. The reviewed mapping pilot remains broader than the implemented proofs, covering public exact anchors across GDPR, IRAP, Cyber Essentials, NCSC CAF, NIST CSF 2.0, NIST SP 800-53, the EU AI Act, the EU GPAI Code of Practice, NIST AI RMF, NIST AI 600-1, NIST AI 100-4, NIST AI 700-2, and the first ETSI AI entries, while keeping the ISO AI standards at candidate status until licensed review exists. The LegalLean runtime handoff is now live across every current public fixture, even though that still falls short of a released live-evidence verifier.
Architecture
The runtime pipeline, components, and how proofs, attestations, and publication-safe artifacts fit together.
Open architecture
Trust Model
How signed artifacts, transparency logs, witness reruns, and fail-closed issuance make the system tamper-evident without blockchain.
Open trust model
Agentic AI
How purpose limitation, rights handling, explainability, retention, and supply-chain roles should appear when an AI system can initiate actions on its own.
Open agentic-AI boundary
Certification
What OpenCompliance can already prove, what still relies on attestation or judgment, and what accredited certifiers or assurance firms still decide.
Open certification ladder
Essay
Why an open, limitation-aware proof layer would move the compliance industry forward even before it solves every control.
Read the essay
Landscape
Where OpenCompliance overlaps with Ceel, Vanta, and Drata, and why the open-source proof layer still matters.
Open landscape
Examples
The public repos now carry blocked, stale-evidence, cyber-baseline, AI-governance, and successful synthetic ExampleCo corridors, persisted classification artifacts, a first mixed-control decomposition in the medium corridor, additional Lean-backed password-policy, managed-WAF, centralized-monitoring, network-boundary, plaintext-transport, encryption-at-rest, unique-infrastructure-identity, and segmentation proofs, raw source-export inputs, boundary-aware proof-runner metadata, a LegalLean typed-boundary summary, signed governance evidence, public transparency logs, a lifecycle drift pack, typed claims, signature manifests, scoped certificates or punch-lists, OSCAL-shaped projections, replayable witness receipts, and now also machine-checkable AI provenance plus signed evaluation and data-quality governance evidence in the public AI corridor.
Open examples
Run public verifier
Showcase
A company-level ExampleCo walkthrough now shows how a hypothetical team can aggregate four corridor results into one honest buyer-facing assurance story without overstating full-framework compliance.
Open showcase
Lifecycle
See how a source change maps to impacted controls, triggers fail-closed revocation or re-verification, and blocks higher-level composition until trust is restored.
Open lifecycle
Auditor Search
Explore publication-safe AICPA, UKAS, PCAOB, ANAB, and FedRAMP assurance records by source, jurisdiction, source-specific signals, recency, and visible public scope with explicit provenance.
Open auditor search
Vendor Search
Search a source-aware market map of trust and compliance platforms by segment, headquarters, supported frameworks, public assurance signals, age, and employee band.
Open vendor search
Foundation
Why the shared semantic layer should live in a neutral home, how sponsors fit in, and how the documents should be peer reviewed.
Open foundation
GitHub Org
The public root is explicit
The published project surface is organized under a single GitHub organization so people can inspect the site, specs, examples, schemas, validators, and Lean corridor directly.
Open GitHub org
Repository Map
Start with the repo directory
If you only read one page before diving into GitHub, read the repository map. It tells you which repo is normative, which repo is executable, and which repo is only explanatory.
Open repository map
Site Repo
What you are reading now
The public docs bundle, including the trust model, roadmap, publication plan, and repository map, lives in its own repo.
Open site repo
Specs Repo
Normative public semantics
Artifact contracts, mapping methodology, control-boundary metadata, exact-anchor review pilots, and versioning rules belong in the public specs repo.
Open specs repo
Examples Repo
Synthetic replay bundles
The ExampleCo corridors, lifecycle packs, witness receipts, transparency logs, and OSCAL-shaped projections are published as synthetic public examples.
Open examples repo
Conformance Repo
Executable checks
The public validator and conformance vectors are published separately so the examples and schemas can be checked rather than trusted by prose.
Open conformance repo
Evidence Schema
Typed claim surface
The public evidence envelope and claim-type payload schemas are published on their own so others can integrate or critique them independently.
Open schema repo
Lean 4 Controls
Narrow proof corridor
The public Lean package shows exactly what the current proof slice covers, imports LegalLean for typed boundary work, and makes the proof boundary explicit instead of leaving it as prose alone.
Open Lean repo