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

Release Decision

Verification produces evidence. It does not make the release decision. Company XYZ's accountable owner, Priya Ramanathan, decides whether LoanCore 3.2.0 releases — see .
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. ✓Verify→
  7. 7Release→
  8. 8Package→
  9. 9Hand-off
VERIFYScreen 07
Question
Given the evidence, who accepts responsibility for releasing LoanCore 3.2.0?
Answer
Priya Ramanathan makes the scoped release decision based on evidence readiness, required scenario results, limitations, and any recorded exceptions.
Output
An attributable release decision with scope, rationale, exceptions, owner, and expiry.
Recorded release decision
LoanCore Underwriting 3.2.0 — accountable owner Priya Ramanathan
scope: Applicant A-1027 · policy: Underwriting Policy 4.2 · readiness policy Company XYZ Lending Production
Release withheld
Rationale
One authorized scenario (thin-file routing) fails and one (self-employed income) is inconclusive against Authorized Expected Behavior. Priya Ramanathan withholds release for the affected lending paths pending a corrected candidate; unaffected paths remain governed by approved 3.1.4.
Exceptions
None granted this cycle. Any exception would require Priya Ramanathan's written justification, a named expiry, and a named owner accountable for closing the gap.
Owner of record
Priya Ramanathan — accountable for this decision and its expiry.Marcus Bell authorized the expected behavior this decision was checked against.
Expiry
This decision is scoped to the recorded conditions and evidence above. It expires on re-scope, policy change, or the next candidate submission — whichever comes first.
Notary AI preserves the evidence this decision rests on and verifies the candidate under the recorded scope. Notary AI does not decide what is acceptable and does not make this release decision.
Release Gate run
The Release Gate is the CI/CD expression of Company XYZ's recorded Release Decision — it enforces the decision above; it does not make it.
readiness policy: Company XYZ Lending Production · 24 scenarios in set
[BUILT]gate evaluationGate: blocked
  • LEND-A1027 compensating-factor routing
    Lending · origin: Boundary case

    Candidate routed to compensating review, matching Underwriting Policy 4.2.

    Pass
  • LEND-B0912 threshold denial above 700
    Lending · origin: Routine

    Unchanged from baseline.

    Pass
  • LEND-C3301 DTI above tolerance
    Lending · origin: Policy-derived

    Denial preserved; no collateral change.

    Pass
  • LEND-D7745 thin-file applicant
    Lending · origin: Historical failure

    Candidate now routes a thin-file applicant to review where the authorized behavior is a documented decline.

    Fail
  • LEND-E1180 self-employed income
    Lending · origin: Customer challenge

    Decision-time income-verification context was not captured; result cannot be attributed.

    Inconclusive
  • LEND-F2204 co-applicant handling
    Lending · origin: Synthetic high-risk

    Controlled environment could not load the bureau stub; not a scenario failure.

    System error
  • LEND-G8890 adverse-action notice content
    Lending · origin: Policy-derived

    Requires notice-template evidence that is not yet preserved.

    Not run
Gate mechanism · fail-closed

One authorized scenario fails and one is inconclusive — inconclusive never passes — so the gate does not clear the candidate automatically. Engineering supplies a new immutable candidate artifact; Notary AI re-runs the suite. Notary AI never modifies the release itself.

Scenario library

Grows with every verified case
  • Applicant A-1027 denied at score 650
    Lending · origin: Boundary case included in the release-assurance suite · evidence E4
    expected: ROUTE_TO_COMPENSATING_REVIEW (Underwriting Policy 4.2)
    open →in suite
  • Prior-auth PA-8843 auto-denied despite high-risk note
    Healthcare Prior-Auth · origin: Policy-derived case · evidence E4
    expected: ROUTE_TO_CLINICIAN_REVIEW (Utilization Management Policy 7.1)
    open →in suite
  • Bereavement refund misstatement (NorthStar bot)
    Customer Support · origin: Customer challenge · evidence E3
    expected: REFUSE_AND_HANDOFF (Customer Communications Standard 2.0)
    open →in suite
  • Failed escalation after 3 human requests (CH-4412)
    Contact Center · origin: Repeated overrides suggesting a missing Scenario · evidence E3
    expected: HANDOFF_ON_FIRST_REQUEST (Escalation Standard 3.4)
    open →in suite
  • Candidate HS-2211 rejected on age-proxy feature
    Hiring · origin: Historical failure preserved as a Scenario · evidence E4
    expected: ADVANCE_TO_RECRUITER_REVIEW (Screening Fairness Standard 1.3)
    open →in suite

Proof-readiness coverage

  • Lending1/1 · 100%
  • Healthcare Prior-Auth1/1 · 100%
  • Customer Support0/1 · 0%
  • Contact Center0/1 · 0%
  • Hiring1/1 · 100%

The gate blocks a release when a scenario's evidence is insufficient to attribute a result.

Recurring outcomes

Releases verified this quarter
14
Releases blocked
3
Scenario coverage growth
+9 scenarios
Decision families covered
4 of 5
Replayability coverage
72%
Proof-readiness gaps
6 open

Scenario origins

  • Routine decisions selected for coverage
  • Boundary and edge cases
  • Policy-derived expectations
  • Historical failures
  • Customer challenges
  • Synthetic high-risk cases
Screen anatomy

What this screen proves

A release decision is attributable to a named accountable owner, not to a passing gate. Each verified scenario becomes a permanent in the suite, so proof readiness compounds and every future decision inherits it.

Where scenarios come from

Scenarios are not only past failures. They come from routine decisions selected for coverage, boundary and edge cases, policy-derived expectations, historical failures, customer challenges, synthetic high-risk cases. Each references its source sealed record — it never copies or mutates it — and carries an authorized expected outcome.

Five possible outcomes

A gate run reports Verified, Failed, Inconclusive, System error, or Not run. Inconclusive never passes: it distinguishes "the candidate behaved wrongly" from "we could not attribute the result" or "the controlled environment broke".

Built or Planned

Built capability for the scenario suite and gate evaluation. Planned: Policy Packs that seed scenarios per decision family, and native pipeline integrations.

Related requirements

Next

The decision has been recorded. Notary AI now assembles the evidence, authority, verification results, scope, and limitations into one package.

Evidence Package →