Protocol Research Pipeline
The protocol pipeline turns the value proposition into concrete research targets.
PPP should only move a candidate forward when the candidate has a clear shared claim, multiple peers with distinct authority, and a verifier who benefits from checking a selective proof bundle.
Initial Protocol Blueprints
These pages are not implementation specs yet. They are the first concrete protocol designs extracted from real-world scenarios and candidate research.
| Blueprint | Scenario | First Shared Claim |
|---|---|---|
| Supply Chain Traceability | GS1 EPCIS and DCSA-style event traceability | shipment or item S is traceable under policy P |
| Software Release Provenance | in-toto-style build, review, scan, and release evidence | artifact A is releasable under policy P |
| Credential Status | W3C, OpenID4VC, and AnonCreds-style credential validity | credential C is valid for context K under policy P |
| Milestone Settlement | service, procurement, escrow, and audit payment workflows | milestone M is payable under policy P |
Each blueprint defines:
- peers and peer-owned facts
- required positive and negative evidence
- proof request shape
- proof bundle contents
- certification facts
- infrastructure path
- verifier outcomes
Active Specs
These are the current peer-only feature specs:
The GitHub approval receipts spec in specs/001-* is retained as historical
context. It belongs to the older oracle/registry analysis, not the current
peer-only target.
Candidate Classes
The current research set has three classes.
Standards-backed protocols
These have public specifications or public interoperability material:
- GS1 EPCIS
- DCSA Track and Trace
- DCSA Bill of Lading
- Peppol Post-Award
- Peppol Pre-Award
- SWIFT Documentary Credits
- in-toto
- W3C VC Status Lists
- OpenID4VC
- Hyperledger AnonCreds
- Hyperledger Aries
- Cardano Governance
Protocol families
These are useful domains but not one externally governed protocol:
Internal sketches
These are pattern sketches used to test the fit rubric and user stories:
They should not be presented as researched external standards until they have source-backed protocol notes.
From Candidate To Spec
A candidate becomes a spec only when it has:
- named peers with disjoint fact authority
- one high-value shared claim
- required positive and negative facts
- a proof bundle shape
- a current-state or freshness requirement
- a safe software role
- a documented infrastructure path
The spec should then define verifier behavior first. Implementation follows only after the proof and trust model are precise enough to test.