Home · Work · System design
Assurance, observability and economicsTransactional saga with effect verificationlayered

Partial-fulfilment reconciliation

A multi-step request may succeed in one system and fail in another, leaving the customer, ledger and case record with different views of completion.

Approach

The reconciler models each intended effect and compensation path, reads back every system independently, and moves the request to completed, compensated, pending or human-recovery state.

Organisations, systems and operating conditions are intentionally anonymised and recomposed. The design demonstrates engineering and banking-domain reasoning; it does not represent a named client estate, vendor product or measured production result.

Overview

System overview

Five operating planes separate interaction, identity, decision control, authoritative state and operating evidence.

Partial-fulfilment reconciliation: logical system architecture A five-plane architecture showing channels, access controls, twelve platform services, authoritative domain systems, evidence and operations. Solid nodes are active for this illustrative case; dashed nodes are optional platform capabilities. aSystem boundary and decision authoritySchematic architecture · illustrative scenario Experience planeAccess and scope planeDecision control planeAuthoritative data and effectsEvidence and operations rail Customer Channelweb · mobile · voiceStaff Decision Workspacereview · explain · approveOperations Control Roomincident · replay · withdrawRequest Ingress GatewayTLS · rate limit · schemaIdentity & Purpose GateOIDC · subject · consentPayload MinimiserPII policy · field maskCapability Directoryversion · scope · healthEvidence ContextCompilerContext & evidenceParty RelationshipResolverIdentity & relationshipsAuthority Rules EngineAuthority & policyJourney StateCoordinatorWorkflow & custodyTyped Action BrokerIntegration & effectsDecision ReceiptLedgerEvidence & auditReasoning RouteManagerModel executionEffective-DatedKnowledge HubKnowledge & rulesBehaviour EvaluationHarnessEvaluation & releaseOutcome RecoverySupervisorResilience & recoveryOperational Read ModelWorld state & read modelsDecision ReviewWorkbenchHuman decision & operationsDistributed tracesauthoritative recorddecisionauthoritative recordeffect logsauthoritative recordevaluation resultsauthoritative recordcost recordsauthoritative record HTTPSHTTPSoperations context Immutable Evidence ArchiveTrace · Metric · Cost PipelineIncident · Replay · Custody Queue telemetryexceptions executed or authoritative pathproposal or optional capabilityevidence and telemetryactive in this case
Figure 1. The system boundary separates interaction, authority, business state and operating evidence. Solid services participate in this case; dashed services remain outside the admitted route. This is an illustrative system model, not a named deployment.

Permitted workThe assurance layer observes and evaluates; it may trigger a stop or review but cannot redefine business policy from telemetry alone.

Consistency ruleCarry one correlation chain across synchronous and asynchronous hops and separate event occurrence from observation and processing time.

Hard boundaryThe model is not a system of record, identity provider, policy authority or proof that an external effect occurred.

Deployment

Deployment

The journey can change account, payment, case or document state across systems that do not share one transaction boundary.

Partial-fulfilment reconciliation: deployment and trust-zone topology A production topology separates public edge, identity boundary, workload cluster, integration plane, data enclave and operating controls. Connections name transport and identity protocols, and a second region provides controlled failover. bDeployment topology and failure domainsLogical deployment · no measured estate data EDGE AND ACCESS PRIVATE WORKLOAD CLUSTER INTEGRATION AND DATA ENCLAVE OPERATIONS, EVIDENCE AND RECOVERY PLANE Web applicationfirewallTLS · bot · rate API ingressschema · quota Identity brokerOIDC · MFA Purpose gateclaims · consent HTTPStokensubject Regional traffic managerhealth · canary · failover Workload identity issuershort-lived service tokens Event & work queuepartition · DLQ · backpressure Secrets & key serviceenvelope encryption · rotation Authority RulesEnginezonal workloadJourney StateCoordinatorzonal workloadTyped ActionBrokerzonal workloadDecision ReceiptLedgerzonal workloadOutcome RecoverySupervisorzonal workloadOperational ReadModelzonal workloadReserved workloadslotdisabledReserved workloadslotdisabled HTTPS · scoped JWT workload token async eventkey lookup IntegrationgatewaymTLSDistributed tracessystem of recorddecisionsystem of recordeffect logssystem of recordevaluation resultssystem of record Model route enclavepolicy · schema · egress Qualified data storesSQL · graph · object Trace, metric & cost pipelineOpenTelemetry · redaction Decision receipt archiveappend-only · retention Reconciliation workersreadback · replay · DLQ On-call & review queuescustody · SLA · escalation Secondary-region standbycompatible manifest telemetryreceiptsexceptions
Figure 2. Workloads remain isolated from systems of record. Short-lived identity, typed integration contracts, append-only evidence and controlled failover define the deployable boundary; the topology is schematic.
Authority checkpoint

Retry and compensation require idempotency, current-state verification and explicit authority; narrative success cannot close an unknown effect.

Runtime

Runtime flow

A deterministic outer workflow contains model-led work inside typed, observable calls. Dashed messages remain proposals until policy or a human grants authority.

Partial-fulfilment reconciliation: runtime sequence and control branches Ten lifelines and eighteen protocol messages show authentication, evidence acquisition, policy authority, bounded reasoning, effect verification, human review and append-only evidence. A shaded branch contains timeout and unknown-outcome handling. cRuntime protocol and control pointsProtocol model · illustrative execution Channelcustomer or staffAccess gateidentity & purposeCoordinatorworkflow ownerContextqualified evidenceAuthoritypolicy decisionReasonerbounded inferenceAction brokertyped capabilitySource estateauthoritative stateReview deskhuman decisionReceiptledgerappend-only proof ALT · timeout, rejection, or unknown business effect No blind retry. Resolve source state, narrow the result, or retain custody. Material evidence missing → review queueUnknown effect → readback and reconciliationAuthority denied or expired → stop before dispatch HTTPS · request envelopeOIDC claims · purpose · deadlinetyped evidence requestREST/gRPC reads at qualified timefacts · validity · source versioncontext manifest · exclusionsauthority decision · conditionsminimal residual · closed schemacited proposal · confidence flagsexact capability and payload hashsigned grant · expiry · limitsidempotent command or readaccepted status · effect referenceindependent state readbackaction/effect receiptcase pack when review is requireddisposition · rationale · custodyqualified response · limitations authoritative callproposal / reviewevidence writePattern: Transactional saga with effect verification
Figure 3. The protocol separates request acceptance, permission, business effect and independent readback. A timeout first changes the knowledge state; it does not automatically justify another call. The paths are protocol semantics, not an observed production trace.
S

State model

A durable saga record owns step status, retries, deadlines, compensation and custody. Source systems retain legal business state.

I

Integration choice

Mutating calls pass through typed capability contracts. Events notify downstream services, but command acceptance and effect readback remain distinct.

C

Consistency semantics

Use idempotent local transactions and eventual cross-system consistency. Unknown outcome is a first-class state, not an exception hidden by retry.

Services

Services and interfaces

These roles are deliberately vendor-neutral. Each can be independently owned, versioned and replaced.

  1. COS
    Workflow and custody

    Journey State Coordinator

    Runs a versioned state machine with explicit waits, deadlines, retries, compensations, human tasks and terminal states.

    Degraded routePause at a known checkpoint, preserve custody and resume from the last verified state rather than restarting the request.
  2. CAG
    Integration and effects

    Typed Action Broker

    Exposes typed, allow-listed capabilities with schema validation, delegated identity, idempotency, timeout semantics and effect readback.

    Degraded routeDisable the affected capability, preserve the prepared action and transfer it to an authorised manual route.
  3. RRS
    Resilience and recovery

    Outcome Recovery Supervisor

    Classifies unknown outcomes, replays idempotent work, runs compensations and restores from the last verified checkpoint.

    Degraded routeStop new effects, continue safe reads where possible, and expose the recovery state and owner to customers and operators.
  4. OSR
    World state and read models

    Operational Read Model

    Builds time-qualified projections from source events and reconciliations without becoming the legal system of record.

    Degraded routeExpose source lag and fall back to direct reads for defined critical facts; never present missing feeds as zero.
  5. DES
    Evidence and audit

    Decision Receipt Ledger

    Appends request, versions, policy result, model proposal, approval, action receipt, readback, correction and custody events under one correlation key.

    Degraded routeBlock a consequential close when mandatory evidence is missing; keep the case open with an explicit evidence defect.
  6. PDS
    Authority and policy

    Authority Rules Engine

    Evaluates identity, purpose, capability, amount, risk tier and policy version; returns allow, deny, step-up or human-review with reasons.

    Degraded routeFail closed for effects and restricted data. Read-only explanation may continue only from approved public or customer-visible sources.
Figure 4. Each service exposes a typed contract and a defined degraded route. Coordination stays in the control plane while domain ownership remains outside it.
Data

Data and records

Durable records carry provenance, authority, effect and custody without turning a transcript into an uncontrolled memory store.

Partial-fulfilment reconciliation: state ownership and evidence lineage Authoritative source observations feed six versioned runtime records. Each record names a single write owner. An append-only event and evidence stream builds a disposable current-state projection and supports audit replay. dState lineage, ownership and temporal validityLogical records · fields are illustrative AUTHORITATIVE INPUTS · POINT-IN-TIME QUALIFIEDDistributed tracessource version · observed atdecisionsource version · observed ateffect logssource version · observed atevaluation resultssource version · observed atqualified inputqualified inputqualified inputqualified input WRITE OWNER · Evidence Context CompilerRequest enveloperequest_idpurposeactor_refsubject_refversioned · attributable · retainedWRITE OWNER · Authority Rules EngineContext manifestcontext_idsource_refsource_versionobserved_atversioned · attributable · retainedWRITE OWNER · Typed Action BrokerCase statecase_idstatestate_versioncurrent_custodianversioned · attributable · retainedWRITE OWNER · Reasoning Route ManagerAuthority decisiondecision_idpolicy_versionrequested_capabilityoutcomeversioned · attributable · retainedWRITE OWNER · Behaviour Evaluation HarnessAction and effect receiptaction_ididempotency_keyinput_hashdispatch_statusversioned · attributable · retainedWRITE OWNER · Operational Read ModelCustody eventtransfer_idfrom_ownerto_ownerreasonversioned · attributable · retained APPEND-ONLY CASE EVENTS + DECISION RECEIPTSrequest hash · source versions · policy version · proposal · authority · effect readback · custody Operational current-state viewrebuildable projection
Figure 5. The record chain preserves source version, write ownership, authority and custody. Solid records are required in this scenario; dashed records remain compatible but dormant.
Consistency contractDomain source rule

Carry one correlation chain across synchronous and asynchronous hops and separate event occurrence from observation and processing time.

Choices

Trade-offs

The selected design is not universally superior. It is the safer fit for this boundary and failure cost.

  1. 01

    Open-ended agent planning or a deterministic workflow shell

    Selected path

    Keep consequential state transitions deterministic and use models inside bounded steps.

    Rejected path

    Let the model choose the complete path and recovery sequence.

    Cost acceptedThe shell reduces flexibility, but makes deadlines, retries, permissions and recovery testable.

  2. 02

    Call a source API directly or mediate through a shared capability boundary

    Selected path

    Use direct calls for narrow same-domain reads; mediate cross-domain, reusable or mutating capabilities.

    Rejected path

    Force every call through one integration pattern.

    Cost acceptedMediation adds a hop and ownership overhead; direct calls increase coupling and duplicate controls.

  3. 03

    Distributed transaction or explicit saga with reconciliation

    Selected path

    Use local commits, idempotent steps, compensations and an unknown-outcome state.

    Rejected path

    Attempt one atomic transaction across independent banking systems.

    Cost acceptedSagas expose temporary inconsistency and require recovery logic, but fit systems that cannot share one transaction boundary.

  4. 04

    Query every source in the critical path or maintain operational read models

    Selected path

    Use event-fed projections for scale and direct readback for consequential effects.

    Rejected path

    Fan out to all systems of record for every interaction.

    Cost acceptedRead models introduce lag and reconciliation work, but reduce source load and make cross-system views feasible.

  5. 05

    Mutable current-state record or append-only decision history

    Selected path

    Use append-only events plus a rebuildable current-state projection.

    Rejected path

    Overwrite the case row with its latest status.

    Cost acceptedReplay and storage are more complex, but point-in-time reconstruction and correction lineage remain possible.

  6. 06

    Reason over policy text at runtime or compile executable rules

    Selected path

    Compile stable decision logic and retain retrieval for explanation and residual ambiguity.

    Rejected path

    Ask a model to interpret the source document for every request.

    Cost acceptedRule compilation needs controlled change, but creates repeatable decisions, regression tests and clear exceptions.

Figure 6. Teal marks the selected route; coral dotted rules preserve the rejected alternative. Each decision states the cost accepted rather than presenting one architecture as universally superior.
Recovery

Failures and recovery

Retries are bounded by knowledge of business effect; unknown outcome remains visible, owned and independently reconciled.

Partial-fulfilment reconciliation: failure classification and recovery control flow Five failure sources converge on a classifier that distinguishes known no effect, known failure, unknown outcome, material evidence gaps and control-plane failure. Each state has an explicit recovery route, service degradation and evidence receipt. eFailure classification and recovery policyControl model · thresholds set by owners DETECTION POINTSEFFECT CLASSIFIERRECOVERY DECISIONSERVICE-SPECIFIC DEGRADATION Source dependencyRepeating the whole request can duplicate…Authority servicePolicy is unavailable, expired, or returns…Reasoning routeOutput fails schema, citation, grounding…Action pathTransport times out after dispatch & the…Evidence railReceipt or custody append fails after a… Outcome classifierattempt · idempotency · source readback ·… Known no effectSafe bounded retry with the same…Known failureNarrow, queue, compensate, or fail closed…Unknown outcomeRead back authoritative state before retry…Material evidence gapRetain custody & create an owned…Control-plane failureStop promotion or dispatch; restore the…Journey State CoordinatorPause at a known checkpoint,preserve custody & resume from thelast verified state rather than…Typed Action BrokerDisable the affected capability,preserve the prepared action &transfer it to an authorised…Outcome Recovery SupervisorStop new effects, continue safereads where possible, & expose therecovery state & owner to…Operational Read ModelExpose source lag & fall back todirect reads for defined criticalfacts; never present missing feeds…Decision Receipt LedgerBlock a consequential close whenmandatory evidence is missing;keep the case open with an… RECOVERY RECEIPTfault origin · classification basis · owner · retry/compensation key · readback reference · residual risk · resolved at classifier evidencerecovery evidence Pattern rule: Resolve the earlieraction before retrying. Compensateonly when the reverse effect is…
Figure 7. Recovery follows the known business-effect state, not the transport symptom. Every branch ends in a receipt preserving fault origin, custody and reconciliation basis.
Capacity

Performance and capacity

Actual thresholds belong to accountable service owners. The design exposes the equations and observables that those owners must baseline.

Dependent variablesOperating
envelope
  • duplicate-effect rate
  • unknown-outcome age
  • action and readback latency
  • recovery time and recovery point
Capacity relationships
  1. 01peak_action_rate = requests_per_second x steps_per_request
  2. 02reconciliation_load = timed_out_actions + mismatched_readbacks
  3. 03recovery_capacity = open_unknown_outcomes / owner_resolution_rate
Privacy lens

Collect the minimum diagnostic metadata, tokenise subjects and keep raw prompts or case evidence behind stricter access and retention.

Figure 8. The variables define what must be measured before capacity or quality claims can be accepted. Relationships are analytical scaffolds, not invented targets or production results.
Operations

Release and operations

A design is production-ready only when teams can prove what happened, recover it and change it safely.

Minimum release gates
  1. 01

    trace and outcome completeness

  2. 02

    control-bypass and false-negative review

  3. 03

    cost and human-effort attribution

  4. 04

    kill-switch and recovery exercise

Figure 9. Promotion requires evidence at each gate and a compatible rollback route. No gate is implied to have passed; accountable owners set thresholds and sign the record.
Operating stateReleaseRecover
Evidence

Intended effects, action keys, system receipts, readbacks, discrepancy state, compensation decision, customer notice and final reconciliation.

Human authority

Operations owns unknown or non-reversible outcomes and approves exceptional compensation.

Evolution

Automate reversible steps first. Expand authority only after duplicate, timeout, compensation and operator-recovery tests pass under peak load.

Ownership

Service, control, finance, model, data and operations owners interpret evidence and decide intervention.

Figure 10. Evidence, human authority, ownership and controlled evolution remain coupled throughout operation. Removing any quadrant breaks the assurance case.