The public posture is deliberately specific.
Each row names the control and its current state. LIVE means live in code or record design today. PLANNED means not live.
- 01CRYPTOLIVE WHEN CONFIGUREDConfigurable signing
ECDSA P-256 is implemented when key directories are configured. HMAC remains the dev and legacy default.
- 02INTEGRITYLIVEAppend-only record storage
Records get monotonic sequence numbers and database-level append-only enforcement. UPDATE and DELETE are blocked under row-level security. This is not a per-record blockchain.
- 03TIMESTAMPLIVE WHEN CONFIGUREDMerkle + RFC 3161 timestamp
Daily batches can be hashed into a Merkle root and timestamped through one configured RFC 3161 TSA endpoint. No built-in fallback TSA is live yet.
- 04VALIDATIONLIVEFail-closed validation
Records with unknown chains, missing fields, or malformed rationale are rejected before storage.
- 05PRIVACYLIVEAES-256-GCM encryption at rest
Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.
- 06ISOLATIONLIVETenant isolation
Row-level security and FORCE RLS separate tenant records from runtime roles.
- 07PRIVACYPARTLY LIVEPayload minimization
The public sample exposes only verification fields. Customer schemas require explicit allowlists before any real customer record is public.
- 08OWNERSHIPLIVE IN RECORD DESIGNDeployer-controlled record
The record sits in the deployer's evidence layer. It is exportable, reconcilable, and contract-independent of vendor terms.
- 09OPERATIONSPLANNEDTransparency 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 append-only.
- 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 the decision event after the upstream system has decided, then exposes a tamper-evident record when policy allows public verification.
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.
Signing keys sit outside the producing runtime.
The signing key is held outside the producing runtime. The ECDSA P-256 sample key is served at /.well-known/notary-keys/nc_pilot_ec_1.pem.
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 and public key, verification does not require Notary Cloud to re-run the system or the original vendor.
The record is exportable and independently 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.
Every claim here should be checkable against a live verifier.
The signed sample record and appendix expose the proof fields, canonical string, and public verification path.