SPEC v1.0 · DRAFT
Proof of Governance

Security and AI systems detect, classify, summarize. They do not prove enough.

PoG is an open framework for turning security events and AI-assisted decisions into traceable, sealed, verifiable evidence. Not logs. Not dashboards. Artifacts that a security leader can defend in front of an auditor, a regulator, or a court.

DRAFT · OPEN FOR REVIEW SPECIFICATION v1.0 THREAT MODEL v1.0 CONFORMANCE PLAN v1.0
Who is behind this, stated plainly. PoG is initiated and maintained by Smart STB Sàrl (Geneva, Switzerland), the company behind the PREVORN platform, which serves as the reference implementation. This is a single-vendor framework opening itself to scrutiny, not an industry consortium, and we will not pretend otherwise. The specification is published precisely so that its claims can be verified, challenged, and improved by people who do not work for us.
01 · Principles

Four properties, enforced by construction.

A system is PoG-conformant only if every governed decision produces an artifact satisfying all four properties. Three out of four is non-conformant.

P1

Traceability

An unbroken chain from raw event to final decision: event, incident, analysis, human gate, evidence. No implicit links. Every transformation is recorded with its actor, human or machine.

P2

Integrity

Every artifact is sealed with a cryptographic integrity mechanism at creation. Tampering, substitution, chain corruption and unauthorized resealing are detectable failure states, defined in the threat model.

P3

Governance

The decision path itself is governed. AI-assisted judgments pass through an explicit, recorded human gate before they become authoritative. The gate is part of the sealed artifact, not a checkbox next to it.

P4

Verifiability

Producing artifacts is not the point. Verifying them is. Any PoG artifact can be re-verified after the fact, including outside the system that produced it, using the published verification procedure.

02 · The artifact chain

From signal to sealed evidence.

PoG models the life of a security decision as a chain of typed objects. Each transition has explicit preconditions and failure states defined in the specification.

04 · Conformance

Tested, not declared.

A vendor saying "we implement PoG" means nothing. Conformance under PoG is the result of executing the test plan against an implementation.

Positive tests

The implementation produces correct artifacts under normal conditions: valid chains, valid seals, valid gates, re-verifiable packs.

Negative tests

The implementation must refuse what the specification forbids: sealing incomplete chains, skipping the human gate, silently mutating sealed objects.

Adversarial tests

The implementation is attacked along the threat model: tampering, substitution, resealing abuse, cross-tenant attribution. Detection is mandatory, not best-effort.

One reference implementation currently exists: PREVORN, operated in production on Swiss infrastructure. Independent implementations are the explicit goal of publishing this framework, and the conformance plan is written so that we do not get to grade our own homework forever.

05 · Status and roadmap

What PoG is today, and what it has not earned yet.

This table is the honest state of the framework. It will be updated as gates are passed, and only then.

StageGateStatus
Technical credibilityEvidence sealing, verification flow, event-to-evidence chaining, tenant-safe attribution, first conformance testsIN PLACE · reference implementation
Framework formalizationSpecification, threat model and conformance plan drafted, versioned and published for reviewIN PROGRESS · drafts v1.0
External reviewSubstantive adversarial review by parties independent of Smart STBOPEN · reviewers wanted
Independent implementationAt least one conformant implementation not written by the framework authorsNOT STARTED
Protocol-grade languageStable spec, provable conformance, coherent multiple implementations, survived adversarial reviewNOT EARNED · by design

Yes, this domain is called pog-protocol.org. The name states the destination, not the current status. Until the last gate above is passed, PoG is a framework, and our own claims policy forbids us from calling it anything more.

06 · Governance of the framework

Rules we hold ourselves to.

  • AuthorshipInitiated and maintained by Smart STB Sàrl, 17 Rue Dancet, 1204 Geneva, Switzerland. Editor: the PREVORN engineering team. No consortium is implied or claimed.
  • Claims disciplineExternal claims about PoG are governed by the published Claims Policy. Staged language: framework today, specification plus conformance next, protocol-grade only if earned.
  • Review processAnyone may submit a review by email. Substantive issues are answered publicly in the changelog. Silence is not an option we allow ourselves on documented flaws.
  • VersioningDocuments are versioned explicitly. Breaking changes to sealed-artifact semantics require a major version and a migration note.
  • LicensingSpecification documents are published under a license permitting free reading, citation and implementation. The PREVORN product code is not part of the framework and remains proprietary.
  • No pay-to-playConformance language may never be bought. If a certification program ever exists, its tests will be the published ones, executable by anyone.
07 · Frequently asked questions

The questions skeptics ask first.

Is PoG a standard?
No. PoG is a framework initiated by a single vendor, currently at draft stage, with one reference implementation. It becomes worth calling anything more only after independent review and independent implementations exist. We publish the maturity table above precisely so nobody has to take our word for it.
Why should anyone trust a single-vendor framework?
You should not trust it. You should read it. The specification defines objects, transitions and failure states precisely enough to be attacked; the threat model tells you where to aim; the conformance plan is executable. A framework that survives that treatment earns trust the only way that counts. One that does not deserves to be discarded, ours included.
What problem does PoG actually solve?
Accountability of automated and AI-assisted security decisions. When a regulator, auditor or court asks "why did the system decide this, based on what data, validated by whom", most stacks can produce logs and scores but not proof. PoG forces every governed decision to leave a sealed, re-verifiable artifact with a recorded human gate. That artifact is the answer.
How does PoG relate to ISO 27001, nLPD, GDPR or NIS2?
PoG is not a compliance framework and does not replace any regulation. It is an evidence and governance layer: the artifacts it produces are designed to serve as high-integrity evidence within those regimes. Mapping tables from PoG artifacts to common control frameworks are part of the roadmap.
What is the relationship between PoG and PREVORN?
PREVORN is the commercial platform built by Smart STB and the reference implementation of PoG. The framework was extracted from that engineering work, not invented for marketing. The two remain deliberately separable: the specification must stand on its own, and the conformance plan applies to PREVORN exactly as it would to any other implementation.
How do I review or contribute?
Email spec@pog-protocol.org with your comments, attack ideas or implementation questions. Substantive reviews are credited in the changelog. Adversarial readings are the most useful kind and are explicitly welcome.