Illustrative walkthrough using seeded data. Product capabilities are marked Built or Planned.
NOTARY AI
Screen 06[BUILT]

Candidate Verification

Three frozen inputs — preserved decision evidence, the immutable candidate artifact, and Authorized Expected Behavior. Result states: Verified, Failed, Inconclusive, System error, Not run. Inconclusive never passes. Method: .
Company XYZ decision accountability · LoanCore Underwriting 3.2.0Contact Center · Conversation CH-4412— Repeated explicit escalation requests produced no handoff
  1. ACCOUNT1–3→
  2. VERIFY4–7→
  3. DEFEND8–9
  1. ✓Connect→
  2. ✓Landscape→
  3. ✓Readiness→
  4. ✓Scenarios→
  5. ✓Authorize→
  6. 6Verify→
  7. 7Release→
  8. 8Package→
  9. 9Hand-off
VERIFYScreen 06
Question
Does LoanCore 3.2.0 produce Company XYZ's authorized outcome under the preserved conditions?
Answer
Under the scoped A-1027 conditions, the candidate routes the applicant to compensating-factor review as authorized.
Output
A reproducible comparison between approved version 3.1.4, candidate version 3.2.0, and Authorized Expected Behavior.
Comparison result
Not run
Approved contacthub-router-5.2.0
NO HANDOFF — bot continued responding for 11 more turns
Candidate contacthub-router-5.3.0
Pending run
Authorized Expected Behavior
HANDOFF_ON_FIRST_REQUEST

Scoped to the preserved Applicant A-1027 conditions and this scenario's bindings. This does not claim candidate contacthub-router-5.3.0 is correct, safe, or compliant in general — only that it matches Authorized Expected Behavior under these recorded conditions. Result states: Verified, Failed, Inconclusive, System error, Not run. Inconclusive never passes.

Boundary

Notary AI does not modify production and does not author fixes. Engineering supplies an immutable candidate artifact; Notary AI replays preserved decision scenarios against it in a controlled environment and reports whether the candidate matches the authorized expected behavior.

Candidate artifact

[BUILT]verification run
baseline_version
contacthub-router-5.2.0
candidate_version
contacthub-router-5.3.0
artifact_digest
sha256:9e05…b7a1
source_commit
e4471bd
change_type
configuration
submitted_by
ContactHub Platform Engineering
change_summary
Semantic escalation matching with immediate handoff on first explicit ask
Declared behavior changes
  • escalation_matcher
    keyword→semantic + keyword
    Adds vernacular variants
  • hard_handoff_after_n
    unset→1
    1 explicit ask = immediate handoff
Evidence sufficiency
E3N=20 sampled, ≥95% agreement

Verification run log

N=20 sampled, ≥95% agreement
Waiting for replay…
Screen anatomy

What this screen proves

Given a preserved decision scenario and the customer's , Notary AI can reproduce what the baseline version decided and then show what the candidate version decides — under decision-time context bindings, not current settings.

Why it matters

This runs on every candidate release, not only after an incident. It is how a vendor answers "does this version still behave the way we authorized?" before deployment rather than after a complaint.

Replay method: exact or sampled

N=20 sampled, ≥95% agreement. Classifier plus generator — sampled verification.

Exact replay works when the decision is fully rule- or feature-driven. Language-model decisions use N-sample verification with a disclosed confidence threshold; the certificate states which was used.

Decision-time context bindings

A pins the policy version and configuration in effect when the original decision was made. Verification runs against those bindings, so a passing result describes behavior under real recorded conditions.

Built or Planned

Built capability. Deterministic replay and candidate verification against authorized expected behavior exist today. Independent third-party verification packages are planned.

Related requirements

Next

Verification produces evidence, not authority. Company XYZ's accountable owner must make the release decision.

Release Decision →