The public posture is deliberately specific.
Each row describes code or a published record, not a currently operating API. PLANNED features remain unshipped.
- 01CRYPTOWHEN CONFIGUREDConfigurable signing
ECDSA P-256 is implemented when key directories are configured. HMAC remains the dev and legacy default.
- 02INTEGRITYIMPLEMENTEDDatabase-enforced record controls
Records receive server-assigned sequence numbers. Database triggers block UPDATE and DELETE on protected record tables, while Postgres RLS separates tenant access. Privileged out-of-band storage access remains a trust boundary; sequence gaps do not prove source completeness.
Maps to: post-admission alteration and sequence signals
- 03STORAGEWHEN CONFIGUREDCustomer-held WORM retention
When the customer's Object-Lock bucket is configured, signed records replicate into it (write-once retention), so the bytes sit under the institution's retention control, not ours. Deleting or rewriting a record inside the retention window is blocked by the customer's storage layer itself.
Maps to: record retention; record-alteration detection (storage layer)
- 04TIMESTAMPPUBLISHED RECORDMerkle + RFC 3161 timestamp
A verified inclusion path in the July 2026 record links it to a Merkle root with a timestamp token from an independent RFC 3161 authority. The token establishes that the root existed by its genTime. It does not establish the earlier application or decision timestamp. The live anchoring job is paused.
Maps to: independent latest-existence bound
- 05VALIDATIONIMPLEMENTEDFail-closed validation
Records with unknown chains, missing fields, or malformed rationale are rejected before storage.
- 06PRIVACYIMPLEMENTEDAES-256-GCM encryption at rest
Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.
- 07ISOLATIONIMPLEMENTEDTenant isolation
Row-level security and FORCE RLS separate tenant records from runtime roles.
- 08PRIVACYPARTLY IMPLEMENTEDPayload minimization
The public sample exposes only verification fields. Customer schemas require explicit allowlists before any real customer record is public.
- 09OWNERSHIPDEMONSTRATED IN DEMODeployer-controlled record
The record format is designed to sit in the deployer's evidence layer: exportable, reconcilable, contract-independent of vendor terms. Deployer-held key custody is the pilot target mode. The fictional Demo Bank record shows cross-origin public-key resolution; it does not establish independent production custody or source truth.
- 10OPERATIONSPLANNEDTransparency surfaces
Public status page, incident history, and key rotation log are planned. They must ship before any production pilot claim.
Notary Cloud records. It does not decide.
- The deploying system makes the decision.
- The decision, rationale, and scoped inputs are sent to Notary Cloud.
- The payload is canonicalized, minimized through an allowlist, signed, and stored under database update/delete controls. Privileged out-of-band storage access remains a trust boundary.
- The public verifier checks the signature client-side against a public key served separately.
Notary Cloud does not decide, screen, approve, deny, or file SARs. It records a decision declaration and scoped context after the upstream system submits them, then exposes a tamper-evident record when policy allows public verification. It cannot reveal a decision that never crossed that submission boundary.
Subprocessors are named only when finalized.
Current hosting and storage
Deployment, hosting, and storage details should be named only after the subprocessor list is finalized. This page does not fabricate vendor names.
Published list
Subprocessor list is published here and kept current. Status: publication pending.
Public record boundary
Public samples expose verification fields. Real customer schemas require explicit allowlists before any customer record becomes public.
Key-custody modes are stated separately.
The fictional Demo Bank record verifies against an ECDSA P-256 public key served from a separate demo origin at https://demo-bank-keys.pages.dev/.well-known/notary-cloud/demo_bank_ec_1.pem. That demonstrates cross-origin key resolution, not independent bank custody. The archived anchored mechanics record uses a Notary Cloud-held pilot key whose public half is retained statically. Customer-held private-key issuance is a target mode, not a currently available service. A past proof remains verifiable only while its signed bytes, a trustworthy public-key reference, and any anchor material are retained.
Customer BYOK and HSM/KMS-backed signing are planned, not live. A public key rotation log is planned.
Verification should survive company and vendor change.
Incident history
Incident history is planned. It should be public before any production pilot claim.
Record continuity
If the deployer retains the signed record, a trustworthy public-key reference, and any anchor material, checking a past proof does not require Notary Cloud to re-run the system or the original vendor.
The record is exportable and cryptographically verifiable.
- Proof JSON with proof ID, key ID, timestamp, algorithm, input hash, decision, and signature.
- Canonical string used for signature verification.
- Public key URL served separately from the proof payload.
- Verifier URL that can be opened by an examiner or reviewer when policy allows access.
The published cryptographic claims remain checkable in the browser.
The signed sample record and appendix expose the proof fields, canonical string, public-key reference, and the limits of that verification.