N
NextGenRails™
Software Integrity Receipt Authority
Verify Receipt
System Active
NEXTGENRAILS™ | SOFTWARE INTEGRITY RECEIPT AUTHORITY

From trust-based software claims to cryptographic proof.

CBOM Compliance transforms supported software manifests into deterministic, cryptographically signed verification receipts that can be independently verified.

Start Verification Verify Receipt

Deterministic verification • signed receipts • independent public-key validation

CycloneDX / SPDX JSON SHA-384 Fingerprint Merkle Root Derivation Signed Receipt Public-Key Verification
Zero Retention Deterministic Outputs Signed Receipts Independent Verification
System Output

What You Receive

Authority Output

Each verification run produces a deterministic, signed receipt artifact tied directly to the submitted manifest and designed for independent validation outside this interface.

Receipt Status
SIGNED
Fingerprint
SHA-384
Structure Proof
Merkle Root
Verification Path
Public Key
Issued Artifact
Signed, time-bound proof of manifest state with independently verifiable receipt output.
Verification Workbench

Manifest Verification

System Idle

Submit a supported JSON manifest to generate a signed verification receipt.

Verification Tier
Standard = proof only. Advanced = proof + intelligence + time-aware re-evaluation.
Controlled Issuance
Signed receipt issuance is usage-metered and access-controlled.
Each purchase currently includes 10 signed receipts.
For enterprise usage or verification inquiries:
ngr.admin@proton.me
Sample manifest preview
Click "Load Sample" to preview a test manifest.

Data Handling & Verification Model

Submitted manifests are processed transiently for the sole purpose of generating a signed verification receipt.

No uploaded data is stored, retained, indexed, or shared. Processing occurs in-memory within a serverless execution context and is discarded after computation.

Issued receipts are signed by the system and can be verified independently using the public verification key endpoint.

No persistent storage • No manifest logging • No database retention of uploaded contents

Live Scope

System Status & Receipt Scope

Service
Checking…
Mode
Checking…
Timestamp
Checking…
Protocol
Checking…

Receipt Scope

  • Cryptographically signed verification receipt
  • Manifest SHA-384 fingerprint
  • Merkle-root derivation result
  • Timestamped validation record
  • Public-key verification path
  • Advanced tier: risk analysis, source-backed intelligence, and time-aware re-check

The receipt is designed to function as machine-readable verification evidence, not as a blanket claim of software safety or regulatory approval.

Public verification key endpoint: /.netlify/functions/public-key
Verification Model
Proof of submitted manifest state at issuance time, with signed output and independent validation path.
Authority Boundary
This system proves the submitted input and signs the resulting receipt. It does not claim full runtime truth or automatic legal compliance.
Output

Verification Result

No manifest verified yet.
System Interpretation

How This Works

Overview

Receipt-issuing verification layer

CBOM Compliance processes supported JSON manifests and returns a cryptographically signed verification receipt. The output is designed to function as machine-readable evidence tied to the submitted manifest, not merely a pass/fail screen.

Flow

Verification process

  1. Upload a CycloneDX or SPDX JSON manifest.
  2. The system validates structure and extracts component entries.
  3. A SHA-384 fingerprint and Merkle root are derived from the manifest data.
  4. A signed receipt is issued with timestamp, manifest hash, and verification metadata.
Proof Scope

What the receipt proves

  • That this manifest was processed by the NextGenRails verification system.
  • That the output receipt was signed by the system's private signing key.
  • That the manifest fingerprint and Merkle root in the receipt are deterministic outputs of the submitted data.
  • That the receipt can be verified independently using the public verification key.
Boundaries

What it does not claim

  • It does not certify that software is vulnerability-free.
  • It does not guarantee legal compliance by itself.
  • It does not replace a full security audit or formal attestation framework.
  • It produces cryptographically signed verification evidence for submitted manifests.