Status, stated plainly
PBGF-CS is a draft conformance specification with one author and one reference implementation. It has no independent governance body, no standards-body process, and no second implementer. The reference implementation is currently below Level 1 on it.
That is the honest position, and it is the position of every specification at this stage. It is not a stable one, and this page exists to say what would change it.
Versioning
Tightening and loosening are not symmetric.
- Tightening — adding a requirement, narrowing an existing one, or closing an interpretive gap — may occur in a minor version, with the change and its rationale recorded.
- Loosening — removing a requirement, weakening an existing one, or widening an interpretation such that previously non-conformant behaviour becomes conformant — requires a major version and a documented rationale.
The asymmetry is deliberate. A specification that can be quietly relaxed by its author is a specification that means whatever is convenient this quarter.
Clarifications — where a requirement’s wording is ambiguous and the resolution does not change which behaviours conform — are published as numbered clarification questions with a resolution and a date. A clarification that turns out to loosen is a major version, whatever it was called when it was raised.
Conformance claims name a version. “Conforms to PBGF-CS” without a version is not a claim.
Proposing a change
Open an issue against the specification repository, or write to the address on the specification page. A useful proposal states:
- Which requirement, by section number.
- What is wrong with it — ambiguous, unsatisfiable, unnecessary, or missing.
- The evidence. For “unsatisfiable,” an account of what was attempted and where it failed. For “unnecessary,” an argument that a conforming gate without it is not weakened.
- The proposed wording, if you have one.
The most valuable contribution is evidence that a requirement cannot be satisfied in practice. That is not an objection to the specification; it is the specification working. Requirements are extracted from measurements, and a measurement that does not survive contact with a second implementer is a finding.
Dispute resolution, while there is one author
Until there is a second implementation, the author decides — and that is exactly the weakness this section names rather than hides.
Two constraints apply in the meantime, and they are checkable by anyone:
1. The author may not resolve an ambiguity in favour of his own implementation’s conformance score. Where a requirement is ambiguous and one reading would raise gated’s position, the strict reading is published and the ambiguity is raised as a clarification question to be settled at arm’s length. This has already been exercised once: §4.3(2)’s “where the evaluation is scenario-based” has a plausible reading under which the requirement does not attach to a promotion verdict on an unknown artifact. The strict reading is published anyway, and the question is open.
2. Disputes and their resolutions are published, including ones the author loses, and including ones resolved against a proposal without a fully satisfying argument.
These are process commitments, not mechanisms. They are stated here so that a failure to honour them is visible.
Conformance claims
Anyone may claim conformance for their own gate. No permission is required and no certification is offered — there is no body to certify, which is the point of Level 1 being self-attested.
A claim should state: the level, the specification version, the scoped artifact-boundary pair the claim covers, and where the evidence can be inspected. A claim that names no scope is not a claim; conformance attaches to promotion verdicts for a defined artifact class at a defined boundary, not to a product.
The author’s own claims carry no special standing. gated is a reference implementation, not an arbiter. Where its behaviour and the specification disagree, the specification is correct and the implementation has a defect — including where the implementation is more convenient.
Where this should live
The intent is to move PBGF-CS out of single-author control. A conformance specification with one implementation is a proposal; the value of the trichotomy and the four requirements, if it is real, does not belong to whoever wrote them down first.
The destination should be an existing foundation with adjacent supply-chain or AI-assurance work and an established multi-vendor governance process — not a new body. At one implementation, forming a consortium would be ceremony rather than governance. SLSA’s path, from a single-vendor internal practice to foundation governance with multiple contributors, is the relevant precedent and the shape worth copying.
The trigger is the point at which a second implementer proposes a change — that is when single-author control stops being merely the arrangement and becomes the obstacle. A second implementation without a proposed change is encouraging; a proposed change is the moment the process has to be real.
Until then, the honest description is: an early-stage specification, openly published, with a declared path out of single-author control and a stated trigger for taking it.
What this page does not fix
Publishing a governance model does not create a governance body, does not produce a second implementer, and does not make a single-author specification into a standard. It states the terms on which those things would happen and makes the current arrangement’s limits explicit.
The circularity is real: the specification and its reference implementation share an author. The mitigations available today are (a) that the implementation is measured against the specification in public and currently fails it, (b) that ambiguities are resolved against the author’s interest, and (c) that the exit is stated with a trigger. Those reduce the problem. They do not close it, and no amount of process will — only a second implementer will.
PBGF-CS v0.1 · specification: moriapp.dev/pbgf-cs · framework: moriapp.dev/pbgf · reference implementation: github.com/fjwood69/gated (Apache-2.0)