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.0Lending · Applicant A-1027— Rigid credit threshold does not consider approved compensating factors
  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 loancore-underwriting-3.1.4
DENIED
Candidate loancore-underwriting-3.2.0
Pending run
Authorized Expected Behavior
ROUTE_TO_COMPENSATING_REVIEW

Scoped to the preserved Applicant A-1027 conditions and this scenario's bindings. This does not claim candidate loancore-underwriting-3.2.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
loancore-underwriting-3.1.4
candidate_version
loancore-underwriting-3.2.0
artifact_digest
sha256:4c18…9d72
source_commit
84f9c2a
change_type
configuration
submitted_by
LoanCore Engineering
change_summary
Add compensating-factor review below score 700
Declared behavior changes
  • min_score_hard
    700→620
    Aligns to portfolio PD tolerance
  • compensating_review
    off→on
    DTI < 30% + tenure > 18mo triggers review
Evidence sufficiency
E4bit-deterministic

Verification run log

bit-deterministic
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

bit-deterministic. Rule-driven — the preserved scenario produces the same outcome every replay.

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 →