Publication Strategy

Publish only what is meant to be public.

The cleanest model is a private working repository with explicit public export bundles. Docs, open specs, and public example fixtures each get their own allow-listed release target instead of mirroring the whole repository by accident.

Recommended Split

Seven public repos

Docs repo: the static site under docs/, suitable for GitHub Pages.
Governance repo: charter, governance, conflicts, sponsor model, and release policy.
Specs repo: draft artifact formats for trust-surface reports, proof bundles, witness receipts, revocations, signed-artifact manifests, and versioning rules.
Examples repo: replay bundles, lifecycle examples, signature manifests, public keys, and other synthetic public test data.
Conformance repo: descriptive vectors, witness expectations, and an executable validator tied to the public examples.
Evidence-schema repo: typed evidence claim envelopes, signer and provenance fields, and public claim-type payload schemas.
Lean4-controls repo: a buildable Lean 4 corridor with explicit proof-boundary notes tied to the synthetic example bundles.

Why Split Them

Different audiences, different risk

The docs need to be simple and public. The open specs need reviewable semantics and versioning. The example bundles need public-safe synthetic fixtures. The private working repo may still contain internal experiments, private evidence, or unpublished runtime work that should never leak into a public mirror.

Submodule-friendly model

private monorepo
  projects/dev/opencompliance/docs/              -> public docs repo or docs submodule
  projects/dev/opencompliance/foundation/        -> public governance repo or governance submodule
  projects/dev/opencompliance/open-specs/        -> public specs repo or specs submodule
  projects/dev/opencompliance/fixtures/public/   -> public examples repo or examples submodule
  projects/dev/opencompliance/conformance/       -> public conformance repo or conformance submodule
  projects/dev/opencompliance/evidence-schema/   -> public schema repo or schema submodule
  projects/dev/opencompliance/lean4-controls/    -> public Lean repo or Lean submodule

private only
  projects/dev/opencompliance/src/
  projects/dev/opencompliance/fixtures/internal/
  projects/dev/opencompliance/.env
  projects/dev/opencompliance/secrets/

Rule 1

Allow-list every release

Publication should be manifest-driven. If a path is not listed for a public bundle, it does not ship.

Rule 2

Run public-boundary checks in CI

Secret scans, path checks, and artifact-manifest validation should block release before anything reaches the mirror target.

Rule 3

Keep docs independently publishable

The docs bundle should work as a standalone GitHub Pages site so it can be published without exposing the rest of the project.

Rule 4

Only ship synthetic examples by default

The public examples should be synthetic unless a real example has been explicitly approved for release. Public review works fine without customer leakage.

What the public repos now carry

Examples

Four corridor bundles plus lifecycle and signing packs

The public `examples` repo now has a small `minimal` blocked bundle, a `failed` corridor that demonstrates present-but-non-compliant evidence, a richer `medium` blocked corridor with raw synthetic source exports spanning repo policy, CI policy, IAM, cloud, and signed attestations, plus checked-in verification results for the repo and CI controls themselves, an `issued` ExampleCo corridor that demonstrates the narrow certificate path, a lifecycle pack showing drift, delta rechecks, and composed component certificates, and a signing pack with a synthetic public key plus signed-artifact manifests. Together they show persisted classification artifacts, typed punch-lists, scoped certificates, replay bundles, transparency logs, inclusion proofs, OSCAL-shaped projections, witness receipts, lifecycle artifacts, and public signature verification without leaking private data.

Conformance

The validator now checks all four corridors

The public `conformance` repo validates typed payload schemas, persisted classification artifacts, proof-bundle mappings, witness digests, transparency logs, inclusion proofs, corridor control references, and OSCAL projection consistency across the four synthetic corridor bundles. The lifecycle pack is public and executable, but it is still a descriptive example rather than part of the conformance matrix.

Publication options

Option A

One-way export to public repos

Keep the monorepo as the source of truth, generate release manifests, and push allow-listed bundles into separate public repositories. This is the safest operational model.

Option B

Public repos as submodules

Mount the public repositories as submodules and publish into them from the private repo. This helps reuse and external contribution, but the publication boundary still needs manifest checks or the submodule will just become another leak path.

Immediate next step

Keep the exports synchronized, expand conformance honestly, add lifecycle and composition checks without bluffing, and resist the temptation to publish a "reference verifier" before the public artifacts and proof corridor are stable enough to support it.