Interlude V-A: Operation Catalyst
Aa
This interlude serves as a worked example within The Proofs, applying the Part V specification machinery (A22 through A26) to a high-stakes domain: automated loan underwriting with contradictory data sources and regulatory constraints. Operation Catalyst tests entity identity (A23), failed comparisons (A22), policy mismatches and higher-arity events through a proposed lending decision. The corresponding narrative context appears in Vol I, Chapter 7 (The Witness Protocol).
A proposed loan brings source comparison into contact with an institution’s authority to act. The calculation can be reproducible while the inputs remain inadequate for approval. This interlude follows that difference through the records an auditor would need.
The applicant, institutions, identifiers, dates, rates, policies and results are entirely constructed. This is a specification exercise, not a reported deployment or a statement of lending law. The records test whether the proposed representation keeps distinct what a decision would need to examine.
The Setup
A regional bank deploys an AI-assisted underwriting system. Three agents collaborate:
- Agent A (Credit Assessment): Pulls credit reports, calculates risk scores
- Agent B (Income Verification): Verifies employment and income from multiple sources
- Agent C (Decision Engine): Combines assessments into approve/deny/review decisions
The system processes a loan application for "Maria Chen" requesting $50,000 for a small business expansion.
The Data Sources
Credit Bureau 1 (Bureau A):
subject: maria_chen@bureau_a_id_7734
credit_score: 712
derogatory_marks: 1 (medical collection, 2019)
credit_utilization: 34%
Credit Bureau 2 (Bureau B):
subject: m_chen@bureau_b_id_44821
credit_score: 698
derogatory_marks: 2 (medical collection 2019, late payment 2021)
credit_utilization: 41%
Employer Verification (EmployerService):
subject: maria.chen@employer_service_employee_9981
employer: "Chen's Bakery LLC"
income: $78,000/year
employment_status: owner
tenure: 4 years
Bank Account (Internal):
subject: mchen_account_55123
average_balance: $12,400
monthly_deposits: $6,200
deposit_variance: high
The Coherence Problems
Problem 1: Entity Identity (T2, T7)
Are these the same person?
maria_chen@bureau_a_id_7734m_chen@bureau_b_id_44821maria.chen@employer_service_employee_9981mchen_account_55123
Unwitnessed identification: Agent A assumes they're the same based on name similarity. No witness. No scope. If they're different people (Maria Chen the bakery owner vs. Maria Chen the accountant), the loan decision is based on the wrong credit history.
With Third Mode: Agent A must declare equivalences with witnesses and scopes:
EQUIVALENCE_DECLARATION:
left: maria_chen@bureau_a_id_7734
right: m_chen@bureau_b_id_44821
scope: credit_assessment_context
witness: {
class: PROBABILISTIC
method: fuzzy_match(name, SSN_last4, DOB)
score: 0.94
calibration: not_supplied
disposition: candidate_match_requires_further_evidence
}
EQUIVALENCE_DECLARATION:
left: maria_chen@bureau_a_id_7734
right: maria.chen@employer_service_employee_9981
scope: identity_resolution_context
witness: {
class: ATTESTED
authority: EmployerService_identity_service
attestation_date: 2026-01-15
}
The equivalences are scoped. The fuzzy-match score is a proposal; without calibration and further grounds it does not establish a probability of identity. The witness for employer matching is attested (EmployerService's identity service vouches for the link).
Problem 2: Contradictory Values (T1)
The reported scores and counts differ. Before calling them contradictory, the bank must establish that they measure the same quantity for the same person, period and scope. Different scoring models or reporting snapshots can yield different numbers without either being internally inconsistent.
Unrecorded selection: Agent A averages the scores, picks one derogatory count, and proceeds. The disagreement is invisible. If the bank later faces a fair lending audit, there's no record of which source was used or why.
With explicit comparison: The bank records the different inputs and the missing comparison conditions. This is not yet a proved sheaf obstruction:
COMPARISON_ATTEMPT:
cover: [bureau_a_context, bureau_b_context]
target: unified_credit_context
subject: maria_chen (proposed link; bureau identity remains unestablished)
COMPARISON_RECORD:
disagreeing_contexts: [bureau_a_context, bureau_b_context]
differing_reports:
- claim: (maria_chen, credit_score, 712) in bureau_a_context
- claim: (maria_chen, credit_score, 698) in bureau_b_context
- claim: (maria_chen, derogatory_marks, 1) in bureau_a_context
- claim: (maria_chen, derogatory_marks, 2) in bureau_b_context
resolution_options:
1. COMPARABILITY: Establish scoring model, date and population before comparing points
2. AUTHORITY: Prefer Bureau A (contractual primary source)
3. ADVERSE_SELECTION: Consider lower-score policy only with justified comparability and applicable authority
4. ESCALATE: Flag for human review
An average or selected score could serve a defined model, but would be a new calculation or policy choice. It must not be presented as the answer on which the original sources agreed. Choosing the more adverse value is not inherently more accurate or fair.
Problem 3: A Source the Bank Declines (T5)
Agent B verifies income. EmployerService says Maria is an "owner" with $78,000/year income. But the bank's internal policy uses a source-admission policy for income verification: if income isn't in their approved sources list, it's treated as unverified.
EmployerService is not on the bank's approved list. Under this stipulated rule, Maria’s income is “unverified by the bank” even though EmployerService attested to it.
Unexplained source decision: The system either ignores the policy (risky) or rejects the application without explaining why EmployerService attestation wasn't sufficient.
Recorded source decision: The policy mismatch becomes explicit:
CLAIM_REGISTRATION_ATTEMPT:
claim: (maria_chen, verified_income, $78,000)
context: bank_income_verification_context
witness: {
class: ATTESTED
authority: EmployerService
}
REJECTION_WITNESS:
reason: SOURCE_POLICY_MISMATCH
evidence:
- bank_income_verification_context requires: source ∈ approved_sources
- EmployerService ∉ approved_sources
- Therefore: claim cannot be registered as "verified"
remediation_options:
1. REGISTER_AS_UNVERIFIED: Claim recorded but not as verified income
2. ADD_SOURCE: Request policy change to add EmployerService to approved_sources
3. ALTERNATIVE_VERIFICATION: Request W-2 or tax return
The record explains why the bank’s current rule rejects the source. That is not proof that the income assertion is false, that the source lacks relevant evidence, or that the bank’s whitelist is adequate.
Problem 4: Higher-Arity Event (T10)
The decision event involves multiple participants with typed roles:
EVENT: loan_decision
type: UnderwritingDecision
roles:
applicant: maria_chen
loan_officer: agent_c
credit_agent: agent_a
income_agent: agent_b
decision: conditional_approve
conditions: [verify_income_via_tax_return, provide_collateral]
amount: $50,000
rate: 8.5%
context: underwriting_context
timestamp: 2026-01-20T14:32:00Z
Omitted decision grounds: Suppose the decision log omits the contributors and supporting premises. Six months later, when Maria disputes a condition, the bank can't reconstruct which agent imposed which condition or whether the credit assessment supported the rate.
With Third Mode: The event is a first-class object with typed roles (A31):
EVENT_REGISTRATION:
event_id: DECISION-2026-0142
type: UnderwritingDecision
role_bindings:
applicant: maria_chen (identity witness: ...)
loan_officer: agent_c (authority: stipulated_bank_delegation)
credit_agent: agent_a (contributed: credit_assessment)
income_agent: agent_b (contributed: income_report)
decision_binding:
outcome: conditional_approve
conditions: [COND-001, COND-002]
supporting_evidence:
- credit_score_selected: 698 (stipulated lower-score policy; comparability requires checking)
- income_status: unverified_pending
constraints_satisfied:
- ¬(approve ∧ credit_score < 650) ✓
- debt_to_income check: NOT ESTABLISHED; debt inputs absent
- conditional_approve → |conditions| > 0 ✓
An event identifier links the role bindings and decision premises. A relational design can preserve them with joins and constraints. Deletion and retention require an explicit policy; event grouping alone does not prescribe either. Here the missing debt-to-income evidence prevents treating the sketch as a completed underwriting approval.
The Audit Trail
An audit of the proposed decision asks why the calculation used 8.5% instead of the stipulated base rate of 7.9%. The missing debt-to-income check still prevents treating that record as completed approval.
Without the retained decision grounds: The bank must reconstruct the calculation from other records. Recovery may succeed; the rate field alone cannot supply the omitted reasons.
With Third Mode: The query is:
QUERY: Why rate = 8.5% for DECISION-2026-0142?
RESPONSE:
Rate calculation trace:
base_rate: 7.9%
adjustments:
+0.3%: credit_score < 720 (score = 698, source = stipulated lower-score policy)
+0.3%: income_unverified (EmployerService not in approved_sources)
final_rate: 8.5%
Supporting artifacts:
- ComparisonRecord COMP-2026-0089 (credit-input comparison)
- Resolution: LOWER_SCORE_POLICY (used 698, not 712)
- RejectionWitness REJ-2026-0044 (income verification failed)
- Reason: SOURCE_POLICY_MISMATCH (approved-source rule)
Policy references:
- Rate adjustment policy v2.3, §4.2 (score-based adjustment)
- Income verification policy v1.1, §2.1 (approved sources)
The illustrative adjustments add 0.6 percentage points to the 7.9% base rate. The trace allows that arithmetic and the stated rule to be inspected. It does not establish the comparability of the scores, the completeness of the inputs, or the justification of charging more when the bank declines a source. Those remain consequential questions the record now exposes.
What the Machinery Provides
| Problem | Touchstone | Artifact |
|---|---|---|
| Entity identity | T2, T7 | Scoped equivalence with witness |
| Different measures | T1 | Comparison conditions and selected-use record |
| Source-admission rule | T5 | Record of the policy and excluded evidence |
| Higher-arity event | T10 | Grouped roles and premises; atomic update remains an implementation obligation |
The Stakes
The recorded difference is not merely that an auditor can reproduce a number. The bank can see where its own choice entered the result: an identity inference, a preference among scores, an excluded source, an uncompleted check. These choices have different grounds and require different forms of challenge.
Fashion recommendations can also affect livelihoods and access; lending does not confer significance on an otherwise trivial machinery. The example makes the same requirement harder to evade. A record of a decision can establish how it was made without establishing that it was justified.
Consequence
The proposed loan exposes a decision that a reproducible calculation cannot justify by itself. The recorded inputs let the bank locate the missing identification, excluded source and uncompleted debt check before treating the result as approval.
When an AI system makes a decision with real stakes—approve a loan, deny a claim, flag a transaction—the decision must be:
- Grounded: Based on identifiable evidence, with estimates and transformations represented as such
- Witnessed: Supported by evidence with explicit verification regime
- Scoped: Using equivalences that are valid in the decision context
- Auditable: Reconstructible from adequate records, including logs where they preserve the necessary premises
The bank must either obtain the grounds its approval requires or refrain from representing this calculation as an approved loan. Preserving a reason for a charge also makes the rule imposing it available for challenge; the trace does not justify the rule by reproducing its arithmetic.