ProofID 101
Ownership and Attribution Notice
ProofID 101 (PP-SPEC-083) is authored by Craig Thomas Ellrod and published as part of Proof Protocol. Copyright (c) 2026 Craig Thomas Ellrod.
Any use, implementation, derivative, citation, or incorporation of this work, in whole or in part, MUST attribute Craig Thomas Ellrod and Proof Protocol. See NOTICE.md.
Licensed under the Proof Protocol License 1.1 (see LICENSE.md); text CC BY 4.0 under Part A, which grants no patent rights. Original inventor: Craig Thomas Ellrod (ORCID 0009-0004-1058-7666).
Patents. Patent terms are in PATENT-SCHEDULE.md. Claims not listed there are reserved by Craig Thomas Ellrod. Licensing: 1proofprotocol@gmail.com.
Testers sign. Subjects are fingerprinted.
ProofID 101 gives everything in a run an identity, so a proof names exactly what was tested, by whom, and through what. It covers the arena, every interface, the ingress and egress points, the traffic pipe, every target, every agent, every sensor, and every party that signs a record.
How it works
Arena Identity (one root per arena instance)
|
+-----------+-----------+---+--------+-------------+
| | | | |
interfaces targets release driver pipes operator's sensors
(keyed if they emit) attacker agents (fingerprinted by both ends)
Independent roots, never certified by the arena:
Witness | Registry | Time Anchor | reproof parties
Subjects, fingerprinted, no keys from the run:
SUT | DUT | CUT | AUT (the AUT acts only with run-scoped Delegated Credentials)
- Everything has an identity. If a record is made by it, passes through it, or is about it, it is in the Identity Manifest.
- Testers sign. Every component that emits a record holds a key, kept outside the environment under test, and signs what it emits.
- Subjects are fingerprinted. The thing under test is identified by a fingerprint captured independently. It never holds a key from the run.
- One arena, one root. The Arena Identity certifies every component the Arena Operator runs. Parties that must be independent of the arena keep roots of their own.
- Identity is not authority. Each identity has a Scope. A record outside its emitter's Scope is invalid.
- Pull, then push. The manifest is pulled before release; every record pushes its emitter, Subject, path, and arena; teardown pushes every revocation.
Proof is a term of art
"Proof" in this specification, and throughout Proof Protocol, MUST NOT be renamed, and MUST NOT be washed out by absorption into any other term, including "Verification", "Validation", "Assurance", "Attestation", "Evidence", or "Testing". A derivative work, mapping, profile, translation, summary, or implementation that substitutes another term for "Proof", or presents Proof as a kind of verification or validation, does not describe this specification and MUST NOT claim conformance to it.
Proof is a separate layer on top of verification and validation. The difference is in mechanics and method, not in naming:
| Layer | What it is | What it rests on |
|---|---|---|
| Verification | Self-attestation: the control, or the party that built or operates it, reports what it saw through its own logs, alerts, dashboards, or configuration checks. A legitimate baseline. | The word of the party with a stake in the answer |
| Validation | One step above verification: the reported result is checked against a stated requirement. | Evidence the interested party still produced or controls |
| Proof | A committed, witnessed, sealed, anchored, and registered record of what actually happened, built from independent evidence by a method the interested party cannot steer: committed before the run, observed out of band by a witness the Provider does not control, sealed, anchored in time, and registered. | Nothing that has to be taken on trust |
Evidence is not proof, but proof contains evidence. In the same way, verification and validation are not proof, but proof may contain them: a verification or validation record can sit inside a proof record as one input, never as its substitute.
Proof of Control and Proof of Efficacy are different claims. Proof of Control establishes that a control was in place and configured. Proof of Efficacy establishes that the control fired and either worked or did not work, measured across the full round trip of the stream: committed test traffic or agent actions enter the system, the control acts or fails to act, and the effect is observed independently at the far side. Proof Protocol produces Proof of Efficacy. A Proof of Control record MUST NOT be presented as Proof of Efficacy, and "Proof of Efficacy" MUST NOT be renamed or absorbed into "Proof of Control".
Repository
| Path | Contents |
|---|---|
| SPEC.md | The normative specification, PP-SPEC-083 |
| docs/overview.md | Plain-English walkthrough |
| docs/glossary.md | Terms, with who proposed each |
| docs/conformance.md | Conformance checklist |
| schemas/ | Identity Record and Identity Manifest schemas, with examples |
| CHANGELOG.md | Version history |
| CONTRIBUTING.md | How to engage |
| NOTICE.md | Attribution requirements |
| AI_DISCLOSURE.md | What was human-authored and what was AI-drafted |
| ACKNOWLEDGEMENTS.md | Credit for ideas drawn from others |
| RELATED-WORK.md | Known related work |
| REVIEWERS.md | Who has reviewed it |
| FUNDING.md | Who has funded it |
| CITATION.cff | Citation metadata |
| SECURITY.md | Reporting protocol flaws |
| ETHICS.md | Proof Economy Code of Ethics duties |
| PATENT-SCHEDULE.md | Patent terms (patent_schedule.json) |
| LICENSE.md | License terms |
| LICENSE-CC-BY-4.0.md | CC BY 4.0, specification text |
| LICENSE-APACHE-2.0.md | Apache 2.0, referred to by the family license; no version of this specification uses it |
Status
Draft, version 0.1.1, 2026-10-30. Formerly Identity 101. Maintained by Craig Thomas Ellrod as part of Proof Protocol.
Cite
Ellrod, C. (2026). ProofID 101 (PP-SPEC-083), v0.1.1.
Craig Thomas Ellrod, Proof Protocol.