Independent evidence core · EB1 v2
HREVN EB1 Core turns canonical product records and their files into a deterministic ZIP with per-file hashes, one content root and a signed envelope. The same core verifies each security property separately.
Core, trust root and signed registry active
The core can establish
The core does not infer
The protocol
Product adapters decide what a record means. The core owns the evidence mechanics so every product does not invent its own hashing, signing and verification path.
Canonical inputs, sorted members and fixed archive rules produce a reproducible evidence structure.
Bundle identity, root, product, profile, producer, key identity and claimed times are covered by the signature.
Unknown fields, ambiguous archive structures and unsupported signature forms stop the relevant conclusion.
Format, integrity, signature, authority, profile, time and anchor evidence remain separate.
SuperProperty uses an adapter; future verticals must consume the same core instead of forking it.
Python and Go implementations are checked for divergence; agreement is evidence, not a proof of correctness.
How it works
The application selects authoritative JSON and files and validates its own record profile.
The core builds the exact archive, computes checksums and root, and signs the complete envelope.
A recipient can inspect the ZIP offline, add the published HREVN trust context and receive qualified results instead of a single green answer.
Published production trust
HREVN now publishes trust root v1 and a 2-of-3 root-signed key registry. A conforming verifier can use those separately distributed bytes to determine whether a signing key was authorized for the bundle’s exact protocol, product and profile.
Online ratification goes one step further: the exact external ZIP SHA-256 must also appear in the signed HREVN issuance ledger. It does not certify the underlying statements, claimed time or legal effect. Blockchain anchoring remains a separate optional property.
In production now
Its visits and annexes are produced through product-specific adapters and the independent EB1 core. Its signing key is present in the published registry; exact HREVN issuance remains a separate ledger result and is confirmed only for bundles recorded during issuance.
The HREVN rule
Use EB1 when files, identity and product context must travel together as one reviewable package.
Discuss an integration