Screen 04[BUILT]
Failed escalation after 3 human requests (CH-4412)
Contact Center · Support SLA / CX escalation policy — 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.0Contact Center · Conversation CH-4412— 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 · Classifier gap
An intent classifier used keyword-only matching and missed vernacular escalation phrasing.
Decision chain
[BUILT]captured evidenceINPUT
Conversation transcript
3 asks: 'human', 'someone real', 'a person'
TOOL
Intent classifier
Matched 'human' only; missed variants
MODEL
Response generator
Continued auto-response cycle
RULE
Failing or uncertain nodeEscalation trigger
keyword-only match
DECISION
Conversation ended
CSAT dropped, no case opened
Why this case is useful for release assurance
- source_decision
- Conversation CH-4412, 3 explicit escalation asks
- trigger
- 218 conversations with escalation asks and no agent join
- failing_node
- Escalation trigger
- evidence_level
- E3
- replayability
- Replay-ready from the sealed cassette
- missing_evidence
- Classifier configuration in effect at decision time is not captured for ~40% of conversations.
- applicable_policy
- Escalation Standard 3.4 (2026-02)
- expected_behavior
- Authorized by VP Customer Experience — Jordan Ochoa
- suggested_preservation
- Preserve decision-time policy version and human-review evidence on the next occurrence
- suggested_scenario
- Add to the Contact Center Release Scenario set as a repeated overrides suggesting a missing scenario
Candidate provenance
- evaluator
- company-xyz-evaluator v0.6.2
- frozen_input_set
- contact-center-sweep-2026-07
- evaluated_at
- 2026-07-22T04:15:00Z
- source_evidence
- sha256:2a70…9c33
- relationship_confidence
- Confirmed — decision and adverse-action record share a source identifier
- known_limitations
- Advisory; no CSAT causality established.
Captured decision
Conversation CH-4412, 3 explicit escalation asks
Outcome
NO HANDOFF — bot continued responding for 11 more turns
reason: Escalation classifier missed vernacular phrasings
Authorized Expected Behavior
Immediate handoff on any explicit or vernacular escalation request.
Evidence
E3sufficient for verification
cassette · sha256:2a70…9c33
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 →