Zero-Network Verification Architecture

Making Sense of a Federated Notary Journal Export

Company-managed journal integrations keep historical signer data and complete PDFs in your company’s environment. NotaryCentral provides permitted metadata, commitments and signed receipts for independent verification. Here is how to interpret, verify, and audit every byte of the resulting export.

How is the custody boundary configured? Learn how workspace admins manage PII custodians, HTTPS origins, and order lookup URL templates.
Read Settings Breakdown

Signer Data Stays with Your Company

Signer names, addresses, and ID numbers never touch NotaryCentral cloud servers. The partner retains the raw PII along with a 32-byte cryptographically random salt.

Offline Root Attestation

NotaryCentral issues an RS256 JSON Web Signature (JWS) certifying non-PII metadata, document hashes, and the salted PII commitment under a pinned offline trust root.

Verification in Your Environment

Your company’s archive worker verifies the historical source against signed evidence and renders PDFs automatically. An isolated browser verifier remains available for individual review and audit exports.

Get the complete PDF automatically after Finalize

Configure your company’s archive worker once: check the evidence API for finalized entries, retrieve the exact receipt, verify your own historical snapshot and assets, render the complete PDF, and save it in company-controlled storage. Acknowledge archival only after that save succeeds. No company browser, notary passphrase or Download click is required.

The local reference worker publishes journal.pdf, journal.json and manifest.json together in a private .export folder. Your production integration uses its approved cloud destination. The synthetic downloads below illustrate the separate browser export format; they are examples, not your company’s archive or a hosted PDF-generation endpoint.

NotaryCentral signs the receipt; your company’s renderer produces the PDF. Source PII and completed reports stay outside NotaryCentral infrastructure.

Set up your company’s integration

Download Authentic Sample Export Artifacts

These authentic sample files were generated and certified during our live end-to-end verifier test runs.

Test Vector: order_X9y8z7 (Pennsylvania PA)

Verified Journal PDF

561 KB

Complete 3-page Pennsylvania journal export with cryptographic verification cover, participant PII, credential analysis, and receipt linkage.

Filename: verified-journal.pdf · PDF Document

Verified Relational CSV

1.3 KB

Spreadsheet-safe relational export linking signers to documents with formula injection mitigation (escaped formulas) and credential numbers.

Filename: verified-journal-export.csv · UTF-8 CSV

Full Audit ZIP Package

570 KB

Self-contained multi-file package with aggregate CSV, per-record PDF and CSV, and a verification manifest containing SHA-256 digests.

Filename: verified-journal-audit-package.zip · ZIP Archive

Cryptographic Verification Report

4.6 KB

Machine-readable audit record detailing the pass/fail evaluation across the recorded cryptographic checks and root certificate signatures.

Filename: verification-report.json · JSON Data

Raw Evidence & PII Bundle

7.1 KB

Complete input payload containing the signed receipt, certified key manifest, 32-byte salt, and PII snapshot for independent verification.

Filename: evidence-bundle.json · JSON Bundle
Interactive Audit Inspection

Explore the Real Pennsylvania Audit Export

Download PDF (561 KB)
Page 1 of 3

Page 1: Cryptographic Verification Cover

Root-Anchored Attestation & 18 Independent Verification Checks

Every generated journal audit export begins with an immutable, machine-verifiable cover sheet. It proves that the receipt was issued by a certified key from NotaryCentral's pinned offline root and that all 18 cryptographic invariants passed without error.

Key Invariants On This Page

Offline Trust RootPinned demo root ncj-demo-root-2026-01

The verifier verifies the key manifest against a hardcoded public key, rejecting any external server certificate overrides.

Cryptographic Receipt ID87f5e1d2-f8b3-4afd-b53d-4b8289b8c67e

Universal identifier permanently tying this export to the non-PII attestation receipt stored in NotaryCentral.

Privacy BoundaryZero-network client evaluation

Rendered locally in browser memory. NotaryCentral never receives or stores the underlying signer PII.

18 Cryptographic Checks Passing·Layout: Pennsylvania RULONA

Direct rasterized rendering from the standalone browser verifier (Page 1 of 3).

Anatomy of the Export Files: What Each File Contains

Auditors and regulators receive a package of coordinated artifacts. Each file has a presentation or verification role.

1. The Audit PDF (`verified-journal.pdf`)

The PDF is the human-readable journal output. Its verification cover identifies the evidence and captured source version; it does not certify source-data truth or blanket legal compliance.

  • Page 1 (Cover Sheet): Cryptographic attestation cover detailing the offline trust root, receipt ID, notarization timestamp, and full checklist of the recorded cryptographic checks.
  • Page 2 (Jurisdiction Journal Entry): Presented using Pennsylvania, Florida, Texas or General field layouts. Includes signer names, addresses, ID credentials, and notarial act references.
  • Page 3 (Document & Receipt Linkage): Enumerates the signed documents (e.g., Deed of Trust, Note, Mortgage), page counts, signer links, and NotaryCentral’s frozen metadata digest.

2. The Relational CSV (`verified-journal-export.csv`)

Designed for automated ingestion into loan origination systems (LOS), data warehouses, and compliance spreadsheets.

  • Formula Injection Mitigation: To prevent CSV formula injection attacks in Excel and Google Sheets, any cell starting with dangerous characters (=, +, -, or @) is automatically prepended with a single quote (').
  • Unicode & Normalization: UTF-8 encoded with strict Unicode NFC normalization to preserve non-ASCII participant names (e.g., accents, umlauts).
  • Relational Structure: Denormalizes participant-document relationships so auditors can query which signer executed which specific instrument.

3. The Audit ZIP Package (`verified-journal-audit-package.zip`)

The definitive bulk or single-order forensic archive.

  • Folder Hierarchy: Stored under records/0001-.../journal.pdf and records/0001-.../journal.csv.
  • Verification Manifest: Includes verification-manifest.json containing the SHA-256 digest of every file inside the archive, allowing changed or missing files to be detected against a trusted copy of the manifest.

Understanding the Cryptographic Checks

The verifier runs the required checks for the supplied protocol and history before enabling export. If even a single check fails, the export gate remains locked.

1. Root Trust & Key Certification

Pinned NotaryCentral trust root
Verifies the key manifest against hardcoded public key ncj-demo-root-2026-01. Never accepts attacker-supplied root keys.
Exact key manifest payload
Requires the decoded manifest payload bytes to exactly equal the manifest_payload parameter.
Offline root signature
Proves that receipt signing keys were certified by NotaryCentral's offline root authority.
Canonical key manifest
Enforces lexicographically sorted keys and strict ncj-receipt-key-manifest-v1 schema.
Key certification at receipt time
Confirms the receipt's issued_at timestamp falls within the validFrom/validUntil manifest window.
Certified receipt keys
Validates that the active signing key ID is officially listed inside the certified manifest JWKS.

2. Receipt Integrity & Metadata Binding

Evidence structure
Ensures all non-PII evidence parameters (receipt ID, timestamps, digests) match the protocol specification.
Protected JWS header
Validates alg=RS256, typ=notarycentral-journal-receipt+jws, and kid=demo-journal-key-1.
Exact signed payload
Guarantees the decoded JWS bytes exactly equal the receipt_payload string without re-encoding.
NotaryCentral signature
Verifies the cryptographic RS256 signature using the certified public key.
Canonical receipt payload
Requires strict canonical UTF-8 JSON matching the exact byte representation stored in the database.
Receipt claims match evidence
Validates that every signed claim in the JWS matches the corresponding evidence field.
Frozen metadata digest
Recomputes lowercase hex SHA-256 over 'NCJ-METADATA\0V1\0' + canonical appointment metadata.
Protocol versions and state
Confirms protocol NCJ-FEDERATED-1 and terminal state COMPLETE.

3. Zero-Network PII Commitment & History

PII snapshot bound to journal
Asserts that journalEntryId, journalVersion, and metadataDigest inside the PII snapshot agree with the receipt.
Historical PII commitment
Reproduces the exact SHA-256 hash over 'NCJ-PII-COMMITMENT\0V2\0' + 32-byte salt + exact snapshot UTF-8 bytes.
PII snapshot schema and references
Strictly validates participant/document refs, dates, and Unicode NFC normalization.
Complete receipt history
Validates continuous version sequencing (1, 2, 3...) and verifies each version's previousReceiptId link.

How to Independently Verify on Your Own Machine

You do not need to take NotaryCentral’s word for it. The verification protocol is open source and designed to run entirely offline or in an air-gapped environment.

# 1. Download the evidence bundle and verification tool

curl -O https://www.notarycentral.org/downloads/federated-journal/evidence-bundle.json

# 2. Run the offline zero-network verifier locally

Obtain the approved, versioned verifier release and public trust root from your integration provider.

Build and serve that release using its included instructions.

# 3. Import the synthetic evidence-bundle.json into that isolated verifier.

# Verification runs locally; the browser verifier makes no server calls after receiving the bundle.