Screen 04[BUILT]
Applicant A-1027 denied at score 650
Lending · ECOA / Regulation B — Fair Lending — one entry in Company XYZ's versioned library of : preserved decision conditions paired with an Authorized Expected Behavior, reused on every future candidate version.
Company XYZ decision accountability · LoanCore Underwriting 3.2.0Lending · Applicant A-1027— Representative lending boundary case
- ACCOUNT1–3→
- VERIFY4–7→
- DEFEND8–9
VERIFYScreen 04
- Question
- Which decision conditions must future versions continue to handle correctly?
- Answer
- Company XYZ has preserved representative, boundary, disputed, and previously failed decisions as reusable Assurance Scenarios.
- Output
- A versioned library of decision conditions with authorized expected outcomes.
Fault attribution · Rule failure
A rigid deterministic gate denied a case the underlying model would have passed.
Decision chain
[BUILT]captured evidenceINPUT
Application payload
score=650, income=$78k, DTI=22%, tenure=2y
TOOL
Bureau pull
TransUnion — 2 tradelines, 0 delinquencies
MODEL
Underwriting model v3.1
PD estimate = 0.041 (within tolerance)
RULE
Failing or uncertain nodeHard threshold gate
if score < 700 → DENY
DECISION
Adverse action
Notice mailed 2026-06-14
Why this case is useful for release assurance
- source_decision
- Applicant A-1027, personal loan $18k
- trigger
- 142 lending denials without a policy binding
- failing_node
- Hard threshold gate
- evidence_level
- E4
- replayability
- Replay-ready from the sealed cassette
- missing_evidence
- None — decision-time policy version, bureau pull, and adverse-action record are all preserved.
- applicable_policy
- Underwriting Policy 4.2 (2026-06)
- expected_behavior
- Authorized by Fair Lending Lead — Marcus Bell
- suggested_preservation
- Preserve decision-time policy version and human-review evidence on the next occurrence
- suggested_scenario
- Add to the Lending Release Scenario set as a boundary case included in the release-assurance suite
Candidate provenance
- evaluator
- company-xyz-evaluator v0.6.2
- frozen_input_set
- lending-sweep-2026-07
- evaluated_at
- 2026-07-22T04:15:00Z
- source_evidence
- sha256:9f2c…a17b
- relationship_confidence
- Confirmed — decision and adverse-action record share a source identifier
- known_limitations
- Excludes decisions missing bureau pull; advisory only.
Captured decision
Applicant A-1027, personal loan $18k
Outcome
DENIED
reason: credit_score (650) below hard threshold (700)
Authorized Expected Behavior
Route to compensating-factor review (2y employment, DTI 22%) under Underwriting Policy 4.2.
Evidence
E4sufficient for verification
cassette · sha256:9f2c…a17b
Next action
Advisory only. An must define or approve the expected behavior before a candidate version can be verified against it.
→ Authorize expected behaviorScreen anatomy
What this screen proves
For any single decision case, Notary AI can show which nodes ran, which node is failing or uncertain, what was captured, what evidence is missing, and what the record is at.
Why it matters
This is how a case earns a place in the release-assurance suite. A useful case has preserved evidence, a known applicable policy, and a clear expected behavior worth testing every future candidate version against.
Built or Planned
Planned capability for candidate generation; the decision-chain view and evidence grading are built. Candidates shown here are a seeded illustration.
Important boundary
The candidate is advisory. Notary AI does not determine what the acceptable outcome should be — an supplies the Authorized Expected Behavior on Screen 05, and the re-checks eligibility server-side.
Related requirements
Next
A scenario preserves the conditions, but it cannot decide what outcome is acceptable. An authorized Company XYZ reviewer must establish that.
Authorized Behavior →