Reconcile Payments

Why is this a Capability MLE? It has an independent purpose, rules, executable contracts, and a realization despite never being customer-visible.

What does this example teach? That a Capability MLE is not synonymous with a page, screen, endpoint, or user-facing feature — internal/background capabilities qualify too, and even one with no direct UI can still have a genuine Communication dimension (see Related MLEs by Dimension below).

Evidence status: illustrative / synthetic — written to teach the model, not a specification for a particular financial system.

Core meaning

Capability purposeMaintain trustworthy financial records by detecting and resolving mismatches between expected and received payment information.

Meaningful outcomeMatched records and clearly identified discrepancies that can be reviewed or resolved by an authorized finance actor.

IncludesImporting payment records, matching obligations, classifying discrepancies, and producing review outcomes.

ExcludesInitiating payments, changing settlement, collecting from a payer, and writing off balances without authorization.

Interaction Contract MLEs

Import payment records

Actor: Authorized scheduler, finance operator, or integration
Result: A reconcilable payment-record set
Effect: PaymentRecordsImported

Run payment reconciliation

Actor: Reconciliation service or authorized finance operator
Invariant: Do not mark a record matched without required identifying evidence.
Result: Matched, unmatched, duplicate, or ambiguous payment outcomes
Effects: PaymentReconciliationCompleted, PaymentDiscrepancyDetected

Review payment discrepancy

Actor: Authorized finance operator
Invariant: Only an authorized finance actor may resolve or write off a discrepancy.
Result: A documented discrepancy-review outcome
Effect: PaymentDiscrepancyReviewed

Operational realization

Execution modesoftware-primary

ExposureInternal workflow

Why it mattersThis proves that a Capability MLE can be internal: external observability is not a requirement for a CRD.

Related MLEs by Dimension

Traceability only. Two dimensions are deliberately omitted rather than filled: Interaction/Behaviour (the three Interaction Contract MLEs above already are this capability's own required core) and API/Interoperability (no API surface is known for this internal capability — "none" is not the same as an entry).

Dimension	Relationship	Related MLE
Business/Domain	implements	Discrepancy classification policy (duplicate / unmatched / ambiguous)
UX/Experience	supports	Finance-operator discrepancy review queue
Communication	defines	Discrepancy Escalation Notice — see below
Frontend/Interface	supports	Discrepancy review queue UI
Backend/Execution	implements	ImportPaymentRecords, RunReconciliation, ReviewDiscrepancy use cases
Data/Information	implements	PaymentRecord, Discrepancy entities
Agentic	supports	Ambiguous-discrepancy triage assistant (illustrative, `agent-primary-using-software`, supports rather than replaces the human reviewer)
Verification	verifies	An unmatched record is never silently marked resolved; a duplicate payment is not reconciled twice
Operations	supports	Reconciliation run monitoring / schedule

Communication MLE: Discrepancy Escalation Notice

Purpose: Alert the responsible finance operator that a payment discrepancy needs review, with enough context to act.
Trigger: A discrepancy case is created by Run payment reconciliation (PaymentDiscrepancyDetected).
Audience: Authorized finance operator.
Required meaning: A discrepancy exists; its classification (unmatched / duplicate / ambiguous); where to review it; that no automatic write-off has occurred.
Terminology: Call it a "discrepancy," never an "exception" or "anomaly," consistently across every realization.
Tone / style: Neutral and operational — this is routine finance work, not an incident.
Rule: Must not state or imply that a discrepancy has been resolved before an authorized finance actor has reviewed it.
Recommended default: If a review-time expectation exists, state it; otherwise, do not invent one.
Possible realizations: Internal dashboard queue item; scheduled email digest; chat notification.
Example copy: "New discrepancy #4821 — ambiguous match, $128.40. Review in the reconciliation queue."

This is also the resolution of an open design question from the CRD site iteration plan: is Communication always a per-capability MLE, or does some of it belong in something Source Context Reference-shaped? This trial shows both are true at once, for different content — the notice itself is owned by this capability, but a cross-cutting rule like "never call it an exception" would belong in a product's Source Context Reference if one existed, and this Communication MLE would reference it rather than restate it.