Product

VREC is designed as a verification layer for existing systems of record.

The planned product will create portable Evidence Receipts that describe issuer identity, integrity, time, status, and independently inspectable proof.

Core objects

Six core objects describe the parties, records, receipts, bundles, and lifecycle events.

ORG

Organization

The customer, authority, verifier, software partner, or operating entity with a defined trust boundary.

ISS

Issuer

The person, system, or organization responsible for an evidence statement and its authority context.

EVR

Evidence Record

The canonical, privacy-aware representation of a source event, decision, document, or approval.

RCT

Evidence Receipt

The signed and status-aware proof that can be checked without exposing the full source record.

BND

Evidence Bundle

A portable group of related receipts for a transaction, audit, shipment, case, or closing.

STS

Status Event

An append-only lifecycle statement such as superseded, suspended, expired, or revoked.

Platform services

The planned platform coordinates evidence creation, authority controls, anchoring, and verification.

01

Evidence interface

A planned API and connector layer for creating, retrieving, checking, and updating evidence status.

02

Issuer and authority controls

Bind signatures to organizational roles, policies, credentials, and delegated authority.

03

Policy and chain gateway

Apply the requested assurance profile while abstracting network operations and preserving transparency.

04

Verify and proof export

Give people and software a clear result plus a portable package for independent checking.

Proof boundary

VREC can establish evidence integrity, origin, timing, and lifecycle.

VREC can establish

  • Which issuer signed or attested
  • Whether the submitted bytes still match
  • When proof states were recorded
  • Which assurance and chain policy applied
  • Whether status has changed

VREC cannot establish by itself

  • Whether a physical event truly occurred
  • Whether an issuer was legally competent
  • Whether a regulatory decision was correct
  • Whether a professional opinion was sound
  • Whether source data was truthful

Review the integration method and the planned developer interface.