Protocol Specification
PatentChecker is not just software. It is the reference implementation of a protocol for machine-checkable patent claims.
The protocol enables evidentiary objects that survive organizational boundaries, vendor relationships, and time.
Three-layer protocol stack
The protocol separates concerns into grammar, proof, and trust. Each layer is independently verifiable and frozen until v1.0.
Grammar (Layer 1)
What can be claimed, how it is encoded, and which fields are normative versus advisory.
- • Schema structure
- • Claim classes A-E
- • Field semantics
- • Validation rules
spec/evidence-packet-v0.1.mdProof (Layer 2)
How claims are verified: canonicalization, hashing, signatures, and result codes.
- • Canonical JSON (pc-canon-v1)
- • SHA-256 derivation
- • Ed25519 signatures
- • Verification procedure
spec/evidence-packet-v0.1.md (Sections 3-6)Trust (Layer 3)
Who attests to artifacts: trust stores, key rotation, and attestation vs truth.
- • Trust store format
- • Key roles
- • Attestation semantics
- • Rotation rules
spec/evidence-packet-v0.1.md (Section 7)Independent implementations
The existence of multiple independent verifiers is a protocol correctness proof. If two implementations produce the same result, the specification is unambiguous.
- • Full verification
- • Schema validation
- • Signature verification
- • Trust store mgmt
patentchecker artifacts verify <bundle>
- • Zero dependencies
- • Independent canonicalization
- • Receipt generation
- • Cross-verified
python3 patentchecker_verify.py <bundle> --json
- • Single file
- • No npm install
- • Embedded contract hash
- • For legal teams
node patentchecker-verify-standalone.js <bundle>
Independence proofs
A protocol is real when it survives contact with reality. Here is the honest assessment.
| Proof | Status | Evidence |
|---|---|---|
| Another team implements verifier | ✅ Proved | Python implementation exists, passes golden vectors |
| Another machine reproduces hash | ✅ Proved | CI determinism tests pass across Linux/macOS/container |
| Another org consumes artifact | ⚠️ Provisionally | Standalone verifier exists, awaiting field test |
| Another lawyer cites object | ❌ Not yet | Citation format ready, no live workflow yet |
What "provisionally proved" means
The standalone verifier makes independent consumption possible, but we have not observed it in the wild. Real proof requires an external party with no dev help from us successfully verifying and referencing the artifact.
Claim classes (frozen v0.1)
The protocol defines specific claim types to keep the grammar legible. Each class has normative boundaries: mandatory fields, policy inputs, and invariants.
| Class | Name | Event Types | Status |
|---|---|---|---|
| A | Publication Ingestion | new_publication, publication_metadata_changed | Frozen v0.1 |
| B | Family Membership | new_family_detected, family_member_added, family_member_removed | Frozen v0.1 |
| C | Overlap/Diff | roi_overlap_delta, match_score_delta, assignee_changed | Frozen v0.1 |
| D | Timeline/Risk | risk_score_changed, severity_escalation, cooldown_expired | Frozen v0.1 |
| E | Legal Monitor | legal_event_detected, proceeding_status_changed | Frozen v0.1 |
See spec/claim-classes-v0.1.md for normative boundaries.
Citation formats
A citation format must be precise enough for cryptographic verification, clean enough to survive Word/PDF/email chains, and short enough for footnotes.
{
"citation_version": "pc-cite-v0.1",
"bundle_id": "pc:ep:v0.1:sha256:3f8c...",
"claim_classes": ["C", "D"],
"verification": { "status": "VERIFIED_OK" }
}PatentChecker Evidence Packet Bundle: pc:ep:v0.1:sha256:3f8c9e... Claim Classes: C (Overlap/Diff), D (Timeline/Risk) Contract: v0.1.31 Verified: 2024-03-14, Status: VERIFIED_OK
PC Bundle 3f8c9e..., Claim C/D, Contract 91ab... (Verified)
See spec/citation-format-v0.1.md for full specification.
Downloads
Protocol philosophy
Artifacts, not APIs
Most legal tech sells APIs: "Trust us, it's right." PatentChecker sells artifacts: inspect the bundle, verify offline, trust the math. The power dynamic shifts from vendor dependency to cryptographic verification.
Attestation, not truth
The trust model provides attestation authority, not metaphysical truth. A signer attests: "This artifact was produced under these rules by this authority." Not: "This is universally true forever." That humility is a strength.
Boring machinery
SHA-256, canonical JSON, Ed25519 signatures. Tiny gears with absurd consequences. The universe runs on boring parts. Protocols are boring machinery with empire-grade consequences.
Protocol vs product
The software is one implementation. The protocol is the long-term bet. History suggests that if the format solves a real problem and verification is truly open, the protocol outlives the company that created it.
Status
The infrastructure layer is complete enough. Now we test the social reality of the object.