Standards

Standards

Trust & Compliance Infrastructure: converting governance from policy into verifiable, portable proof, enforcement, and receipts.

Procurement‑grade Offline‑verifiable Public‑safe draft
Download immutable deposit (Zenodo) Download KCS Spec (PDF) Verify offline

Canonical pointers here; immutable deposit on Zenodo.

ReleaseKCS v1.0.0 (R3) • 2026‑02‑12. Deposit: v1.0.0‑R3.2 (record 18623859 • 2026‑02‑13).
PinsFingerprint (OpenPGP / Ed25519): 6075A8FD8EDBD3FC2B9108324933EB1FE08BCFF8. Mismatch MUST yield HOLD (UNTRUSTED).
VerifyVerify RECORD_SHA256SUMS.asc → RECORD_SHA256SUMS, then sha256sum -c. (Bundle ZIP: SHA256SUMS.asc → SHA256SUMS, then sha256sum -c.)
RotationKey changes require a new pinned fingerprint + Zenodo update. Silent rotation is prohibited.
Change controlCorrections are replacement + deprecation (new deposit). Meaning changes in‑place are prohibited.
ReportIntegrity/security: security@meridianverity.com • Licensing/incorporation: licensing@meridianverity.com
Draft previewExpect HOLD

ALP‑L1: Agent Lockdown Profile (draft)

Fail‑closed interoperability profile for enterprise agent runtimes. UNSIGNED_PREVIEW — not procurement‑grade — EXPECT HOLD.

Zenodo record 18682584 Download ALP‑L1 (PDF)
Candidate objectNow public

Falsification Receipt

Falsification Receipt is a public candidate spec and remains subject to revision until witnessed replay operations mature further.

Read replay spec Implementer guide
Offline verification
PinnedTrust anchor

Signing key fingerprint (pinned)

Trust is pinned by fingerprint, not by hosting location. If the fingerprint differs, treat the deposit as untrusted (HOLD).

Pinned fingerprint
6075A8FD8EDBD3FC2B9108324933EB1FE08BCFF8
6075 A8FD 8EDB D3FC 2B91 0832 4933 EB1F E08B CFF8
Download from ZenodoReport
RequiredRecord integrity

Record integrity (required)

# From Zenodo deposit:
#   - artifact signing pubkey (see KEYS/ in the bundle)
#   - RECORD_SHA256SUMS, RECORD_SHA256SUMS.asc

# Import pinned public key (do not rely on keyservers)
gpg --import KEYS/mvg_zenodo_artifact_signing_pubkey.asc

# Verify signed checksums, then verify all files
gpg --verify RECORD_SHA256SUMS.asc RECORD_SHA256SUMS
sha256sum -c RECORD_SHA256SUMS

If authenticity cannot be established, treat the state as HOLD (fail‑closed).

OptionalBundle integrity

Bundle integrity (optional)

# Bundle ZIP (from Zenodo)
unzip KCS_*_ZENODO_BUNDLE*.zip -d kcs_bundle
cd kcs_bundle

# Verify bundle checksums (inside ZIP)
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS

Verifiers MUST verify packs using pins carried inside receipts or packs. Hosting location MUST NOT be treated as a trust signal.

Audit packet
AuditorAttachment set

What auditors attach

AttachKCS Spec (PDF) + from Zenodo: RECORD_SHA256SUMS, RECORD_SHA256SUMS.asc, and the artifact‑signing public key (see KEYS/ in the bundle).
VerifyVerify RECORD_SHA256SUMS.asc → RECORD_SHA256SUMS, then run sha256sum -c. (Optional: bundle‑level SHA256SUMS.asc inside the artifact ZIP.)
OutcomesDeterministic PASS / FAIL / HOLD. HOLD is fail‑closed and MUST be treated as “not verified”.
Open Zenodo record Download KCS Spec (PDF)
Templates
CounselClause

Incorporation by reference (example)

Illustrative clause for counsel review. Non‑binding; not legal advice.

Example clause (illustrative; for counsel review):

KCS (Kingdom Conformance Standard) v1.0.0 is incorporated by reference solely for evidence-pack interoperability and offline verification semantics.
Canonical pointers: https://meridianverity.com/standards/. Immutable deposit: Zenodo record 18623859 (DOI 10.5281/zenodo.18623859).
Verification SHOULD be performed offline using signed checksums and the pinned artifact-signing key fingerprint published on the canonical surface.
Boundary: not a compliance certification or warranty; not legal advice; no patent license by publication.
CopyLegal boundary
ProcurementTicket note

Auditor attachment note

Ticket-ready note preserving pins, deposit, and boundary language.

Ticket note (copy/paste):

KCS v1.0.0 (public-safe) — offline-verifiable conformance artifacts (PASS / FAIL / HOLD; fail-closed)
Canonical pointers + pins: https://meridianverity.com/standards/
Immutable deposit: https://zenodo.org/records/18623859 (DOI 10.5281/zenodo.18623859)
Verify: gpg --verify RECORD_SHA256SUMS.asc RECORD_SHA256SUMS; sha256sum -c RECORD_SHA256SUMS (see KEYS/ in deposit)
Boundary: not a compliance certification. Non‑binding unless incorporated by reference. No patent license by publication.
CopyProcurement
AutomationPointers

Canonical pointers (JSON)

Machine-readable pointers for internal verification pipelines.

{
  "standard": "KCS",
  "spec_version": "v1.0.0",
  "revision": "R3",
  "canonical_url": "https://meridianverity.com/standards/",
  "immutable_deposit": {
    "provider": "Zenodo",
    "record_url": "https://zenodo.org/records/18623859",
    "doi": "10.5281/zenodo.18623859",
    "version": "v1.0.0-R3.2"
  },
  "pinned_artifact_signing_key_fingerprint": "6075A8FD8EDBD3FC2B9108324933EB1FE08BCFF8",
  "record_integrity": {
    "public_key": "KEYS/mvg_zenodo_artifact_signing_pubkey.asc",
    "checksums": "RECORD_SHA256SUMS",
    "signature": "RECORD_SHA256SUMS.asc"
  }
}
CopyVerify
Normative excerpt
NormativePublication integrity

15.10 Publication integrity and discovery

Public‑safe excerpt intended for incorporation into a future deposited revision. Non‑binding unless incorporated by reference.

15.10 Publication integrity and discovery (normative)

Canonical publication integrity
The Registry Authority (RA) MUST publish public registry snapshots and supporting artifacts as mirror-safe bundles with:
(a) SHA256SUMS (SHA‑256 checksums), and
(b) an authenticity mechanism for SHA256SUMS (e.g., detached signature or DSSE envelope).

The authenticity key fingerprint for public artifact signing MUST be pinned on the canonical standards surface (Canonical URL).
Consumers MUST treat the pinned fingerprint as the trust anchor for artifact authenticity.
Keyserver discovery or unauthenticated key distribution is insufficient.

Key rotation and exceptions
Any change of artifact-signing keys MUST be explicit and MUST be announced as a new pinned fingerprint on the canonical standards surface.
Silent key changes are prohibited.

Registry heads (optional; discovery rail)
The RA MAY publish a REGISTRY_HEADS document as a discovery and monitoring surface for “current” registry snapshots. If published:
- REGISTRY_HEADS MUST be append-only, and SHOULD chain to a previous head digest.
- REGISTRY_HEADS MUST be authenticated under the pinned artifact-signing key (or an explicitly pinned equivalent).
- REGISTRY_HEADS MUST NOT override pins carried inside receipts or packs. Verifiers MUST verify using pinned snapshot IDs from receipts; heads are advisory pointers only.

Change log (recommended)
For each published registry snapshot, the RA SHOULD publish a change log entry describing additions, deprecations, replacements, and any verifier contract updates.
Meaning changes in-place are prohibited; corrections MUST use replacement + deprecation.
DepositLegal boundary
Release order
OperationsNon‑binding

Publication order (one-shot)

  1. Prepare the deposit bundle as the single source of truth (Zenodo record).
  2. Compute checksums (RECORD_SHA256SUMS) and sign (RECORD_SHA256SUMS.asc).
  3. Publish /standards/ (canonical pointers + pins) before or the same minute as the record is made public.
  4. Publish the Zenodo record and confirm both record URL and DOI resolve.
  5. Verify from a fresh download (signature + sha256sum -c). Any mismatch MUST yield HOLD.
  6. Corrections use replacement + deprecation (new deposit). Meaning changes in‑place are prohibited.