NeuralBridge signs the authorization proof with their own key, under their own DID. We provide the SDK; they do the signing. The authorization proof carries transaction details, a reference to the delegation credential, the authorization level, my principal DID, and NeuralBridge's signature.
-Crucially: independently verifiable. Any third party with the authorization-proof JSON and NeuralBridge's published public key (via standard did:web resolution) can verify without runtime dependency on AT's or NeuralBridge's backend. The authorization proof survives every party going offline.
Crucially: independently verifiable. Any third party with the authorization-proof JSON and NeuralBridge's published public key (via standard did:web resolution) can verify without runtime dependency on AT's or NeuralBridge's backend at the moment of settlement. Resolving NeuralBridge's key by did:web does need their domain to answer; hold a copy of that DID document and the proof verifies with every party offline.
Imagine a dispute. Weeks later, the principal claims they didn't authorize the transaction. NeuralBridge presents the authorization proof. It cryptographically establishes: an approval was issued against this exact transaction, signed by the key the delegation names; the authorization was one-time; the delegation credential is valid; the scope matches; the timestamp is consistent. The dispute is resolved before it becomes a chargeback.
-The operations view shows what NeuralBridge sees: the recorded transaction, four-line integration snippet (no API key, no runtime dependency -any third party can verify), stored authorization proof, and dispute prevention indicator. AI infra companies don't displace anything to adopt this -they add the trust layer.
+The operations view shows what NeuralBridge sees: the recorded transaction, four-line integration snippet (no API key, no runtime dependency on us -any third party holding the issuer's key can verify), stored authorization proof, and dispute prevention indicator. AI infra companies don't displace anything to adopt this -they add the trust layer.
diff --git a/scripts/shared-copy.json b/scripts/shared-copy.json index b7c08e0..b3726f4 100644 --- a/scripts/shared-copy.json +++ b/scripts/shared-copy.json @@ -37,7 +37,8 @@ "trading.html", "verify.html", "integrate/index.html", - "blog/op-crossrail/index.html" + "blog/op-crossrail/index.html", + "chargeback-prevention/index.html" ], "phrases": [], "claimPatterns": [ @@ -53,7 +54,7 @@ "makes no network call at all", "our uptime", "permission from us", - "runtime dependency on (OP|us|Observer)" + "(no|without) runtime dependency" ], "claimPatternsAreRegex": "Case-insensitive regexes, matched by check-shared-copy.mjs. Written from the site's own examples rather than from one remembered sentence: the claim is spelled 'call back to us' on index.html and 'callback to Observer' on docs.html, and a literal lower-case list saw neither the capitalised heading nor the Observer variant. Four assertions were invisible to this block on 2026-08-09 for exactly that reason. When you add a home for the claim, add its WORDING here, not just its file.", "claimPatternNote": "Any occurrence of these in an HTML file MUST sit inside an element tagged data-shared-copy=\"offline-scope\". That is what makes a tenth instance a build failure rather than a discovery. Add the tag, or add the file to mustAppearIn if it is a new home for the claim. Some tagged instances REFER to the claim rather than asserting it (docs.html's resolution-hosting rationale is one). They are tagged anyway: the enumeration's job is to know everywhere the phrase appears, and a human scoping the claim decides per instance."